Android vs. iOS Development: Fight!

Standard
Screenshot of Android Emulator for SDK version...

Screenshot of Android Emulator for SDK version 2.3. (Photo credit: Wikipedia)

English: Navit on Android phone

English: Navit on Android phone (Photo credit: Wikipedia)

it's real :)

it’s real 🙂 (Photo credit: Wikipedia)

Android ... 'Apple's nightmare' (7 September 2...

Android … ‘Apple’s nightmare’ (7 September 2013) …item 2.. Dean Martin & Goldie Hawn – Smart People? …item 4.. Pink Floyd – Welcome to the Machine … (Photo credit: marsmet474)

Image representing Apple as depicted in CrunchBase

Image via CrunchBase

Android vs. iOS Development: Fight!

Next Story

The eternal startup question “Android or iOS first?” grows ever thornier, with news that Android’s market share exceeds 80%. But never mind the managers and non-technical founders: what dodevelopers! developers! think of that divide? Whoever makes life easier for them gains a sizable edge.

And by “them” I mean “us.” When not writing TC columns (and novels) I’m a software engineer for HappyFunCorp, a consultancy with the best name (and web site–go on, click through) ever. To keep my hand in, as I find myself doing ever more management, I recently wrote and open-sourced a pair of more-or-less identical Android and iOS apps for a pet personal project. So let me use them to walk you through the state of the art.

Background: I’ve written numerous Android and iOS apps previously, both personally and professionally. These apps are native clients for my pet news aggregator, Scanvine, which identifies stories being shared unusually widely across social media. Their complete source code is available on Github: (Android | iOS) and the actual apps are available for download: (Google Play | App Store.)

Before we begin, I would be remiss not to mention Xamarin’s cross-platform development tools. If I was fluent in C#, especially if I didn’t already know Java and Objective-C, that would be my first choice for native app development.

Also, a disclaimer: this is more “fun code” than “production quality.” You’ll notice a stark lack of test code; I still need to track down an iOS heisenbug; I should be using git submodules rather than copy-pasted files for the third-party libraries; etc.

Now, with no further ado, let the battle commence!

Environment

You can still write code with text files and command lines, and many do, but it’s somuch more productive to use an integrated development environment, or IDE.

Apple’s is Xcode, which is, by and large, a joy to work with. It’s slick, fast, powerful, helpful without being intrusive, and it keeps getting better at papering over both the unheimlich compilation machinery beneath its glossy exterior, and the complex and paranoid certificate/profile machinery which Apple imposes on developers to retain its titanium-fisted control over iOS apps and devices. The debugger works seamlessly, and the simulator is fast and responsive.

But Android? Oh, Android. The current state-of-the-art IDE is Eclipse, customized with Android plugins, and it is embarrassingly bad. Slow, clunky, counterintuitive when not outright baffling, poorly laid out, needlessly complex, it’s just a mess. Its debugger is so clumsy that I find myself doing log-file debugging most of the time, whereas the XCode debugger is my iOS go-to bug-hunt tool. And the less said about the Android emulator, which takes minutes to launch and then half the time fails to connect to the Android Debug Bridge, the better.

Now, to be fair, Google knows this is a problem, and they are working on a new Android Studio IDE. Alas:

Android Studio is currently available as an early access preview. Several features are either incomplete or not yet implemented and you may encounter bugs. If you are not comfortable using an unfinished product, you may want to instead download (or continue to use) the ADT Bundle (Eclipse with the ADT Plugin).

It’s nice to see they’re working on it, but it’s amazing–in a bad way–that 4.5 years after I purchased my first Android phone, this mess is still the state of the art.

Advantage: iOS, by a country mile.

Configuration

As I mentioned, beneath the sleek, seamless exterior of Xcode and Objective-C lurk the Lovecraftian horrors of 1970s programming. I kid, I kid…but still. Macros and header files; projects, targets, schemes, and build configurations; an appallingly-intimidating list of build settings; the grim despair of encountering a baffling linker error; anddiscoveries like “oh, your third-party code doesn’t support ARC? Just add the -fno-objc-arc flag! Simple, no?”

Android has a single manifest file and Eclipse builds your app in its entirety (usually) every time you save any file. I’d prefer a more clarity in the error messages you get when your app isn’t working because you haven’t configured its permissions correctly, but that’s a minor cavil. By and large, Android app configuration is simple and elegant.

