I’ve had the opportunity to develop on both the iOS and Android platforms, something that, statistically speaking, makes me part of a minority of developers. My experience has been that the iOS platform offers better tools for developers, but that the Android platform offers more freedom in what a developer can do with a device. I thought I’d share some of my observations on the differences between the two platforms for anyone who is curious what its like developing for the other device.

The Development Tools

iOS Dev Tools

The main development tools for the iOS platform include Xcode, Interface Builder and the iOS Simulator. Xcode has always seemed like a very polished and well put together tool and I enjoy working with it. Some of the features that stand out for me include:

• The workspace is customizable: the available buttons and hotkeys can be set to the developers preferred workflow.
• Excellent support for customizing syntax coloring and highlighting to suit the developers preference.
• It has excellent code completion.
• Projects are managed at the folder level making it easy to move folders around to share or reorganize your dev environment.

My only serious complaint about Xcode is its historic lack of a tabbed interface for opening multiple documents at once, although this feature may finally be included in the soon to be released Xcode 4.

Interface Builder is Xcode’s UI design tool. Instances of UI elements and their associated actions are defined in code and then linked to their visual counter parts in Interface Builder. Interface Builder also supports custom objects so the developer is not limited to just the stock iOS controls and classes.

The iOS Simulator is used or testing an iOS application. The Simulator can run either as an iPhone or iPad, requires very little configuration and launches very quickly. The Simulator can be launched with various Instruments to assist in debugging, showing memory usage, object allocations and memory leaks, among other things.

Android Dev Tools

Development for the Android platform can be done with just the command line tools that come with the SDK plus your text editor of choice, but I chose to use Eclipse plus the ADT plugin.

I’ve used Eclipse since version 3.3 (Europa) and while the IDE has made great improvements in stability and speed its still a little hit or miss for me. For example, Flex Builder is built on top of Eclipse and I have very rarely had problems using it. On the other hand, Eclipse 3.5 (Galileo) only worked well for me when I limited the number of installed modules. As I would install new plugins to expand the capabilities of the tool it would begin to feel clunky and occasionally certain features would just stop working. Version 3.6 (Helios) was recently released and I’m hopeful I’ll see better performance in the new version (just as soon as all the plugins I use are upgraded as well).

Quirkiness aside, Eclipse has been an adequate tool for Android development. While it doesn’t really shine, I still prefer it over the command line tools. Some of the things I like about Eclipse include:

• Tabs!. I know you aren’t surprised when I say my favorite thing about the Eclipse IDE is its support for opening multiple documents in tabs.
• The workspace can be customized to display a variety of different panes that, in addition code, show a code file outline, a file browser, console and debugging information, etc.
• I really like the ability to hold down the the control/command key and click on a type, an instance name, or method and jump directly to its definition.

Sadly, I have more criticism than I do praise:

• Configuring syntax coloring has been a dubious and tedious exercise in the past. Its just so hard to get things to look just right.
• Projects are confined to a “workspace” location on the file system and can not simply be moved around to the developer’s liking. This places constraints on how you organize your dev environment’s folder structure.
• Eclipse has been a memory hog at times, 3.5 (Galileo) less so than previous versions but I still find that it becomes slower over time and I typically restart at least once a day to reclaime responsiveness especially if I’m switching between the java editor and the XML editor frequently.
• Eclipse takes a long time to launch, making it a poor choice of tool for making a quick edit to some random file.

The Android platform lets the developer define layouts via XML markup and the ADT plugin includes a lackluster GUI tool for those that don’t want to write the XML by hand. I’ve barely used this tool, it was so bad. It was much easier for me to just write the XML (code hinting is supported). However the XML editor’s validation mechanism has a bug that occasionally incorrectly reports an XML syntax error that has to be manually cleared.

