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:
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 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 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.
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.
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.
The newest contender, Palm, released the webOS 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.