I’ve had the pleasure of working on two side-by-side streams of development for the same app on two different platforms since January 1 – the new TweetPhoto applications for the iPhone and for the Android (see screen grabs below).
First of all, let me say that from a developer perspective, I’m one of the most platform agnostic people you’ll find anywhere. My philosophy is that money is green, spends the same anywhere, and if someone wants to build something on their favorite platforms of choice and needs someone to develop for them, then that platform is now my de facto “favorite development environment ever.”
Fact is, if one sticks around long enough, you outlive whole sets of tools, operating systems, and methodologies. That certainly has been true in my career; while I lovingly still have my IBM 360 yellow book and can still recognize a fair subset of Hollerith on sight, it’s almost as embarrassing as watching The Who play the Super Bowl to talk about it.
Wandering sidebar aside, the past six weeks have given me a fantastic opportunity to compare iPhone and Android, side by side, on the same problem set and see how the two environments stack up.
There are things about each SDK I really like… and there are things I really dislike equally.
In fairness, my experience on the iPhone SDK is much more extensive than on Android.
Even so, putting together the exact same feature set on the two platforms points out where one platform shines over the other in terms of ease of implementation and execution.
All of the opinions below are 100% subjective and are my own. If you have a contrary opinion, fine. I don’t care. Call a talk show or write your own post.
For the iPhone, you really only have one choice for developing apps – XCode. For Android, I chose to use Eclipse and the Android plugins for Eclipse.
The Apple experience is tight, feels integrated out of the box, and just works. The iPhone emulator is fantastic and works almost like the real thing.
Eclipse, since it is the Swiss Army Knife of Java Development, is not as integrated – out of the box – as XCode with regard to it’s Android implementation. The Android Eclipse plug ins work great and are powerful. I really dig Eclipse’s “Quick Fix” feature for including imports I need and recommending ways to fix broken code. What I don’t dig is starting and re-starting the various emulators when trying to debug a running Android app. Which I did tens of times each day when Eclipse lost full connection with the emulator I happen to be running.
Even so, I found the tools for controlling the features of the emulator (or should I say, emulators – you can configure an emulator AVM for each targeted device type and OS level you want) on Android to be much more powerful than the control one has – or doesn’t – over the iPhone emulator.
In a nutshell, someone proficient with Eclipse and who is a half-way decent open source / Java developer – who has never developed a mobile app – will be able to jump in and crank out working code quickly. Apple, especially to a newcomer to Objective-C, is a pretty tough slog for the beginner.
Honestly, it took me about six weeks before I really felt a mastery over Objective-C. From a standing start to finished app, it took me under three weeks to develop a professional grade Android app. Enough said.
Getting Apps to Devices
The whole process of getting certificates, creating provisioning profiles, and the whole Apple approval process is pretty daunting to a newcomer. Remembering back to when I first started to developing iPhone apps, and the time it took me to get up and sprinting, Apple’s setup is a pretty damn big barrier to entry. Heck – I still run into provisioning and certificate problems switching between developer accounts when developing for multiple customers on the same development system.
Without going through the Apple App store, your only option is to use Ad Hoc provisioning, which limits you to 50 devices per Ad Hoc provisioning profile and you have to collect device UUIDs to make it work. Factor in having to distribute new profiles each time a new device is added to keep everyone in sync and it quickly can become a real pain, especially if many QA testers are involved in a project.
For Android, you basically sign a .apk file and you’re off to the races. You still have an approval process to get on Android Market – the analogue to Apple’s App Store – but there is absolutely nothing standing in the way of you distributing your app on your own without Google standing in your way.
Advantage to Google on this. It’s worlds easier to get an app out and onto devices under Android than iPhone.
SDK Feature Comparisons
OK. Getting the nuts and bolts of making apps for each platform behind us, let’s take a look at how coding for each device stacks up.
Documentation: Android’s documentation is there… but woefully lacks useful examples in a place handy to the API call I want to make. My least favorite sentence to read in any discussion / support forum of any ilk is “well, if you check the sample apps, you’d see…” You know what? I don’t have time to read every line of every sample application. You want to see an easy to use document with ready-to-use sample code should be done? Look at the PHP.net site. It should be that easy to see how to use API calls. Apple is not much better in this regard, but on the whole the iPhone is documented much better than the Android developer site. But I’m not a huge fan of either, truth be told.
And while I’m screeding here (is that the proper pluperfrect subjunctive?) let me just say that it’s a good thing that Google exists, because I had to Google a shit-load of example code from about a hundred different places for stuff that should have been trivial to find – but wasn’t. Like camera operation. See the next section.
Using the Camera: The iPhone has a well documented interface for using it’s phone, and for selecting photos from it’s library – the image picker. Android doesn’t have a pre-packaged all-in-one interface for doing this. There is a bare bones example of how one ties into the camera, and a poorly documented – as in I had to find the solution in the wilds of the interwebs – of how one browses the camera’s gallery for photos already taken.
Let me go on the record as saying that in terms of overall code, it took a lot less code to do camera operations under Android than it did under Apple to do the same task – but that for Apple, it took me maybe two hours to get right while under Android it took me the better part of a weekend to find the right solution, and found somewhere other than on the Android developer site. The image gallery code turned out to be like two lines of Java to implement, but is almost criminally under-documented.
Screen Design: Apple – hands down – has a better screen design tool in Interface Builder than the screen design tools available under the Android SDK. I wound up doing most of my screen design using the underlying XML for each screen anyway. Having said that, creating screens to display suitably for portrait or landscape mode under Android is ridiculously easy when compared to what you have to do under iPhone. And before someone says, “well, it just works under iPhone as well”… child, please. Only if you finagle each design element individually under Interface Builder, subclass the tab controller, capture device orientation for subviews that don’t respond to the “should change orientation” messages. By a mile, this is something that Android did very well compared to Apple.
Maps: this is something that Google failed miserably at, in my very humble opinion. Under iPhone, you add a MapView and it works with just a little additional setup for scaling and setting your location. I got my first MapView in an Apple app working in like 10 minutes. On Android, you have to get the MD5 fingerprint of your keystore (where the certificate you sign your app is stored) and apply for a Google Maps key. And not just one key, but two keys – one for your debug keystore and one for your production keystore. Which means that you have to manually change your keys between the debug key (so you can see your maps on the emulator) and between the production key (so you can see maps on real devices). This is a total pain in the ass and is one more thing to forget before staging an app going out the door. All in all, it took me an hour before figuring this all out and getting my first map working on Android.
Permissions: Android has many permissions that can be set, many of which you don’t know you need until you try and run your app and have it fail inexplicably. For example, internet access is disabled by default (on a mobile device? yeah. I know). While I understand the beauty of this type of control, and that they are being safe rather than sorry, having to accidentally discover which permission is keeping my app from working is a not so pleasant experience. The iPhone SDK really doesn’t have anything like this in terms of hobbling application capabilities on such a wholesale scale (push notifications being the one notable exception).
Application Manifest: Under Android, each screen (or Activity) has to be explicitly declared in the Application Manifest – more or less a map of your application’s permissions and activities – or your app will bomb when you try to invoke that screen. I would say that this is the cause of most accidental crapping out that happens when putting apps together for the first time – forgetting to put a new screen into the manifest. Under iPhone, you typically run into a similar situation by trying to load the wrong type of view controller into an improperly defined variable – but it’s not really the same thing. Under iPhone, you know you need to load a view a certain way, and if you’ve defined the view it should work. it’s not at all intuitive that you have to remember to add your new screen class to the application’s manifest file. Or else.
Overall verdict: each SDK excels or fails because of the elements upon which they are built (amazing grasp of the obvious duly noted).
Because Objective-C is, at its heart of black hearts, just C with some objects bolted on, everything basically has to be built from scratch, especially tying UI elements together. Because Android is Java based, and most of the screen design and integration “just done” for you, the time from zero-to-application running is much smaller under Android than under Apple.
My one huge complaint about Android is that a developer has to manually bring several pieces together to do anything productive, whereas with Apple it’s download and code.
In truth, if you’re a Java developer, you’re gonna be right at home with Android and curse the Apple fan boys. If you’re an Apple fan boy, you’re gonna poo-poo the open source dweebs who have to support all of the forks that the Android environment will be challenged with as set makers try to differentiate features between their competitors.
And if you’re a developer like me, who’s just trying to pay the mortgage, feed the kids, and keep tuition current, you just hope to stay even.