The Localytics Blog

Smartphone OS Wars: What platforms to develop for? Part II (Technology perspective)

Deciding which platform to develop on is not only a business decision (as described in Part 1) but also a matter of what technology is right for the project. Each platform provides a different set of tools and development concerns for the application programmer.  Below is a brief discussion of the major technology differences between the platforms which are relevant to a developer:

Part II: The Tech Perspective

iPhone
iPhone is well rooted with its sleek UI builder and clear design guidelines.  It is is based on OSX, which means many developers will be familiar with it.  Still, users are feature fickle and wait with baited breath for missing capabilities such as background application abilities similar to those found on Android, Blackberry, Symbian, Windows Mobile, or the Pre.  The iPhone 3.0 software update, released June 17, does include a workaround if your goal is to communicate with users even when your apps is not on.  The new Push Notification System allows developers to send notifications via Apple’s server in the form of text, sound, or badges with less networking and processing (and thus battery) overhead.  The change is great for users, but something of a headache for developers who implement this, as they must setup servers that can communicate with Apple’s.  Developers also still struggle against Apple’s sometimes seemingly arbitrary approval process, with denial or approval resting on the judgment of the reviewer.

Android
Android has had a slow start, but looks poised to jump into the game.  The Linux-based OS developed by Google and later the Open Handset Alliance provides full J2SE and useful Google-related API’s, but in some cases doesn’t include full documentation.  Developers must also contend with the unique way Android handles the application life-cycle, with frequent data destruction and recreation when the phone changes states (for example when the users switches between vertical and horizontal orientation).  There is also the concern of breaking changes caused by new updates to the OS, making application maintenance difficult.

BlackBerry
BlackBerry has maintained backwards compatibility, so old apps will run fine on newer hardware.  Apps are built with only J2ME and a handful of libraries provided by RIM making it difficult to create a very rich application experience.  Many different hardware configurations mean that BlackBerry applications must be designed and tested for a host of different resolutions, input methods, and OS versions.  Both the BlackBerry JDE (Java Development Environment) and the associated Eclipse plug-in have their share of bugs and quirks lengthening developer ramp-up time.

Symbian
Internationally prevalent, Symbian apps can be developed from different directions, using either native or managed code.  The phone is designed to be resource efficient for effective multi-threading.  Unfortunately, the side effect is a high learning curve for developers, and there is debate how effective this specialized resource management really is. Symbian supports a variety of UI toolkits, S60, UIQ, and QT.  S60 and UIQ address different phones and QT which is supported across a variety of PC, mobile, and embedded platforms.  There was also fear of unauthorized software being executed on phones, which lead to Symbian 9 requiring software to be digitally signed; otherwise, you are locked out of most core OS features, which is yet another headache for developers wanting to push out software.  However, Symbian is pushing Flash, which could allow quicker development and good cross device compatibility.

Windows Mobile
Like Symbian, Windows Mobile runs either managed or native code.  It’s windows based, which makes it comfortable to work with for many developers.  It also is supported by Microsoft’s useful .NET Compact Framework.  Complaints against Windows Mobile are that it’s UI is old and clunky, lacking the shine of the newer phones (an overhaul isn’t scheduled until 2010) and the new app store won’t be compatible with the current versions of Windows Mobile.  An advantage of Windows Mobile is that the platform aims to be as open as the desktop OS and provides easy access to all of the device and OS features.

Palm
The newest contender, Palm, released the Web OS based Pre on June 6th.  There’s no open SDK yet for developers, but there is a lot of tech buzz about the phone.  It runs on a Linux environment and seems almost playfully open (enabling developer mode involves entering the Konami code) to software modding and 3rd party apps.  While the pre does not currently support Flash, it is expected to receive it before the end of the year.  There are concerns about the overall growth potential, with neither Palm nor Sprint (their go-to-market partner) doing particularly well financially.

Hi,
Managed code (.NET CF) as opposed to the native one is the term of Windows Mobile and is not usually associated with Symbian.
You probably meant J2ME as a managed environment on Symbian?

Hi Eugene,

Thanks for pointing out that I was slightly confusing there.  What I was implying was that while J2ME is not as feature rich as Android’s J2SE, it is still Java which is managed code (runs in a virtual machine instead of natively on the device).  As a result it allows for rapid application prototyping / development.

I felt that the fact that Symbian developers have the option to use Java OR their variation of native C++ was a plus for Symbian because it opens the doors for developers. 

Windows Mobile supports a compact version of Microsoft’s CLR which is a managed platform.  Granted, when paired with the surprisingly extensive .netcf libraries this is more powerful than using J2SE on a Symbian device. 

So, both Windows Mobile, and Symbian support managed and native code which I thought was a plus for both them.  This is compared with Android and BlackBerry which are managed-only, and iPhone which is native only.

“new app store won’t be compatible with the current versions of Windows Mobile”

This is everybody is missing, that developing for MS’s App Store means you are developing for a system that has an install base of ZERO.  Because MS never had the balls to fight either the cell-phone manufacturers or the carriers to require users to be able to upgrade the installed OS.