Introduction
Smartphones and tablets are becoming ubiquitous, and, with them, mobile apps. But what does the proliferation of different devices mean for developers entering the market? Do you target a single platform, build your app twice for iOS and Android, or use a cross-platform framework?
Here’s a bit of history, and an overview of the different technologies on the market now:
First, there was the iPhone
There were smartphones before the iPhone and there were mobile apps as well. Windows CE was first released in 1996, but it was Apple’s iPhone (launched in 2007) that really signaled the start of the smartphone era.
Originally, the iPhone didn’t allow third-party native-code apps to be installed; developers wanting to add their own content had to do so using HTML web apps running in the phone’s browser. There were some extensions to make such apps look like Apple’s apps rather than web pages, but access to the hardware was limited.
With 2008 came the App Store, and with it the opportunity to develop in native apps in Objective C. This wasn’t without limitations: development required a Mac, Xcode, and only documented parts of the API were available. The resulting app then had to be vetted before being published.
However, the iPhone’s dominance at this stage meant that mobile developers really only had to target one platform, one device, and a very small set of OS versions.
Then Android. Many, many Androids!
Founded in 2003, acquired by Google in 2005, and with the first handset launched in 2008, the Android platform has since seen an explosion of devices since the original G1. In fact, Wikipedia currently lists nearly 100 such devices, made by over 30 manufacturers.
Android devices now collectively account for over 50% of worldwide smartphone sales (Gartner, Q1 2012), but, unlike the iPhone, there’s huge variation in just about everything: screen size, resolution, processor speed, memory, features, and OS version.
Suddenly the idea of developing a single app that runs everywhere (or nearly everywhere) became a goal that was much harder to achieve – but one that remains as attractive as ever.
Solution #1: Cross-platform compilers
These come in a variety of guises. There’s the lowest level: C compilers, linking against the various platform SDKs. You’re working in a common language, but the APIs are vastly different.
Thankfully, there are options at a higher level, too: Appcelerator’s Titanium platform compiles JavaScript code into native apps, linking it against their platform-neutral SDK. Xamarin offer a C# compiler targeting both Android (MonoDroid) and iOS (MonoTouch).
These (and other similar) platforms offer a common language, but still one that needs to be compiled for multiple devices.
Solution #2: HTML 5 web apps
With HTML 5, code running in web browsers is able to provide an increasingly rich client-side experience: local storage, geolocation, audio and video, offline working, accelerated graphics operations and more. The distinction between apps and website has certainly become more blurred.
A great example here is Amazon’s Kindle web app on iOS: because of changes in App Store policies, they opted to go for a pure HTML5 app, whilst still allowing users to download content for later use, and keeping a great user experience.
One of the downsides here is more social than technical: many people now expect apps to be listed in app stores, and have become used to the discovery and installation process associated with their platform of choice. There are also still some limits on the APIs available, and the amount of data that can be stored locally.
Solution #3: HTML5 hybrid apps
A further solution is to develop your app using a combination of HTML5, JavaScript, and usually some extra libraries, and then wrapping it in a relatively thin native-code wrapper.
The advantage of this approach over the two covered above is that it combines the benefits of both HTML5 and native apps: there’s a common development language, a common set of APIs for all supported platforms, and enhanced access to the device over a pure HTML 5 web app. Local storage can exceed the 5MB limit, photos from the local device can be uploaded, background services can run (on some platforms), and so on.
Leading this field is the PhoneGap framework – now donated to the Apache Software Foundation as an open-source project and renamed Apache Cordova. Cordova provides a platform-specific wrapper for Android, iOS, BlackBerry and Windows Phone, and exposes a platform-independent API to code against in JavaScript.
Web development skills now apply equally to mobile apps – the same language, the same design process, and the same technologies.
The final sticking point, however, is the build process. To compile apps into their native wrappers, you still need the SDK for each platform. And that’s not as easy as it sounds: iOS requires a Mac, Windows Phone requires a Windows PC, and getting the Android SDK going isn’t generally the slickest experience.
Enter the hosted build services...
If the idea of hybrid app development appeals, but the setup cost and effort doesn’t, then hosted build services may be the right answer.
If Dreamweaver is your world, Adobe have integrated the PhoneGap Build service into their new Creative Cloud offering. If you’re more development-oriented, Red Gate’s Nomad allows you to work in Microsoft Visual Studio, before shipping your code off to their cloud-based build service. Once built you get native iOS and Android apps, ready to use on your devices – no Mac required.
It’s worth noting that (whichever solution you use), to build apps for the iOS App Store, you’ll still need to be a member of the Apple iOS Developer Program, which is $99 a year.
So native development is dead?
Definitely not. There’s a class of apps that just can’t be built using hybrid or cross-platform technologies: from low-level utilities (such as the excellent Tasker app on Android), high-performance games (although the graphics performance available through Canvas is improving all the time), to those talking to parts of the platform SDK or peripherals that just aren’t available in your cross-platform framework of choice.
But for 90% of the apps out there, consider whether your time is really best spent setting up multiple development environments, re-developing your app in several different and unfamiliar languages, or whether you can use the work that a fantastic community of people have already done for you.