Advantage: Android.

UX Design

You would expect Apple to walk off with this trophy. Its Interface Builder is a very sleek way to put simple good-looking user interfaces together quickly. The trouble is, the more I’ve actually used Interface Builder, the less I’ve liked it. It’s another layer of configuration complexity; it’s excellent for simple things, but as time goes by and apps evolve, those simple things tend to get complex and messy; and I really don’t like the multi-screen Storyboards Apple added about a year ago.

While Android theoretically has a comparable visual tool, the less said about it the better. In practice you wind up writing XML files which provide layout guidelines, as opposed to rules, so that apps are rendered (hopefully) well on the entire vast panoply of devices and screen sizes out there. (Apple’s Auto Layout moves in the same direction, with an eye towards a larger variety of iOS screens in the future, no doubt.) Meanwhile, Android provides an icon pack for developers to use, whereas iOS developers have to go with third parties like Icons8, or roll their own.

Overall it’s a closer contest than you’d think, although I concede that this is pretty idiosyncratic. In the end two things give iOS the edge. First, it’s still much simpler: three screen sizes (including iPad) and two screen densities, as opposed to the mass of complexity which is Android. Second, the default iOS visual elements — eg popup menus and messages – are so much more visually attractive than Android’s.

Advantage: iOS.

Language

Android apps are written in Java; iOS apps in Objective-C. There are exceptions – there’s Xamarin, again; there are various other native-app fringe cases; and there are native/web hybrids like PhoneGap — but in general, native Android apps are written in Java and native iOS apps in Objective-C.

I cut my programming teeth on Java, and didn’t think much of Objective-C at first, in large part because of its excessive verbosity: a line like

String s2 = s1.replace(“abc”,”xyz”);

becomes

NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@”abc” withString:@”xyz”];

but I’ve grown very fond of Objective-C. It’s just better and cleaner than Java. It hasblocks: Java does not. It has categories; Java does not. It does not require you to wrap much of your code with vast swathes of boilerplate try/catch exception-handling whitespace: Java does.

Java has its advantages. Better stack traces, for one thing, which means tracking down sporadic bugs tends to be a lot easier. And until a couple of years ago Android had the huge advantage of garbage collection. But now that iOS has automatic reference counting, that advantage has mostly vanished (although old third-party tools often don’t work with ARC, which means you have to do some XCode configuration voodoo to switch it off on a file-by-file basis.) With that distinction gone, the winner here is clear.

Advantage: iOS.

APIs

Both Android and iOS make an enormous library of software available to their developers, and, broadly speaking, those libraries are fairly similar: there are APIs for phone functions and features, network access functions, a panoply of View objects including a powerful WebView which essentially functions as a full-fledged browser. Most of the work, meanwhile, is done in controllers: very roughly, an iOS ViewController is equivalent to an Android Zctivity.

What iOS has which Android doesn’t is an extra set of frameworks and features — there’s no real Android equivalent to iOS’s powerful Core Data framework, for instance — and a generally cleaner, better designed system. Compare these two relatively simple iOS classes, for instance, which really do the bulk of all the work in the app, withthese three equivalent Android classes, which between them include a half-dozen more inner or anonymous classes. At the end of the day I’d just much rather work with an iOSCollectionViewController than an Android ListAdapter.

Another metric, albeit a flawed one: lines of code. These apps are very nearly functional identical, but the iOS one has 1596 lines of custom code, including header files, compared to 2109 lines of Java code and XML for Android. That’s a full 32% more.

Advantage: iOS.

Internet

These days many-to-most apps are conduits to Internet APIs more than they’re standalone programs; this is important enough that it’s worth looking at separately. Both iOS and Android provide a panoply of tools and APIs for this. They also both provide very similar WebViews, which are basically full-fledged browser windows that you can plug into your app anywhere.

Network connections basically have to run in the background, so as not to block the main thread of the app, and multithreading is hard. Android provides an AsyncTaskclass for things like this, which is verbose but works well, and a very easy way to determine whether you’re currently online. iOS provides equivalent facilities, but they’re all pretty low-level and unsatisfying.

