The Cross-Platform Mobile Problem
As the smartphone market becomes increasingly fragmented, it’s important to decide if you want to choose a “write-once-deploy-everywhere” web-based mobile platform strategy, or one that provides better native usability and performance on each individual platform. There are advantages and disadvantages to each approach, but the tide seems to be turning toward web technologies.
With competition heating up in the smartphone world, the market is becoming increasingly fragmented. A recent Gartner study showed that worldwide third quarter 2011 smartphone market share was dominated by Android, with Symbian, iOS, and RIM left to fight over the scraps.
This might be a bit misleading. When we think about the enterprise market, or even the urban, American consumer, we know intuitively that the story is quite different – Symbian is non-existent, and RIM still has a big presence. Indeed, if we look only at 2011, RIM has given up some ground to both Apple and Android, but this is hardly a sea-change. Microsoft is doing better with their Windows Phone 7, but is still being beaten out by even their own outdated platform, Windows Mobile.
There’s no clear winner here, nor should there be. The economics of smartphones don’t completely obey traditional network effects. Factors that drive consumers to one device or the other depend more on the intended use and the budget of the consumer than on how many total users that platform has. Gamers may prefer iPhones, while business users might be just as happy with an Android or Blackberry device. All three support Exchange and web browsing so there’s low switching cost unless they happen to be using RIM’s enterprise services. In other words, if you’re waiting for a winner here, you might be waiting a long time.
How all of this plays out has big implications for companies who want to develop mobile apps. The development tools used to build apps for each platform are completely different. The cost of developing and maintaining your app is multiplied by the number of devices you want to support.
When I ask developers of iOS or Android apps whether they intend to support, for example, Blackberry, or Windows Phone 7, the response is generally that they are going to “wait and see”. The subtext is that they would love to increase their reach with a 2nd tier device but the economics are prohibitive. Instead, they’ll continue scanning the horizon for any perceptible shift in device preferences, and hope they’ll be the first among their competitors to discover the next niche opportunity.
This is actually a very widespread problem – and an obvious business opportunity.
First of all, one wonders how we got into this situation in the first place. There’s already a platform for applications that’s trusted and used by everybody, and it’s called the web. Given that the current generation of smartphones all have astonishingly modern web browsers built right in, it’s even more unfortunate that web technologies were not the prescribed way to build apps right from the beginning. One could point to the limited computing power of these devices as possible explanation (using a browser can be a less efficient way to execute code), but cynics could also claim that this was done deliberately to create incompatibility as a way to foster those all-important network effects.
- PhoneGap (Apache Callback) :PhoneGap is an open source and free framework developed by the Internet startup Nitobi, who was recently acquired by Adobe (full disclosure: I was a principal developer there for years). Apps using this framework are basically web pages housed in a native container, making them seem like native apps. It has recently been admitted into the Apache Software Foundation and is on its way to becoming a full Apache project.
- Rhomobile: Recently acquired by Motorola, Rhomobile takes a similar tack as Titanium in that is uses web technologies as the foundation to build apps that are in fact not web pages, but native apps using familiar widgets that adapt to each device platform they run on. Rhomobile also provides some back-end services to simplify the integration of enterprise data sources such as Dynamics, Oracle, SalesForce, and SAP.
- Mono (MonoTouch / MonoDroid) by Xamarin: The recent entry of Windows Phone 7 has brought Microsoft development technologies to mobile. An open source project that has long had the support of Novell called Mono has been adapted to run on iOS, and Android devices. Now, the breadth and power of the Microsoft development stack can be brought to bear on virtually all major handheld devices except Blackberry and Symbian. The Mono strategy is yet another mixture of part native-development, part abstraction. The main difference here is that in the case of Mono, the needle is tilted a little more towards the native toolchain, making only parts of your application shareable between platforms. Anecdotally, about 65% of code is re-usable between all three platforms using Mono.
Choosing a Cross-Platform Strategy
Given all the advantages of using web technologies, why might someone choose not to go the Netflix or Facebook route and use, for example, a PhoneGap solution?
A big consideration is native look-and-feel. With a web page, you’re generally going to get exactly the same presentation on an Android device as an iOS device. Any attempt to mimic the device’s native look and feel generally falls a little short of being completely convincing.
Performance is another issue, making games not a good target for web apps. For business applications, this hit isn’t a big deal, but few would argue, for example, that Netflix’s iPad app even approaches the quality of a native app, and this can be attributed to the fact that it is really a webpage under the hood. However, with the performance of handheld devices improving in leaps and bounds, the quality gap between web and “native” is ever shrinking.
In the long term, the tide seems to be moving in the direction of web technologies. Here at ForeSee, we have so-far adopted a native strategy with our mobile apps partly because it’s important to us that we develop competencies in the tools used by our customers. Looking forward, it’s inevitable that we will be including more and more web technologies in our mobile roadmap.