Mobile platforms

by Tim Anderson

Deployment to mobile clients is becoming increasingly important, but which platforms do you go for?

HardCopy Issue: 55 | Published: February 1, 2012

The trend towards mobile is gathering pace. Gartner reports worldwide mobile device sales up 5.6 per cent in the third quarter of 2011, to over 440 million units with around one third smartphones. In the same quarter, the analyst firm reports a decline of 11 per cent in PC sales in Western Europe. Separate reports show tablet sales of over 60 million units in 2011, most of them Apple iPads.

Meanwhile, according to a November 2011 survey conducted by PHP specialists Zend, two-thirds of PHP developers are working on mobile development. Mobile platforms are now firmly in the mainstream, and it is traditional PC applications that look more like a niche area.

Despite, or perhaps because of, tumultuous growth, the world of mobile development is far from settled. In the PC era you could develop for Windows and be sure of hitting most of the market. Mobile by contrast presents difficult choices. Is it better to focus on native code for one or two specific platforms, or to take a cross-platform approach using HTML5 or one of the cross-platform toolkits, or to concentrate on mobile-friendly Web applications rather than apps?

Plane Finder App

UK developer Lee Armstrong, who has his Plane Finder app on iOS, Android and Windows Phone, found iOS sales around ten times greater than Android when he studied his figures for December last year, while Windows Phone barely registered.

One thing that is apparent is a consistent theme of Google Android and Apple iOS dominance. In the influential US market, Nielsen research reported Android and iOS at 52 and 37 per cent smartphone sales respectively in the fourth quarter of 2011, leaving just 6 per cent for RIM Blackberry and 3.8 per cent for Windows Mobile and Windows Phone 7 combined. The worldwide market is more diverse, though Android still dominates. Gartner reports a 53 per cent worldwide market share for Android smartphone sales in the third quarter of 2011, followed by Symbian at 17 per cent, iOS at 15 per cent and RIM at 11 per cent. Apple won a bigger share in the fourth quarter after the release of the iPhone 4S.

While Android is ahead in hardware numbers, Apple takes the lead if you look at another important metric: the app market. Research firm Strategy Analytics reports a 54 per cent market share for Apple versus 27 per cent for Android in 2011. Individual developers also say that iOS is the most profitable platform.

In the tablet market, analyst firm IDC gives Apple a 62 per cent market share for the third quarter of 2011 and Android 33 per cent. Android’s share should grow, thanks to the launch of new mass-market devices like Amazon’s Kindle Fire, but Apple has a strong hold and will likely have new models of its own in 2012.

Another complication is that the Android market is fragmented. Amazon’s Kindle Fire runs Android, but with several gotchas if you want to target other Android tablets as well.

The mobile app revolution has been mainly consumer-driven, and the market may look different in the corporate world. Microsoft should have an advantage as it integrates with its Enterprise stack based on Windows Server, Exchange and SharePoint; but Apple is already making inroads as employees find iPads perfect for meetings, presentations and more. The impact of the tablet-friendly Windows 8 is another unknown.

However you look at the figures, no single platform will dominate mobile in the way that Windows has dominated PCs – unless it turns out to be HTML 5. All the smartphone and tablet platforms have strong browser engines, usually based on WebKit, the open source project used by Apple Safari and Google Chrome. “WebKit has become the de facto [standard], which has really been driven by Apple and Google and against Microsoft. That’s driving HTML5 forward,” said Jeff Haynie, CEO of mobile tools company Appcelerator.

So there are three broad approaches to developing for the mobile client. First, you can do a native application for each platform, using the primary native toolkit for each. That means Objective-C for Apple iOS, Java for Google Android, Silverlight for Windows Phone 7 and so on. The advantage is that you get the experience on each platform, but the disadvantage is that you have to keep several independent projects synchronised. Minority platforms suffer because of the small payback for the investment in code.

Second, you can use a cross-platform toolkit. These are numerous, with some of the best-known being PhoneGap, Adobe AIR (based on Flash), and Appcelerator’s Titanium. These toolkits let you maintain a single code base, with some conditional code for specific platforms, and compile them into native apps.

