Why develop a native mobile application?
· 11 minute read
Published May 17, 2011 based on experiences building GS Research for iPad. Updates will be additive as the original article will be kept intact for posterity.
UPDATE (9/22/2012): Facebook developer Tobie Langel has posted some interesting feedback to a W3C mailing list in the aftermath of rewriting Facebook’s failed web-based iOS application.
UPDATE 2 (11/28/2012): And now my app (Tumblr) is fully native as well.
Interested in building a mobile application but not sure where to start? There are a dizzying number of frameworks and platforms all currently vying to be your answer. In order to decide which is right for you, it’s important to understand the pros and cons of the different mobile development and deployment strategies available today.
In this paper, I’ll compare and contrast native applications, mobile web applications, and a few approaches that blur the lines between the two.
Native development kits allow one to build mobile applications that are performant, can access all of a device’s API points, and have a familiar look-and-feel. Access to a mobile device’s camera, microphone, and address book, to name just a few, is provided by its native SDK. Native applications are unique in being able to seamlessly integrate these features1.
From a user experience point of view, native UI frameworks can be leveraged to build applications that are both aesthetically pleasing and intuitive. There’s a case to be made that mobile applications shouldn’t look and function the same on every platform; users of a mobile operating system acquire a sense of familiarity with the gestures, controls, and paradigms that are specific to that platform, and design decisions made with an iOS user in mind may not make as much sense to a user of a similarly sized and powered webOS device or BlackBerry.
To quickly mention a few more advantages of developing on a native platform:
- Advanced persistence: Frameworks such as iOS’s Core Data provide rich object- relational mapping (ORM) and robust lazy-loading and caching mechanisms.
- Superior tooling: IDEs like Eclipse and Xcode contain powerful debuggers among other useful tools.
- Secure storage: The iOS “keychain” provides a secure storage mechanism, which can be configured to encrypt data for a unique device/application combination and to only be available when the device has been unlocked.
- Stable frameworks: When choosing Cocoa Touch as your platform, it is assuring to know that Cocoa has been in use in all kinds of applications dating back to the 1980s. Mature components like Core Audio and Core Animation are well maintained and thoroughly documented2.
Mobile web applications
One benefit of developing a mobile web application is that you can immediately release new versions without requiring users to explicitly upgrade. While the Android Market allows for a similarly quick turnaround time, distributing through the Apple App Store requires first having your application’s quality and subject matter reviewed and approved by Apple, which can take some time4. With a web application, you also don’t need to worry about breaking backwards compatibility.
“The Web technology stack hasn’t achieved the level of performance we can attain with native code, but it’s getting close.”
Web applications with native “wrappers”
This approach may fall short, however, when you end up needing to debug or tune your application at a low level. A slide in a 2010 deck on the PhoneGap website entitled “How do I debug it?” merely states that “Desktop Safari is very close to Mobile Safari (close but not exactly).”
“Desktop Safari is very close to Mobile Safari (close but not exactly).”
Cross-compilation and native UI “bridges”
While this is quite cool and potentially very useful, no one knows how long these frameworks will be actively developed, documented7, and supported, and it is risky to assume that the best interests of a third-party intermediary will always align with yours. When mobile device and platform vendors release hardware and OS updates, they are often accompanied by new APIs for developers to take advantage of. If you’ve chosen a framework like Titanium, you first have to wait for the Titanium developers to add wrappers around the new APIs before you can use them. Doing so in a timely fashion may not be a high priority for the framework vendor, depending on how much of their user base is clamoring for the feature and how widespread it is expected to be across other devices and platforms (i.e. part of the lowest common denominator).
This isn’t solely an issue with new features, either. Neither PhoneGap nor Titanium offer a built-in way for applications to access the keychain, the encrypted storage option that has been present in iOS for quite some time. Instead, keychain support in both platforms is available only through additional plugins/modules - more dependencies that you, as a developer or project manager, need to worry about.
Inverting the hybrid approach
Instead of developing a web application and wrapping it in a thin layer of native glue, there’s another hybrid approach that warrants consideration: writing a native application that also renders HTML content in specific views.
Clearly, there are disadvantages to developing applications that are targeted only at specific mobile platforms. Aside from the time required solely to create multiple versions, you may also need to learn new languages, libraries, IDEs, abide by the guidelines of the platform owners, and possibly even purchase a new computer8. For applications that only require a subset of features that are common to most of the major mobile platforms and don’t have any significant performance restrictions, a cross-platform solution rooted in web standards could very well be the best choice. Already very high in quality today, these technologies will only continue to get better and faster over time.
That being said, there is still currently value in developing with the technologies that are native to specific combinations of mobile devices and operating systems. As highlighted above, the advantages of this approach include but are not limited to:
- Access to all features of a device and platform
- A consistent look and feel
- Increased performance and battery life
- Powerful debugging and tuning capabilities
- Confidence that the libraries and tools will continue to be improved, documented, and supported going forward
Even Google, one of the largest proponents of web applications, open web standards and high- quality mobile web UIs, has embraced native applications both with their own Android platform and their seven official native applications currently available in the iOS App Store9.
Craig Hockenberry, of The Iconfactory/Twitterrific fame, discusses this same topic in an A List Apart article entitled “Apps vs. the Web”.
Peter-Paul Koch also writes about “Native iPhone apps vs. Web apps” and links to related posts from key industry figures on the QuirksMode blog.
The HTML5 specification provides web applications with some functionality that was previously only available through native SDKs, like geolocation and local storage, but there are and will continue to be gaps and varying degrees of browser support. ↩
Contrarily, one could easily argue that despite some turbulence, HTML5 is still in a better state than certain native SDKs like the BlackBerry Playbook’s. ↩
Apple’s Dashcode (part of the Xcode suite) can be used to create iPhone-optimized web applications, but with varying degrees of cross-browser compatibility. ↩
The review process isn’t all bad; users may be more willing to download an application that has been vetted by a trusted source and is likely to be free of viruses or malicious code. ↩
A few mobile web app stores do exist, but they aren’t well-known or frequented. ↩
The documentation for some of these third-party kits supposedly isn’t great, either. I can only speak to the quality of the official iOS SDK documentation myself, but I can vouch that is excellent. ↩
The iOS SDK requires an Intel Mac running Mac OS X Snow Leopard. ↩
Google Search, Google Earth, Google Voice, Google Books, Google Places, Google Translate, and Google Latitude. ↩