Having now existed for over four years, the App Store impresses not only with revenue numbers and download statistics but by having turned the act of installing software into something fun and easy, that even the most casual smartphone and tablet users feel comfortable doing. As the number of apps and services that an iOS user engages with increases, it’s only natural for developers and users alike to seek integration across these various services. While many apps already integrate nicely with one another, let’s discuss the shortcomings that exist today and how app interoperability could potentially be improved going forward.
Most of the best iOS applications are not completely standalone, but rather pull data in from external sources or provide the option to share outwards. Timehop is a great example of the former. A charming application that helps you reminisce about experiences you may have forgotten, Timehop resurfaces photos, tweets, Foursquare checkins, and other types of data from years past. The value that Timehop delivers correlates directly to the quality and quantity of data that the user provides it with. In terms of sharing outwards, a photo editing application will generally be more appealing to users if it offers an easy way to post to their photo sharing services of choice.
Sadly, the ease with which you can allow one application to integrate with another on your behalf can vary dramatically. Granting access to your Facebook or Twitter data is trivial, as Apple has selectively chosen to deeply incorporate these credentials at the OS level. For other services such as Foursquare or Evernote, this is not the case.
While many of your favorite services likely provide APIs that developers can connect their apps to, there’s a significant time cost in doing so. It’s simply impractical for a developer to manually integrate with the growing number of services that their users may be interested in. Additionally, there are UI considerations when presenting the user with the ability to authenticate with or share to a third-party service. If you were to build a new camera application today, think about how many potential destinations (Flickr, Instagram, etc.) you would have to support. This can result in a large amount of duplicated effort across the developer community.
Services such as Pocket, Facebook, and Dropbox do a great job of mitigating these shortcomings by providing SDKs, bundled code that other developers can drop into their applications in order to easily integrate. Despite this, it’s still unrealistic to expect every app to explicitly define the interactions they have with every other app, many of which may not even exist at the time of development. There should be a better way.
Every iOS application should be able to define types of input and output data. For Tumblr, an input type could be a photo or a video to post, while an output type could be a credential that another application could use to communicate with the Tumblr API. For 1Password, an input could be a URL, and the output a corresponding username and password. Allowing applications to be stitched together dynamically based on the data types that they know how to act upon would allow iOS users to be productive in ways that are not possible today. These are notnew ideas.
Thankfully, Apple has been laying the groundwork for some of what has been described above. iOS 6 introduced “activity controllers”, the grids of icons you have likely seen when trying to share from an application such as the default Photos app. While more visually appealing than the text-based sheets that preceded them, developers still need to manually specify the activities that their app can perform. Looking at the way that Apple requires activities to be implemented, however, allows one to envision a scenario in which applications could dynamically display activities defined by other applications, depending on the type of data being processed.
An activity can optionally provide a screen that iOS will present to the user when selected. When the email activity in Photos is chosen, for example, a compose screen is displayed on top of the app. As of iOS 6, this compose screen is actually being pulled in from outside the app it is being displayed in. While this may not be particularly interesting quite yet, it bodes well for a future where apps can include user interfaces provided by other applications, preventing developers from having to build their own login forms and share sheets for each third-party service that they want to integrate.
Like many of iOS’s built-in applications, Safari also displays an activity controller when the user taps the “actions” button in the toolbar. Many iOS apps currently embed their own crude “browsers” in part due to their inability to augment Safari with functionality specific to their application. These in-app web browsers don’t contain access to bookmarks, iCloud tabs, or Smart App Banners, resulting in a hindered experience for the user. If Safari’s activity controller could dynamically include activities such as “Read Later” from Instapaper or “Fill Credentials” from 1Password, developers could potentially stop building their own in-app alternatives and everyone would benefit.
As iOS evolves, it continues to empower developers with new capabilities for enriching the lives of our users on a daily basis. Allowing apps to be smarter about exposing data to and consuming data from other applications would be a natural progression. By providing dynamic inter-app communication, iOS would allow developers to focus on what makes their particular applications great. For users, a seamless integration of services would make our ever-increasing time spent on mobile devices more productive.
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.
Audience
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.
Introduction
It’s an incredibly exciting time to be a software developer. The emergence of numerous smartphone and tablet platforms, containing both native runtime environments and cutting edge browsers, has resulted in a bevy of options for those interested in writing applications to be used on the go. On the far ends of the spectrum are native applications, written in a language like Java or Objective-C and run directly by a device’s operating system, and mobile web applications, written in HTML, CSS and JavaScript and rendered in a mobile browser. Since web technologies are open, standardized, and allow one to easily target a wide user base, why choose an unfamiliar language or even framework? Using a mobile operating system’s native language and APIs has its advantages, which this paper will investigate and explain.
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 applications
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
Another common approach is to create a website whose user interface is optimized for mobile devices, using a library such as Sencha Touch, jQTouch or the forthcoming jQuery Mobile. These frameworks provide cross-browser compatible interfaces and animations that attempt to look and feel native but are built using standard web technologies: HTML, CSS, and JavaScript3. In many modern browsers, HTML5 web applications can even be used without an Internet connection.
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.
A disadvantage of mobile web development, in addition to the lack of native API support, is inferior performance. “The Web technology stack hasn’t achieved the level of performance we can attain with native code, but it’s getting close,” states an article written by leaders of the cross-platform PhoneGap framework. While native applications are compiled for high-speed execution, web applications use JavaScript that is primarily interpreted at runtime5. Performance also has an effect on battery life; expensive operations will drain a phone or tablet’s battery faster than more efficient ones will.
The article also mentions that even the best JavaScript UI libraries available today leave something to be desired in terms of touch responsiveness and consistency. Similar to how cross- platform desktop apps (e.g. Java, Adobe AIR) can feel clunky compared to their native counterparts, web apps don’t yet provide the slick, snappy user experience that mobile platform users have become accustomed to.
“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”
If you’re looking for a “write once, run anywhere” solution and aren’t concerned with the performance and user experience issues highlighted above, one option is to build an application using web technologies and wrap it with something like the aforementioned PhoneGap. PhoneGap is a free, open source framework that provides native API access and allows for submissions to mobile app stores. This is accomplished using native components that encapsulate browser rendering and JavaScript engines. When combined with a JavaScript UI library, PhoneGap can provide a cross-platform solution that may meet your needs quite nicely. The discoverability and integrated payment options that come with an app store presence can be invaluable6.
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”
Yet another option is to translate an application developed with a common technology into native applications that can run on numerous mobile platforms, using a third-party development kit. A couple of examples are Titanium, which allows you to use JavaScript instead of Objective-C or Java, and Corona, which does the same using the Lua scripting language. Adobe AIR applications can also now be converted to run natively on iOS (they have on Android since late 2010). The selling point here is the same “write once, run anywhere” result that PhoneGap provides, but coupled with native performance and design.
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.
This HTML can be provided by a server-side content management system and reused in all of your native applications. Each application can apply its own CSS and use JavaScript for any interaction between the shared markup and platform-specific controller logic. The majority of your user interface, particularly your navigation and any contextual menus, will still be comprised of native components to achieve the desired look, feel, and performance.
Conclusion
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.
Additional resources
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. ↩
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. ↩