The third option is to avoid locally installed apps completely and to rely on HTML 5 Web apps. Local storage is still possible, and there are emerging standards for access to device hardware such as the camera and GPS (Geographical Positioning System). In fact these last two options are less distinct than they first appear. PhoneGap works by putting a native wrapper around a browser control, so that you still code in HTML and JavaScript. Titanium may also use the local JavaScript engine.

Martin Fowler, Chief Scientist at developer company ThoughtWorks, is doubtful about the value of cross-platform toolkits. “I think cross-platform mobile toolkits are a dead-end,” he writes. “It’s just too hard for them to really mimic the native experience. If it’s worth building a native app, it’s worth building it properly, including an individual experience design for that platform.” He considers Web applications a better option if you need cross-platform code.

The issues are complex. Web apps are hard to monetise, whereas users are more likely to pay for a native app, even if it was created by a cross-platform toolkit. Further, some cross-platform toolkits let you get close to the appearance of a true native application. “We wouldn’t really describe ourselves as cross-platform. We’re really an API that allows you target multiple different devices,” says Appcelerator’s Haynie.

iOS Devices product shot

Apple’s iOS powers a range of popular devices including iPad and iPhone.


The Apple iOS Platform

Apple’s unique approach to mobile is based on vertical integration, or what is less kindly called lock-in. Apple manufactures all the hardware and keeps the operating system patched and up to date, rather than leaving this to the whim of operators. Developers get a consistent target, but with constraints on how apps are developed and deployed.

Apple’s position is that you should either use Objective-C and its Cocoa Touch frameworks, or else create a Web app that runs in the browser. Runtimes such as Java and Flash are not allowed, though the company did step back from an outright ban of cross-platform development tools. App deployment must be through the App Store, with a 30 per cent cut going to Apple unless it’s an internal corporate rollout where private deployment is possible, or for developer testing and debugging.

Getting started with iOS development is a matter of signing up with Apple, paying a yearly subscription (currently $99 per year) and downloading the Xcode IDE and iOS SDK. This includes an emulator for debugging your iOS apps. You do need to develop on a Mac, which can be a nuisance if you also use Windows tools.

Xcode screenshot

Developing for Apple iOS with Xcode.

Objective-C has a mixed reputation, but although it lacks some of the features which C# or Java developers enjoy, it is a productive language and not excessively verbose. Xcode 4.2 introduced Automatic Reference Counting which means that objects are automatically disposed, removing some of the memory management burden. There are a few annoyances. Xcode has a strong visual designer but many developers avoid it because doing layouts purely in code is more flexible. It is a shame not to have the kind of two-way tools seen in Embarcadero Delphi or Microsoft’s Visual Studio.

Another long-standing issue is the lack of namespaces. The mechanism for avoiding name collisions is to use your own class prefix, which is not robust or elegant. On the plus side, the GUI objects in iOS are beautifully designed, and competently written applications generally perform well. The popularity and consistency of the development platform means a large community to draw on for help.


Developing for Android

Google Android is primarily a Java platform with a difference. Your Java code is compiled not to Java bytecode but to Dalvik Executables, Dalvik being the name of the Android virtual machine. Oracle claims that Google infringed Java copyrights and patents in Dalvik, and this is the subject of litigation but has not stopped Android’s remarkable growth.

However you choose to develop for Android, you will need the Android SDK. This includes an SDK manager which then enables you to select which platforms you want to support, as well as optional packages. The SDK also installs the Android emulator.

The next step is to set up a development tool. The standard for Android is an Eclipse add-on called the Android Development Tools (ADT). This is a plug-in for a standard Eclipse installation that has been set up for Java development. The latest version includes a graphical UI designer as well as editing and debugging support.

One of the advantages of Android is that it is easy to debug on a connected device as well as on the emulator. You have to configure your device to allow USB debugging, and to allow installation of non-Market applications.

Android looks good, with huge market share, a familiar language and what is now a mature development environment. The downside is that it is a little bit chaotic, with numerous device profiles, a Market that is less compelling than Apple’s offering, and some Android devices not able to use the official Market at all. Android devices must pass official compatibility tests and be approved by Google in order to access the Market. Google’s statement on the latter point is vague: “Unfortunately, for a variety of legal and business reasons, we are not able to automatically license Android Market to all compatible devices.”


