The mobile development landscape has evolved more rapidly than any other in recent memory. Less than 4 years ago Apple unleashed the mobile revolution with the original iPhone. Though it's hard to remember in these app-crazy times, back then there was no SDK for developing native iPhone applications; the only way to get third-party applications onto the iPhone was as web applications optimized for MobileSafari. Today, on the other hand, Apple has a thriving iOS native development platform, with hundreds of thousands of apps earning billions in revenue. Competitors such as Android, Blackberry and Windows Phone have their own native platforms and app stores with varying levels of success. Meanwhile, mobile web applications remain a viable and possible preferable alternate route to users' eyeballs, with the ability to bypass app store restrictions and review wait times. Finally, a variety of cross-platform and compatibility toolkits promise to let you build mobile applications with your existing skill sets, without wading into the scary waters of Objective-C.
Developers are thus faced with an embarrassment of riches in terms of options for mobile development. Yet all this choice can also be paralyzing - the decision is an important one, requiring potentially large investments in hiring, training, and building core capabilities. Meanwhile, each approach has tradeoffs that must be carefully weighed against the business objectives and environment for each specific mobile development project.
At 5AM, we've recently begun work on a mobile product and have had to analyze these options to decide on our development strategy. In this post I wanted to share some of what we found during our analysis. I will look at three primary options: native applications, cross-platform toolkits, and HTML5 mobile web applications.
This is what most users think of when imagining a mobile app. Each mobile OS will typically have a primary language, SDK, and developer tools for creating native applications, and an app store for distributing them (though some also allow independent distribution). For iOS, this means writing Objective C code, using Cocoa libraries, and working in XCode and Interface Builder. For Android, you would generally write Java and work in Eclipse (though some code can and often is written in C, notably graphics-intensive games). For Windows Phone, you are looking at C# and Visual Studio.
- 100% native look and feel, with maximum flexibility for customization
- Immediate ability to leverage new features of an OS release
- No extra layers between you and the native platform, meaning the code is generally performs best and is least memory-intensive
- Typically excellent tools for debugging and profiling applications
- Large and active developer community
- Supporting each OS means starting from scratch in terms of codebase and skill sets, potentially an expensive proposition.
- The language / libraries of a given OS may use quite a different programming style or lack features that your developers are accustomed to. For example, Objective C lacks garbage collection, necessitating explicit memory management. This implies a steeper learning curve or the need to hire specialist developers for that platform.
- Each release, including bug fixes, must go through app store approval, a potentially lengthy process. App stores have restrictions which disallow certain types of application capabilities.
Cross Platform Toolkits
To address the maintenance and skill set issues associated with native application development, a number of cross-platform mobile toolkits have sprung up. There is a diverse array of options here; some entrants are Titanium Appcelerator, MonoTouch, and Corona. What they have in common is allowing you to program in a single language (that you would presumably be familiar with) across the OS's they support, and providing a set of common libraries for building UIs and accessing phone features that are more or less consistent across the OS's. They do vary in implementation approach and the degree to which they leverage native UI components vs. providing their own.
- Can build for multiple OSs in a single language and a single codebase
- With some toolkits (e.g. Appcelerator), can use native UI components, making app indistinguishable visually from a native one
- Can reuse existing developers' skills, assuming the chosen toolkit aligns with them
- Often language and toolkits operate at higher level of abstraction than the native platforms, making code simpler, more compact and expressive.
- OS differences cannot be fully hidden, especially if fully native feel is desired. Some OS-specific code still needs to be written
- The application still must go through app store process
- Debugging and profiling support is generally not as good as the native toolsets. Sometimes abstractions leak, making debugging difficult.
- When new OS releases come out, there is generally a wait time before the toolkit adds support for new features in those releases
HTML5 mobile web applications
The mobile web applications were the original means of getting third-party applications on smartphones, and they still can be an attractive option. Almost all smartphone OS's use a Webkit-based browser, meaning that browser differences are a much lesser issue than for traditional web applications, and HTML5 support is quite extensive, enabling offline capability, local storage, and other advanced functionality. There are several mobile HTML5 frameworks such as Sencha and jQuery Mobile that make it easy to design nice-looking, native-feeling mobile web applications. In addition, with the PhoneGap framework, HTML5 applications gain access to phone features (such as compass, camera, and so on), and can be packaged as native apps, enabling distribution via app stores.
- Can fully reuse existing web developers' and web designers' skills
- Have a very fast test cycle by loading app in browser, without need for simulator or device deployment, when not accessing phone features
- Can bypass the app store and be hosted directly on your server, meaning updates can be pushed at will
- All OS's truly share the same codebase
- Cannot use native UI components or interactions. While the HTML5 frameworks provide nice looking components, and can closely mimic the native themes and animations, they do not provide 100% fidelity, and users can generally tell that the app is not native.
- If not packaged as a native app (with PhoneGap), the application does not receive the benefit of app store distribution, such as rating system, ranking, or possibly being featured
- Can suffer from the perception among pundits of being a second class citizen of the mobile application space.
As you can see, there is no obvious clear winner for all situations - the right choice depends on the type of application, the intended audience, distribution method, and marketing approach. In my next post, I'll talk about the toolkit we ended up choosing for our application, why we picked it, and our experience with it thus far.