A Scoring Comparison of Android and iOS Development
Thinking of getting into mobile app development? What’s it like to develop for Android compared to iOS? In this article I’ll compare and contrast the two development styles from a programmer’s point of view. As Android 5 (Lollipop) and Material design is still fairly new, I’m looking at the earlier methods, from Android versions 4.0.3 to 4.4. I picked those versions because of the market share figures on Google’s Android developer dashboard. In total, they cover 90.6% of the models.
It’s my contention that iOS development is quite a bit easier, but see if you agree or disagree. With each comparison I’ve given a score for both. These are entirely subjective, but hopefully fair. Note that I switched from Eclipse to Android Studio two days before writing this.
Android development wins over iOS in the programming language category. Java is easier to learn than Objective-C, which is an older, lower level language. That means you have to write more code to do the same thing, and the advanced data structures available to Java developers are well ahead of those in Objective-C. But now, with Swift, I’d put it almost par for learning compared to Java.
Android: 9/10 iOS: 7/10
Previously, Android development was done with Eclipse using ADT — the Google customized Android Development Toolkit. It has now been officially replaced with Android Studio, shown below, with an Xcode screenshot below that. iOS development uses Xcode, currently at Xcode 6.1.1. Both Android Studio and Xcode are free. It’s only when you want to deploy apps onto your iOS devices or distribute them in the App store that you have to pay Apple $99 a year.
Android: 10/10 iOS: 5/10
Android Studio has background compilation and will quickly highlight errors, while Xcode needs an explicit build stage. Both let you debug on emulators or real hardware. It would probably take a very long and detailed article to compare each IDE’s features — both offer navigation, refactoring, debugging, etc. Android Studio offers a few more choices, but this is balanced by the GUI design tools in both, and that depends on the design philosophies, so let’s move onto that.
Android Studio: 8/10 Xcode: 8/10
Somewhat off topic, I’m very fond of ReSharper, a toolkit for C# developers by a firm called JetBrains. They’re very good at writing programmer friendly IDEs, and their Java IDE IntelliJ IDEA is a serious rival to Eclipse, with lots of user friendly editing features such as advanced code completion, refactoring and code analysis. The free community edition is what powers Android Studio, and it has an improved layout editor. When you start a project, you’re offered a selection of activities. I’ve not built anything with it, but from just trying it out, I liked it a lot. Android Studio 1.1 was just released in the last week.
Design Philosophies of Android and iOS
Unlike desktops, the space on mobile screens is relatively small. There are certain design rules that are common to both platforms. For instance, fingers and styluses do not have the pin-point precision of a mouse pointer. The smallest clickable size is similar: 44 pixels on iOs and 48 on Android. The architecture of screens on both platforms has one thing in common: they both call a clickable rectangle area a view. After that it gets a lot different.
On iOS, navigation and organization is done by view controllers, and there are a number of different ones, such as tab controllers, page view controllers, navigation controllers, split view controllers, etc. Generally, a view controller controls a whole screen or part of it. These can be programmed in code or by using a storyboard. With a storyboard, the user can organize the images or illustrations and then store them in an XML file. Originally, the XML files were used to build each page individually as nibs, but storyboards have now been in use for a few years. You can program 100 percent in code — with no XML nibs or storyboards — but it’s slower and more error-prone.
Very roughly analagous to view controllers, Android lets you partition apps into activities and fragments. Activities correspond to a screen, so if you have multiple screens, then you’ll have multiple activities with only one active at a time. Fragments are part of activities and there can be multiple fragments in a single activity. You can use a fragment, for example, to open another screen, enter a value, then return to the activity.
Android also uses XML files, in fact, considerably more so than iOS. The example app, shown below, has two text views, three buttons, an image view and an image button (the settings cogwheel). This is all defined by a 65 line XML file, Main.axml. Other Android XML files include preferences.xml to control the settings, strings and styles XML files and, of course, the AndroidManifest.xml that contains SDK versions and permissions. Again, like iOS, it’s possible to layout controls programmatically, but it’s not as easy as using a visual designer, and the Android Studio layout designer is very nice.
If you want to see how many XML files there are in an Android app, get hold of a .apk file — the app package file, i.e., the installer — rename the extension from .apk to .zip, and unzip it. Yes, APK files are just zip archives, much like jar files, but with a .apk extension. Note, XML files may be in Android binary XML format, so you need to convert them to read them. That Wikipedia APK link mentions tools to do this.
Android: 5/10 iOS: 9/10
Nothing to do with dropping your phone, but a measure of how many different handsets are out there. There are many manufacturers producing phones with different screen sizes. The Android version, screen pixel density, etc. means that Android has around 19,000 (OpenSignal Report) while iOS is under a dozen. On Android you have to support medium dots per inch (mdpi), hdpi, xhdpi, xxhdpi and xxxhdpi. Each resolution has its own folder, and graphics used should be pre-scaled appropriately and put in the correct folder. If you don’t pre-scale graphics for a given resolution, then Android will try to scale them, and that may not look so good.
iOS is better in this respect with just three sizes of graphics, and the lowest one isn’t really needed nowadays. If your graphic is called fred.png and is 60 pixels (width or height is irrespective) then you should also supply a email@example.com, which is 120 pixels. For iPhone 6 and 6+, it should be firstname.lastname@example.org, that’s 180 pixels.
Android: 5/10 iOS: 8/10
Apple has it way too easy here. With such a small range of models, they provide just one simulator that you invoke for the appropriate model. With Android, you have to pick the operating system versions, screen size and have one created for you. Hopefully it’s an Intel-powered version, and not Arm, because Arm’s simulator is very slow unless you install the Intel hardware emulator.
Android: 5/10 iOS: 9/10
Both Android and iOS development are very well documented. I have a slight fondness for iOS docs, because Apple has put a lot of effort into explaining many concepts, like View Controllers, and supports both Swift and Objective-C. But Google’s docs are very comprehensive as well.
Android: 10/10 iOS: 10/10
The Winner is?
Totaling the scores gives iOS 56 and Android 52, so they’re too close to call, which is better. I’ve deliberately excluded market share which is dominated by Android, App Revenue which favors iOS, and other factors like ease of upgrading, which also goes to iOS. The counter to that is it’s very easy to develop for any Android phone, while iOS phones have development obsolescence built-in after three to four years. iPhone 4, anyone? The App store removes any app which doesn’t get upgraded to the latest iOS version within six to nine months of that version being released.
So, Android versus iOS is swings and roundabouts, from a programmers point of view.