Targeting the Kindle Fire

Amazon’s Kindle Fire is a budget-priced tablet running Android 2.3.4 (‘Gingerbread’). It has a colour display of 600 by 1024 pixels and 512MB of memory. Although it runs Google’s operating system, Amazon has made the Kindle Fire its own, driving users to Amazon’s app store and services rather than to the official Android Marketplace.

That said, developing for the Kindle Fire is like developing for other Android tablets, but with a list of things that you cannot do. The no-go list includes Google Mobile Services, gyroscope, camera, Bluetooth and GPS. In-app purchasing is only allowed through Amazon’s payment system, support for which is in beta.

One benefit of the Amazon ecosystem is that it hooks nicely into Amazon Web Services (AWS), a rich cloud platform including virtual servers, online storage, database access and application services such as message queuing and notifications. The AWS SDK for Android includes libraries and code samples for all these services. There is also an SDK for iOS so that you can use the same server code to support apps for iOS, Kindle Fire and other Android devices.

Amazon has done a better job of hooking Kindle Fire users into its ecosystem than Google has done with Android in general.


The RIM BlackBerry

RIM has suffered declining market share in the face of the iOS and Android onslaught. It has responded by evolving a new platform to include touch-controlled tablets as well as smartphones, and in April 2010 announced the acquisition of the embedded QNX operating system from Harman International. The first QNX-powered device was the PlayBook tablet, launched at the end of 2010. BlackBerry smartphones still run the older BlackBerry OS, updated to version 7.0.

RIM Ripple Emulator screenshot

RIM’s Ripple Emulator lets you test and package WebWorks apps, including the ability to simulate the accelerometer and GPS.

In October 2011, RIM announced a new operating system called BBX, really a rebranding of the PlayBook OS, which will be used for both smartphones and tablets. BBX will support apps built with native C/C++, Adobe AIR and HTML5, or it can run Android apps using a BlackBerry runtime.

That sounds confusing, especially as BBX devices are not yet available. However RIM is focusing on HTML 5 and a framework called WebWorks (originally BlackBerry Widgets) which targets all three platforms: BlackBerry OS, BlackBerry Tablet OS, and the forthcoming BBX. WebWorks uses the WebKit browser engine so you develop your app with Web technologies, supplemented by JavaScript wrappers for device APIs.

RIM’s biggest challenge is to keep pace with the wider mobile market. BlackBerry Enterprise Server and strong Exchange integration is no longer enough. “RIM and Microsoft are fighting for third place. I would go long on Microsoft,” commented Jeff Haynie at Appcelerator.

The significance of Microsoft Windows 8

Microsoft’s Windows Phone platform, which was meant to recover ground lost by Windows Mobile, has so far failed to grab much market share despite praise from reviewers, and despite offering developers a strong and familiar development platform with Visual Studio and Silverlight. The company is not giving up though, and Nokia’s partnership with Microsoft and launch of new devices have given the platform a much-needed shot in the arm. Is it too late though, with users seemingly content to choose between iOS and Android?

Windows 8 UI screenshot
Metro-style Windows 8 is Microsoft’s big hope in the mobile market.

This is open to speculation, but there are a few reasons why Microsoft’s mobile platform may yet be significant. PC sales, though still huge, are flagging and Microsoft knows that it must find a way to compete with the iPad and iPhone. Windows Phone 7 was the first attempt, but an even bolder step is to come, in the form of Windows 8. Microsoft has taken the blocky Metro design of Windows Phone 7 and applied it to Windows itself in the form of a touch-friendly new platform that is baked into the next version of Windows, as an alternative to the traditional Windows 7 user interface. Further, Windows 8 will run on ARM as well as on Intel x86 processors, enabling cheaper, more power efficient tablets. A Windows 8 tablet will be nothing like the Windows Tablet devices we have seen in the past.

The Windows 8 developer platform is based on a new Windows Runtime (WinRT). The goals of WinRT include sandboxing apps so that they cannot infect or bring down the operating system, and forcing developers to use asynchronous APIs for all slow-running calls so that apps remain responsive.

WinRT supports three development models. The first is HTML and JavaScript, using JavaScript libraries for access to platform-specific features. The second is .NET, with the user interface in XAML, the design language of Windows Presentation Foundation and its cousin Silverlight. The third is native C or C++ code. All three perform well.

