Mobile OS Musings

I haven't had much time for hobby programming since becoming a father and I can't really talk about my day job, so all I really have to talk about are things I've read about. I fear that I'm indulging in punditry, but I'm aiming for something closer to thinking out loud.

What I'm thinking about, in this case, is mobile app platforms, and I'm starting from the three mobile app platforms I find interesting: Apple's iOS, Google's Android, and HP/Palm's WebOS. I should probably explain why I care about WebOS, and why I'm not covering either the existing Blackberry OS or the QNX-based Blackberry Playbook from RIM.

Justifying Myself

The Playbook looks interesting, but its UI is very similar to WebOS. Furthermore, its app platform is Adobe AIR. As a VM-based runtime, AIR is similar to Android's Dalvik VM. It uses ActionScript, a dialect of ECMAscript/JavaScript, as its development language, similar to WebOS's JavaScript-based development. In short, it isn't different enough from the other platforms to rate discussion (at least for my purposes) and, worse, it isn't shipping yet.

WebOS has shipped on a few devices, but hasn't gained much popularity. It's pretty much a rounding error when it comes to market share. Its fortunes may be changing, however, since HP seems to be betting the company on WebOS. Most importantly, it has some unique features, particularly Synergy and Touchstone (scroll down to "Better Together" on the Touchstone link).

The existing Blackberry OS is a dead end as an app platform. RIM's purchase of QNX makes it clear that they are looking to replace their aging OS, and rightly so. Every Blackberry device currently on the market is already obsolete, and RIM cannot attract a development community to it's excruciating ecosystem of dozens of OS versions on dozens of hardware configurations. There are a few people out there who love their Blackberries, but the vast majority of Blackberry users have them through their jobs. Even if their share of that market lasts for the next decade, it isn't the consumer market in which the other platforms are competing and in which I am interested.

With that out of the way, I want to cover the similarities between iOS, Android, and WebOS development. They seem more different than the same, but there is one part that is and will probably remain nearly identical across platforms: 3D (game) development. Android has the NDK and WebOS has the PDK so that C and C++ code targeting OpenGL ES can be included in an app. C and C++ (and OpenGL ES) are part of iOS development anyway, since all iOS apps are written as C/C++/Objective-C/Objective-C++ code. This means that the core of most 3D games, particularly those from big development houses, are pretty portable across all the platforms. Porting has more to do with managing bundled assets, interfacing with user input, and extensive testing than any rewriting of the game engine. Other similarities include hardware functionality (e.g. GPS, accelerometer/gyroscope, camera, touch input, etc.) and common APIs (e.g. TCP/IP, audio/video, data storage, etc.).

The differences come down to the fundamental approach to development. Developing an iOS app is more similar to than different from developing a desktop application with a traditional event loop and GUI widgets. Android apps run in a VM (it isn't technically a JVM, but the differences are negligible), and are based on a radically different paradigm of activities, views, intents, and services. WebOS apps are basically web apps with JavaScript bindings to native APIs — they use HTML/CSS for presentation and rely on the normal web browser event loop.

Could They?

The really interesting question concerning these platforms is how easy it would be, both technically and legally, for one OS to support a competing app platform. This assumes that the hosting platform's app store(s) would accept app submissions for the competing platform rather than attempting to run apps purchased on a competing platform. Since Android is open source and its apps run in a VM, it should be both technically and legally easy to support on either WebOS or iOS. Various APIs would have to be implemented to call the native platform's equivalent APIs, and some (e.g. background processing) would have to change behavior or simply be removed, but most Android apps could be hosted reasonably on either WebOS or iOS. There may be some legal challenges, however, based on Oracle's lawsuit against Google concerning copyright infringement in Android, or various patent claims from Microsoft and others.

Likewise, WebOS apps run in a web browser and could be supported on either Android or iOS with the same sort of API implementation. The biggest technical hurdle is probably Synergy, but WebOS apps can make use of the available information, ignorant of its origins, rather than using anything specific to Synergy. Again, most WebOS apps could be hosted reasonably on either iOS or Android. The bigger issue for hosting WebOS apps is that a good chunk of the JavaScript provided by the WebOS SDK is protected by copyright, and would have to be reimplemented to avoid infringement. That isn't insurmountable, but it means that it isn't nearly as easy to create a hosting environment for WebOS apps as for Android apps. Hosting AIR apps for the Blackberry Playbook have similar considerations, though Adobe will happily license the AIR environment, possibly at a negligible or even zero cost.

iOS apps are a whole different story. An iOS app is a single native executable (plus a bundle of assets). Most of the libraries on which it relies are neither provided as open source nor in any way similar to any publicly available source code. The GNUstep project has free implementations of some of those libraries as well as the Objective-C runtime, but it would require a huge effort to reimplement those libraries. It is, of course, possible with the application of sufficient time and money, but it is much more difficult and, therefore, more expensive than trying to host either of the other two platforms' apps.

Would They?

At least as interesting as how easy hosting a competing platform would be is whether there would be a competitive advantage to doing so. Apple has shown over and over again that it has no interest in apps that run easily on multiple platforms. The rationale is that supporting a platform they don't control means they can't improve the platform as rapidly as one they do control. More importantly, iOS has no shortage of apps thus supporting apps from a competing platform would do more to help their competitor than iOS.

There would certainly be value to the Android platform to support iOS app, not only because are there more iOS apps but because they have a reputation for greater polish and beauty than Android apps. Since Android is open source, it's possible that the community of Android developers would get together, port GNUstep, reimplement the libraries an iOS app would need, and make it freely available. The work involved in that effort is, as previously discussed, pretty significant, making such development somewhat less likely to succeed. As for Android hosting WebOS apps, it is similar to the relationship between iOS and Android in that it would be more likely to help WebOS than Android.

WebOS, meanwhile, has a distressing shortage of apps. With such a small market share, it's been hard to attract developers to the platform, and the lack of apps is at least partly to blame for continued poor market share. HP's play to put WebOS on PCs may help that, but for now WebOS could benefit significantly from any additional apps it can get. Reimplementing the iOS libraries would be prohibitively expensive, but it isn't too far-fetched to imagine Android apps running on WebOS. Much of the technology is similar (Linux underneath, similar notification systems) and the parts that are different are available as open source. WebOS could become a very pleasant way to run Android apps. Even better, WebOS's unique features, Synergy and Touchstone, could be made available via additional Android APIs and encourage Android apps that only run on WebOS. For those who are interested in history, this is nearly identical to Microsoft's Windows-specific Java APIs that was ultimately considered a monopolistic abuse (see Breaking Java's Portability). In this case, however, HP and WebOS hardly have monopoly power to abuse.

Final Thoughts

I don't really think that HP will support Android apps on WebOS. Despite the ease with which they could, the ongoing support costs might not make it worth it. There is also the opportunity cost of porting the Android runtime rather than improving WebOS itself. I think it has the potential to be a great way out of the chicken and egg problem of attracting app developers and market share. They could even work with the Amazon Android App Store to offer a more curated set of Android apps, possibly avoiding the problem Android app marketing has of the userbase being largely unwilling to pay for apps. If HP can frame it as a bootstrapping opportunity instead of a betrayal of "native" WebOS app development, it has real potential. I won't place bets on whether it will come to pass, but I'd like to see WebOS get a little push toward success. Enjoy!

Update 2011-02-11! I should have considered the Blackberry Playbook as a host platform. Looks like RIM may be planning to support Android apps on the Playbook.