However, there are a host of open-source libraries that make life much easier. I used AFNetworking, which is as delightful as advertised. You simply pass it blocks of code to run when web requests are complete — which isn’t possible in Android, because Java doesn’t do blocks.

Advantage: Android natively, but iOS when third-party libraries are considered.

Sharing

How easy is it to share something from your app to Facebook, Twitter, Evernote, etc? I had thought this would be a first-round knockout for Android, which has long had a powerful inter-app communications system called Intents. And in general Android is still much better at letting apps call and share data with one another.

In the (perhaps unfortunately) much more common case of sharing, though, Apple has caught up considerably. Don’t take my word for it, judge for yourself. The Android code to share a Scanvine story is here, and the iOS code here. The only reason the iOS code is longer is because I do a little more Google Analytics tracking there than on the Android side (which I should fix.)

Advantage: Neither.

Fragmentation

No need to spend much time on this one. AndroidiOS. QED. Though it’s worth noting that Google is implementing an interesting defragmentation strategy, so this may be worth revisiting soon enough.

Advantage: iOS.

Publication

Publishing an Android app is easy as a dream. Just sign your app via a handy Eclipse wizard, and poof, you have an APK file that can run on any device. Email it, put it up on a web site, or upload it to Google Play and make it available worldwide (probably) within the hour. Could hardly be simpler. Check install statistics and crash reports, including stack traces which (usually) identify the individual line of code that went wrong, at your leisure, and you can upload a bug-fix version immediately.

Publishing an Apple app is a nightmare. A brilliant friend of mine always advises people to add at least a day to their iOS development schedule just to wrestle with certificates and distribution profiles. No matter how many times I do it, or how easy the latest version of XCode tries to make it, it’s always a giant hassle. And testing would be evenworse if not for TestFlight. And Apple’s “iTunes Connect” web site is to Google Play Developer Console as a Ford Pinto is to a Tesla. Good luck getting any crash reports at all, much less useful information from them; have fun jumping through their arbitrary hoops; and marvel at just how bad mighty Apple’s UX can be.

Advantage: Android, by a long shot.

And The Winner Is…

iOS, and by some distance. Android has its advantages, but overall, it remains significantly easier to write good iOS apps than good Android apps. Combine that with the fact that iOS users tend to be wealthier–and arguably more influential–and it still makes sense for most startups who want to make a splash to go iOS-first, Android-later. The new Android Studio IDE could conceivably close some of that gap…but not all of it.

(For the record, my own primary phone is a Nexus 4, and I’m very happy with it.)

Image credit: Jennifer Stolzer, DeviantArt.

ADVERTISEMENT

11 comments
+ Follow
Post comment as…

samir

samir17 minutes ago 

Jon, I know you are a good dev (we worked in the same place back in the day) but I have to disagree with you on many points. I have a startup in mobile that does both Android and iOS:

1. IDE: Android Studio has been out for a year, you can’t write this article without even trying it! There is also IntelliJ integration, which is far better than Eclipse. I recommend you try both then comment on this topic.

2. Language: You are joking right? Automatic reference counting is not the same as garbage collection, this is not 1998 with auto reference counters of COM+. Also exception blocks is what makes Android app crash a lot less.

3. API: It sounds like you never built a big app with Android SDK. Multiple OS versions support, Fragment API and backwards compatibility are just a few things that would make your life a breeze. Our iOS app keeps having problem after problem with this. It is not just how easy the API is, but more importantly how robust it is. iOS API is far from robust.

And  Core Data, that’s a joke right? That thing is horrible, and I wish we never used it as it is really not a flexible data interface, your app will just be stuck in a rigid world leaving you little room.

4. Sharing: I think you missed a big point. On Android you can just write one share code, the receiving app will decide how to share that content. On iOS you have to write share code for every single app you want to share with. So if you wanted to share on Facebook, Twitter, Vine you have two write your code 3 times.

5. Fragmentation: OK Jon, you are a developer not just a tech writer, I expected you do better than this. Can you please tell me how this affected you in your own app? It doesn’t (Unless you want to support ancient pre-2.1).  Android SDK and architecture is built towards having multiple versions, and there rarely ever is an API that you need which doesn’t exist. Even new features like fragments and UI has been back-ported to older OSes using Android support library (And if you don’t know what Android support library is, you shouldn’t comment on Android fragmentation)