WinRT is a new platform, though it has some elements in common with Windows Phone 7 including the .NET runtime, XAML for the user interface, and the overall Metro style. Although Microsoft has not said so, it seems likely that WinRT will also come to a future version of the phone, unifying the two platforms.

What this means is that the long-term fate of Windows Phone is linked to the success or failure of Windows 8, and in particular its new Metro side. If Windows 8 Metro is a hit, that success will lift Microsoft’s Smartphone as well.

Going cross platform

In the fragmented world of mobile devices, one mitigating factor is that all recent smartphones and tablets come with high performance browser engines, including fast JavaScript runtimes. Many cross-platform toolkits exploit this, with the best known being PhoneGap. Using PhoneGap, you write your application in HTML and JavaScript, and then package it with a native wrapper so it can be deployed like any other native application. Further, PhoneGap includes cross-platform JavaScript APIs for device features including the accelerometer, camera, GPS, storage and network. PhoneGap supports iOS, Android, BlackBerry OS, HP’s near-abandoned WebOS, Microsoft Windows Phone 7, Symbian and Samsung Bada.

PhoneGap was developed by a company called Nitobi which has been acquired by Adobe. It is an open source project though, and has been contributed to the Apache Software Foundation where it is currently an incubation project. This open approach has won PhoneGap support from many companies. IBM, for example, promotes PhoneGap as a way of building clients for its WebSphere application server.

Sencha Touch is a JavaScript app framework aimed at mobile enterprise developers. “Sencha Touch is designed to let you do anything you could do with Cocoa touch, or an Android SDK, or a Windows Mobile SDK,” CEO Michael Mullany told me. “Its intent is to equip you to develop native quality experiences with native style interaction.” Data integration is another priority, with data binding to a variety of sources and support for local storage. A Sencha Touch app can be browser-hosted, or converted to a native app using PhoneGap.

Another notable cross-platform toolkit is Appcelerator’s Titanium. Titanium also uses JavaScript, but instead of a user interface composed using HTML and CSS, it uses native controls. The consequence is that you have more fidelity to the look and feel of the operating system, but there may also be more work to do customising the app for each platform.

Adobe also has a cross-platform mobile development solution, based on the Flash runtime and Adobe AIR. The company successfully side-stepped Apple’s ban on Flash by creating a packager that bundles it into each app. This has now been extended to Android as well. Considering the strength of the Flash design tools, along with Adobe’s Flash Builder IDE for developers and middleware platform to connect to application servers, this is a compelling offering. That said, Adobe states that its future strategy is now focused more on digital publishing and HTML5 than Flash, raising doubts about the future of AIR for mobile.


Microsoft Windows Phone

Microsoft has two Smartphone platforms, both built on Windows CE but very different. The old Windows Mobile supports development in C++, or with .NET using C# or Visual Basic. You will need Visual Studio 2008 or earlier, as it is not supported in Visual Studio 2010. Although Windows Mobile is pretty much obsolete, some businesses still find it useful, particularly if they have existing applications to maintain. It is also a more open platform than Windows Phone.

Nokia Lumia product shot

Nokia’s Lumia range of Windows smartphones has reinvigorated Microsoft’s phone OS.

The new Windows Phone platform uses Microsoft’s Metro design style and is the outcome of intense usability research. The development platform is .NET using Silverlight or XNA: only phone manufacturers and telecom operators are allowed to use native C or C++.

Visual Studio 2010 (either the free Express version or the full version) forms an excellent development environment for Windows Phone, though the complexities of managing state when your application can be shut down at any time take some adjustment if you are familiar with desktop Windows. An emulator is provided, or you can sign up as a developer for $99 and debug on an attached device.

The ‘Mango’ update to Windows Phone in Autumn 2011 substantially improved the platform. Silverlight was upgraded to version 4, background tasks introduced, a local database added, the mobile browser was upgraded to Internet Explorer 9, and more.

This is technically a strong platform (though it still lacks C or C++ development) but the main concern among developers is the small size of its installed base. Nokia’s entry into the market is helping, but whether it can really carve substantial market share away from iOS and Android is still an open question.