The world of mobile apps is moving so quickly that it's a challenge even to take a moment-in-time snapshot that leads to useful insights. Days and weeks from now, the world might look rather different. To show how profound and rapid the changes are, consider that if you decided to write a mobile app five years ago, the two must-target platforms would have been BlackBerry and Palm. The first iPhone shipped barely a year earlier and was still playing catch up. And as yet, no Android phone had shipped.
White PapersMore >>
- Transforming Operations - Part 1: Managing Outsourced Development in Telecommunications
- Big Data and Customer Interaction Analytics: How To Create An Innovative Customer Experience
If you were writing apps three years ago, you'd have only just become aware of tablets as a mobile platform and you certainly wouldn't be targeting them. And if you could spiral back just two years ago, you'd be surprised to know that worldwide sales of smartphones would today heavily favor Android. And that the leader in Android devices was Samsung, rather than HTC.
Things change fast in mobile and likely will continue to do so. This quality puts a curious and difficult pressure on organizations developing mobile apps: They need to make strategic decisions very early in the development process. The pressure plays out differently for the two major types of mobile app-creating organizations. The first group, which faces the biggest quandaries, comprises ISVs who are writing specialized apps primarily or exclusively for the mobile market. The second includes most businesses that want to provide a mobile app to give customers or employees access to existing resources.
The ISVs must decide the order in which they will target the major platforms and then how they will do it. This is no easy task. Last year, the established order was iOS, Android, Windows Phone, Blackberry. By some accounts, BlackBerry has nudged into third place, ahead of Windows Phone. It makes very little difference, though, because the reality of the market is that whoever falls behind Android sees very little development attention. The reason is that Android is such a fractured market that delivering and testing an app for Android platforms tends to exhaust developer bandwidth. The organization is essentially spavined by having to work out form factor and OS release issues for numerous Android sub-segments. So, rewriting the app for a third platform with small market share has little appeal.
Because of the fragmentation of Android's installed base, iOS is frequently the first targeted platform. Apple's walled garden approach and limited number of devices favors the development effort, especially for ISVs, who generally produce products written as native apps. However, as Android expands its market share (especially on a global basis), choosing the correct sequence becomes increasingly complex.
Which brings us to the second major decision point: How to write the app? Todd Anglin, who heads up cross-platform tool development for Telerik, the makers of the Kendo UI toolkit for mobile apps, elegantly sums up the range of choices:
- Native: Write a completely new app using the native APIs for each platform. This gives the best-looking, most functional apps, but is not portable.
- Cross-compilation: A variant of hybrid, it uses non-native languages, which are then compiled to the native platform. Xamarin is the primary vendor of this approach. (We recently reviewed two of their product releases.)
- HTML5: The most portable solution; but criticized for a non-native look and apps that lack access to many of a devices' capabilities.
Choosing the development approach is, in many ways, the more important of the two decisions and, in many situations, it might obviate the choice of platform. Businesses, for example, which simply need to provide a mobile version of an existing feature to their employees overwhelmingly choose HTML5, which runs with little modification on all the major platforms, including BlackBerry and Windows.
However, things get a lot dicier if the requirements for an app exceed the capabilities of the Web and HTML5, and budget precludes native versions for all platforms. (Let's remove the cross-compilation option from the discussion, as it is a solution that applies only to organizations with unique needs and qualifications.) For the last few years, the hybrid approach has been a workable solution, which explains in part the popularity of PhoneGap. However, Anglin confirms that recently another trend has emerged, in which developers write a native application for the one platform they view as most vital. They then use HTML5 or a hybrid approach to port the app to all other platforms.
I am not sure that this is a trend that will stick. It essentially doubles down on a single platform a terrible proposition in a fast-changing market presently dominated by two players, and it doubles the cost of development, albeit with the benefit of comprehensive platform coverage. What it does convincingly do, however, is demonstrate the very difficult choices organizations face when committing to a mobile strategy.