I will argue that iOS has similar fragmentation problems (iPad, iPhone, iPod Touch, iPad mini, iPhone 5…. and there is still at least 10% of users running older versions), because the SDK has very poor support of different hardware and versions. Where is the Fragments API to support tablet vs phone? Remember when iPhone5 came out? few apps worked in full screen if any. And if you ever want to support older OS versions you enter into endless crashes and API problems, I see this first hand on our apps.

 

tundey

tundey1 hour ago 

I don’t believe I can program in a language that’s this verbose:

NSString *s2 = [s1 stringByReplacingOccurrencesOfString:@”abc” withString:@”xyz”];

 

Are you kidding me?

RafaelKireyev

RafaelKireyev1 hour ago 

I want to use at least three OSes on a single phone. Why not?

In my opinion, if this isn’t possible, we have deal with something aren’t yet fully operational systems or maybe existing phones aren’t yet fully smart.

CalvinR

CalvinR1 hour ago 

About the android IDE, ya I’ve got to try that new Android IDE because eclipse is killing me.  I make my live making asp.net web services and android apps.  I don’t have much to compare it to but Visual Studio seriously light years better than eclipse.

DamsonChan

DamsonChan1 hour ago 

Use Unity3D for game development and your cross platform problem is mostly solved, but… have you seen the pirate scene of the Android platform… It’s totally out of control…

TL;DR:   Piracy on Android takes away any appeal it might have as a platform

mjsalinger

mjsalinger1 hour ago 

This article is completely outdated because it fails to use Android Studio. Android Studio is a developer preview much the same way GMail was in beta for years – talk to me when you’ve done an Android Studio app. The UI tools alone are amazing. Refactoring is easy and fluid. Also your ‘sharing’ example is so basic its laughable. Sure, iOS now has a means of doing basic sharing, but stalls at anything more complex. Finally, APIs. For every API you reference where iOS is better, I can reference one in Android that is better. Take Push notifications. Google Cloud Messaging uses a simple REST API that is quick and easy to build, and hugely powerful. APNS is an abomonation of a web service and should be thrown out and replaced with a whole new system. I could go on and on.

shai.almog

shai.almog1 hour ago 

Being the co-founder of Codename One which allows cross platform development for iOS/Android/Windows/RIM etc. using Java I’m both biased (pro-Java/Android) and well informed on this and you made a lot of simplifications which I would strongly disagree with.
Xcode is an amazing IDE and Eclipse is an awful one, that is true. But that doesn’t make Xcode better, its WAY simpler than Eclipse and weaker (personally I prefer NetBeans). Refactoring, plugins, usage analysis etc. are at a completely different scale. Using the same IDE/language for server/mobile alone is an amazing advantage.
Java is ridiculously superior to Objective-C (but as I said biased), managed memory is completely different from GC and goes a huge way to finding issues and failures which in Objective-C I spend ages tracking down. Xcode has some nice memory management tools but they always failed me when it comes to the hard stuff. I personally like the fact that Java is clean object oriented and properly encapsulates data which isn’t the case with Objective-C. I think saying language X is better than language Y really boils down to taste though.
Androids API is an abomination of complexity, I agree. To their credit it solves a much bigger problem of a much larger set of device types and contains far more features than the iOS equivalent does for most cases.

benjaminjkaiser

benjaminjkaiser1 hour ago 

Android Studio is amazing. I know they call it a beta but seriously? I made my first app and published it using Android Studio for all the development. This article already feels old as it doesn’t take into account the ‘current’ state of development for android.The layout dev in android studio is a dream. Previews on sets of screen sizes all at once, just makes things so easy to plan out.Also you can’t count XML files for views in your lines of code if your not counting apples view files in your lines of code (are they still called xib files? Havnt done iOS dev in a couple of years).This article underrepresents the current state of Android development.

terry.oneill

terry.oneill1 hour ago 

The publishing part is an absolute showstopper for us. You simply can’t do agile development on a platform that may or may not ever allow any particular version to ever see the light of day. Also, agreed that Eclipse is not a productive tool, but Xamarin allows us to use Visual Studio and C# for Android development, and VS/C# is a country mile better than iOS/XCode..

hakobyte

hakobyte2 hours ago 

You made a mistake near Android “Zctivity” 😛 Great Article!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s