App testing is done via an emulator that comes with the SDK. The developer must first define one or more virtual devices configured to match a particular screen size/density and version of the Android OS. Afterward, the virtual device can be ran in the emulator. The emulator doesn’t look as polished as the iOS Simulator, it launches slowly and its performance some times lags. As of this writing there are bugs with the emulator that sometimes prevent it from making an HTTP connection and it occasionally detaches itself from the debugger. When either of these happen I’ve had to restart Eclipse to get it working correctly again.

Winner

Between the two platforms, Xcode wins hands down as the more friendly dev environment for me. Others have even gone as far as configuring Xcode for Android development.

Documentation and Support

Both platforms provide copious amounts of documentation for its tools and SDK. I’ve found that the iOS documentation seems to provide more by way of examples and recommended usage than the Android documentation. However, the source code for the Android platform is freely available and incredibly useful depending on what you are trying to accomplish.

Both platforms have excellent developer communities to turn to when documentation fails. Nearly every question unanswered by the official documentation has been answered by the communities on stackoverflow.com or in sample projects shared on github.

Actual App Development

iOS applications are developed in objective-C using the Cocoa framework. Android applications are developed in JAVA with a subset of the standard JAVA libraries (as I understand it). I’ll go ahead and mention here that Objective-C class requires a separate declaration for its interface, and its implementation and that these are placed in separate files by convention. JAVA classes do not require a separate declaration for its interface and implementation and are written in a single file (along with any nested classes they might have). My experience has been I write less code for an Android app than I do a similar iOS app, partly for this reason.

These differences aside the difference in approach to application development between the two platforms is striking.

Apps and Activities

iOS applications have an AppDelegate that acts as the main application class. The different screens the app presents to the user are comprised of UIViewControllers that manage one or more views. An AppDelegate can manage multiple UIViewController instances at the same time and UIViewControllers can instantiate other UIViewControllers. The developer has very granular control over the view stack and can change the navigation order of views in the stack on a whim.

Android applications have no concept of a single application class controlling what is presented to the user. An Android application is a collection of loosely associated Activities that are more like self contained mini apps. Activities with a common purpose can form a Task but only one Activity has focus at a time (does any work). As a user navigates through the app, Activities launch other Activities via a kind of messaging system called an Intent. Old activities either remain in the history stack or are marked finished and removed, but the history stack cannot be whimsically manipulated by the developer. Actually getting a reference to an instance of an existing activity (other than the current one) can be challenging, simply because Android apps are not designed to work that way. Finally, Activities can be shared between applications making it possible to leverage existing functionality and incorporate it into your own app.

You could say that iOS apps are application centric and Android apps are more like loosely bound services. Coming from an iOS world, the Android approach to Tasks and Activities took some getting used to.

Navigation

I touched on navigation already but I want to go into a little more detail.

Navigation in an iOS app is typically achieved via a UITabBarController that presents a tabbed interface, or by adding and removing UIViewControllers to the history stack of a UINavigationController. The stack of the UINavigationController can be prepopulated by the developer so several screens are already beneath the current UIViewController when its displayed. A UITabBarController displays a different UIViewController for each of its tabs. Each UIViewController can have its own UINavigationController making it possible to navigate multiple screens from within a single tab. Taken together the iOS offers very robust navigation options.

The Android platform has no native analogue to the iOS UINavigationController, but it does have something similar to the UITabBarController called a TabActivity. A TabActivity presents a tabbed interface and each tab displays a different Activity when it is selected. Other Activities can be launched from the Activities displayed in the tabs but the new activity does not load within in the tab. Instead it replaces the TabActivity at the top of the history stack. The developer can alter this default behavior with a little work and replace the activity in the tab with the activity being launched, but even this does not approach the flexibility offered by the iOS navigation options.

Background Processing

Beginning with iOS 4, Apple introduced an app switching feature that allows a user to switch to a new app without first having to completely shut down the old app. Additionally, an API was made available to allow a handful of services, such as audio, to continue running in the background even when their parent application was not the one currently in use. These limited background processing and app switching features were welcomed by the iOS community but still fall short of what is available to the Android platform.

