Android vs. iPhone development experience

There are a steady stream of posts about which platform makes more sense to develop for, in terms of market size, chances for success etc. This post isn’t about that. This post is about the development experience itself, what it’s like building apps for the two platforms.

A few years ago I would have said, and in fact, I did say, that building apps for Android was a more pleasant experience, less painful, than doing so for iOS. Having more recently, jumped back into iOS development with both feet, I think, since iOS 5, the latest Xcode 4.5+, and ARC, iOS native apps are easier to build than Android apps now.

I quickly want to throw out a few caveats. First, I’m not trying spread the “objective-C religion” here, in a Ruby on Rails sort of way. I don’t love objective-C. I much prefer Java to be honest. But, like Dr. Strangelove, I have learned to stop worrying and become tolerant of it – it’s not that bad. Second, I couldn’t give a rat’s ass about Storyboard. I know a lot of people like it, but it’s not my thing. I build and mange the UI in code, or “programmatically” as Apple calls it (a post for another day). And finally, I’m not speaking to points of deep computer science nuance here. I’m just speaking from a practical development perspective.

All that said, here we go…

Where Apple wins: The iOS features now are getting pretty powerful. They give you a lot of functionality without a lot of work in your app. The availability and quality of tons of really good open-source libraries and tools is also a big factor here. Xcode has gotten a lot better. There are times I still want to burn it with acid, but at this point, I have to accept the reality that it is more reliable, better integrated, and provides a much more overall effective development environment than Eclipse for Android. The integration with repos is a nice feature that is finally there in Xcode. The fact that the simulator simulates specific real available device and OS configurations instead of weird theoretical devices is a big plus. While not a pure development environment issue, as a practical matter, the fact that iOS users tend to upgrade more consistently (only 1.5% of iOS users are still on iOS 4.x) means you can worry less about backwards compatibility and supporting old versions of iOS. I could be wrong on this, so feel free to correct me, but I think iOS may have a slight advantage in terms of available open-source libraries, UI widgets, and frameworks. At least for my part, it seems there are more of them and they are easier to find, generally of high quality, and are better supported than the hodge-podge of available Android libraries.

Where Apple sucks: Resolution and screen size is still kind of a kludge and probably always will be. The “default” iOS UI / UX tends to give your app a 2008 look and so most modern apps require significant UI / UX customization…. but… Depending on what you want to customize about your app, it can be difficult if not impossible, and every such change runs the risk of more scrutiny by the App Store reviewer and could raise “user interface guidelines” issues. The “natural” way to customize the appearance in iOS tends to be through PNG images – lots and lots of PNG images (for every screen size, resolution, and orientation). You can easily spend as much time in Photoshop as you spend in Xcode for a highly customized app. The App Store approval process is capricious and inscrutable  Apple can reject your app at any time for any reason and you are powerless to do anything. The constant threat of app rejection is always hanging over your head. So many things seem to depend on the specific reviewer you get and what kind of day they are having. The sandbox is a double-edged sword. It prevents apps from doing all kinds of cool integrations, like capture SMS, but it also means your app can’t very easily screw up other apps or crash the phone. The lack of such, does mean that, short of jail-breaking, apps cannot access files, processes, or other OS internals except through the limited access the iOS SDK provides. You certainly would never get such an app approved on the app store.

People probably expect me to complain about the sandbox and also the lack of “pure” multitasking in iOS, but I’m not sure I want to. I think there are actually some advantages to the way iOS manages “background” tasks. In short, I’m ok with it, usually, but I think there should be, in general, more “deep integration” options for specific apps that really want it. I’m not sure if Apple will ever do it, especially given the malware problems we have seen with Android, and the high cost of reviewing apps they already endure, along with Apple’s paranoia about apps “duplicating core functionality” but it would be nice if there were some option for requesting “deep integration” perhaps where developers have to pay extra to have such an app reviewed.

Where Android wins: Potential for much deeper integration, the best example is probably SMS, where unlike iOS, for better or worse, Android apps can read and process SMS messages. More and better interprocess / inter-app communication possibilities. Apps can also customize the launcher and do other stuff that is not possible on iOS, including really “running” in the background (again, for better and worse). It is much easier to have beta testers install your Android app for testing than the cumbersome UDID provisioning hassles associated with iOS. It’s more of a personal preference, but I’d rather write java code than objective-C code.

Where Android sucks: The simulator situation is pathetic. It’s slow and painful to use. It is difficult, if not impossible, to configure for real hardware that you find in the wild. While less of an issue for the developer and development process, the fact that Android apps have more power and system-level access does mean you have to be a bit more careful that your app doesn’t do anything harmful or represent an inadvertent security threat or a CPU / battery drain. There are too many devices and screen sizes to test them all in practice, especially for all possible versions of Android. And, with Android, it’s harder to ignore older versions of the OS. While things are getting better on this front, over half of all Android phones in the wild are still running 2.3 Gingerbread or older. If you decide to only support 4.x (Ice Cream Sandwich and Jelly Bean) you are forgoing 55% of Android phones (whereas with iOS if you only support 5.x or newer, you are only losing 1.5% of users). That makes building apps for tablets even more challenging. Android development tools and documentation are much less organized: it’s harder to find stuff and harder to get answers. In my experience, the Android developer community seems more abrasive, quick to bully, and less willing to help than the iOS developer community

Where they both suck: Automated testing. It’s really hard and expensive to test iOS and Android apps.

Summary: I’ve seen people claim that the cost of building an Android app is significantly less than an iOS app (some say half the cost). That may be true in terms of what contract houses charge, but I don’t think it’s true in terms of the actual effort required to build the app (depending on what it does and assuming it is not totally impossible on iOS). The wide availability of good working code for many common tasks helps the iOS situation immensely, which when combined with SDK improvements in iOS 5 and iOS 6, makes it much faster to develop iOS apps today than it was a few years ago. For me personally, I’m pretty sure I can get a practical and functional app put together and ready for testing and ultimate distribution on the App Store quicker for iOS than Android, which is not something I would have said a few years ago.

If you haven’t checked out iOS development in a while, I can offer the following as areas that have helped me make progress:

1. Forget Storyboard. Get used to building interfaces “programmatically” – you can thank me later.
2. Study iOS memory management and when you understand it fully, use ARC.
3. Get comfortable with Protocols and Delegates and the Notification Center.