The Android platform is much more open when it comes to running background processes. Developer’s can define their own Services to run in the background, even when their parent app is not currently in use, and these services can be shared across Activities. App switching has always been supported on the Android platform. When an app is sent to the background it is kept around at almost no cost to system resources, allowing the user to pick up right where they left off when they return to the app.

Sharing Data

Sharing data between screens is a common task for each platform. Both platforms offer a simple shared preferences feature, both platforms offer a data storage option like SQLite, and both platforms offer notification broadcast mechanisms. Aside from these options, iOS apps can share data directly between UIViewControllers by setting properties or passing parameters to method calls, something that Android Activities cannot do. Android Activities can share data by setting and reading properties on a global application object (a simple class that does little more than act like a state machine) or by formatting the data into a Bundle object and passing the Bundle via an Intent. Another option is to share data by reading and writing to the file system, something that the iOS platform does not currently support.

Memory Management

Memory must be managed in iOS apps. Object instances must either be committed to an autorelease pool, or explicitly retained and released by the developer at the appropriate times to prevent memory leaks or execution errors from reading bad memory.

Android apps are written in JAVA and enjoy the benefit of the JAVA garbage collector, greatly simplifying memory management over Objective-C.

UI Design

A few key difference in the UI design between the two platforms is the fact that most Android devices have a physical back button, menu button and search button, freeing up screen real estate for other considerations. The Android platform supports a concept of themes and styles that can be applied globally, and the creation of Home Screen Widgets, small representations of an app that provide minimal functionality outside of the app proper. These are things that the iOS platform currently lack.

Most of the UI controls on one platform have counterparts in the other, buttons, images, and webviews, but I want to point out that the Android is seriously lacking a ListView control that is as robust as the iOS UITableView. The stock Android ListView control can manage a single list where an iOS UITableView can be configured as a grouped tableview and display information from multiple lists with relative ease. The Android open source community has tried to fill this gap with varying degrees of success, but to me, this is a glaring absence in the Android SDK.

Handling Multiple Screen Sizes

Both platforms provide techniques for writing a single app that can support multiple screen sizes and resolutions.

iOS lets the developer define different views for iPhone vs the iPad to create a hybrid app. There are naming conventions for image assets to target different devices and screens and support or pixel doubling to scale up images if necessary.

The Android supports 9patch png images for graceful scaling, and developers can specify image assets and other XML based drawables for low, medium and high resolution screens. The Android supports the concept of device independent pixels (dp) that are scaled depending on screen size and density.

Distributing

iOS developers may love their platform with fervor, but I’ve never met one (myself included) who didn’t have a gripe about Apple’s draconian code signing and app submission process. There are plenty of horror stories, some are probably famous, so I won’t go into them here. Still, as horrible as the app signing, submission and approval process can be, the iTunes App Store is an excellent experience, easily searchable and always fresh.

The Android experience is a polar opposite. Code signing on the Android is a breeze by comparison and does not require a complicated certificate exchange process. Apps can be self-signed via the Eclipse export wizard. Its just that simple. The Android Market place on the other hand has been a disappointment for me. The experience from an Android device is adequate but not as good as the iTunes App Store is from the iPhone, but the web based experience is simply horrible. Where you can search and browse iPhone apps over the web and see a “preview” page that looks about the same as the page in the iTunes App Store, the Android Market on the web is not even easily searchable. I have to wonder what the world’s largest search company was thinking when they designed it. A revamped and improved Android Market is rumored to be due with the release of the 3.0 OS and will hopefully make it a competitor to the iTunes App Store in user experience

Summary

I enjoy both platforms, both as a consumer and as a developer thought I think I favor the iOS slightly, perhaps because its where I started. If you would like to get a little more hands-on exploring the differences between the two platforms, an excellent way might be to download and compare the source code for the WordPress iPhone and Android applications. Both are open source and available from wordpress.org. And of course these are just my thoughts, you may or may not draw a similar conclusion.