One of the awesome things about being an Android developer is just how accessible it is, in terms of how easy it is to get started and how easy it is to distribute apps to users. To me, it feels like a return to the days of the ZX Spectrum; where you didn’t need a large development team in order to make money with new games and software. Like older hardware, mobile devices ensure that anyone with a good idea working from their Mum’s basement can take the world by storm.
But before there was Android and the Play Store, there was iOS and the App Store. It was really the iPhone that kicked off the mobile app ‘goldrush’. So in many ways, we have Apple to thank for this opportunity. But the question is: which is the best option today for a new developer trying to make a splash?
Spoiler alert: the answer is an earth-shattering ‘well, it depends’.
Round 1: Development
Let’s start with how you actually go about creating an app for either Android or iOS. In both cases, you’re going to have a lot of documentation and support to help you out, which is a good start. But at the same time, both platforms have tons of options, various different elements and a lot to get your head around before you can really dive in. This is not just a case of learning a new programming language and getting to work…
iOS Development
In Apple’s case, you’ll be creating your apps using the Xcode IDE with the iOS SDK. Xcode supports multiple programming languages but the one that most new developers will choose is Swift. That’s because Swift is a programming language that was created specifically by Apple for iOS and OS X. It is based on Objective-C but is apparently less prone to errors and more concise. If you’re determined to though, then you can use Xcode with plain Objective-C, Javascript or even Python (among other programming languages).
So just how easy is all this? Reports vary but it’s certainly true that things could be more straightforward. Swift works with Cocoa Touch, which is an API for building iOS UI elements. This means you’re going to have to get your head around not only Swift but also Cocoa Touch and the iOS SDK.
And adding an extra barrier is the fact that Xcode will only run on Macs. That’s right: if you’re going to develop for iOS, you’ll need to buy yourself a relatively powerful Mac and an iPhone/iPad if you don’t already own one. This significantly increases the initial investment you’ll need to make before you can get started.
Android Development
On the Android side, things aren’t actually that different. Once again, you’ll need an IDE which in this case is probably going to be Android Studio. This means you’re going to be programming in Java and simultaneously using the Android SDK. I’ve gone into all this in more detail in previous articles, check out this post on how to start Android app development for complete beginners in 5 steps.
So which experience is more streamlined and accessible? To be honest, neither is a particularly appealing prospect for a beginner. And I have much more experience with Android development, so I’m not really in a position to judge the quirks of Xcode. What I can tell you is that Objective-C/Swift and Java are not worlds apart. If you’re used to developing in one, then transitioning to the other shouldn’t be too jarring. Both are object oriented and a fair amount of the structure is similar. There is also no clear consensus on the web as to whether Android Studio or Xcode is superior. Both have their strengths and weaknesses and both could stand to learn a thing or two from the other. It’s certainly true that the iOS simulator is considerably better for debugging than the Android emulators. On the other hand, you can install Android Studio on a PC or a Mac, which is a big win. And it has better autocomplete. In either camp though, you’re going to find a lot of people complaining about things not being as intuitive or quick as they should be, which is fair.
Winner: Draw
There isn’t a clear winner here but there is a clear loser: us. If you want to develop for both iOS and Android using the official methods, then you’re going to have to install two IDEs, learn two programming languages, get to grips with two SDKs and learn various APIs. That’s a massive headache (and it gets worse as we’ll discover).
There isn’t a clear winner here but there is a clear loser: us.
That said, it’s also only fair to note that there are alternative tools for both platforms, some of which make it much easier to port both ways. There’s the excellent B4A and B4i for example which let you code in BASIC, Unity for easy game development and tools like PhoneGap that let you make cross platforms apps in HTML and JavaScript. Each has their limitations though, so you’ll need to do some reading before committing to one.
Round 2: Design Guidelines
If there was a miraculous program that could take your Android app and transform it into an iOS app, then you’d still have a fair bit of work on your hands before you were ready to release. One cannot simply take an app designed for one platform and drop it onto the other, unfortunately.
The main reason for this? The design language is completely different on iOS compared with Android and so is the expected interface. Both Apple and Google want to encourage more consistency between apps, so it will be jarring for users if you don’t conform at least somewhat to the design sensibilities of the specific OS you’re targeting.
One cannot simply take an app designed for one platform and drop it onto the other, unfortunately.
iOS vs Android Design
Like Android, iOS has seen a recent shift away from skeuomorphic shadows and toward flatter designs. However, Android is much clearer and more precise in how it wants users to go about adopting this language and gave us Material Design to refer to. I won’t go over this in detail again here but it essentially means treating UI elements as though they were made from physical material (paper specifically) and using cues like shadows, animations and the Z axis to communicate how the user should interact.
While iOS design is less clearly defined, it generally involves the use of negative space, large images, transitions and lots of translucent elements (often with the ‘frosted’ effect). Generally speaking, iOS is also a little flatter and this can be seen in the different ways the two platforms use cards, for example.
In terms of navigation, the most obvious difference is that iOS devices lack a back button and so need to include them in the UI (normally in the top left). Including a back button in Android is generally considered a no-no.
Winner: Android
There’s no arguing that Google has provided some very clear guidelines for its developers when it comes to design – and for the most part this results in some rather pretty and intuitive UIs. There’s more guidance and documentation for Material Design and so Android comes out on top in this case.
That said, the clearer guidelines also mean that Android developers need to work a little harder if they want to keep up.
Round 3: Fragmentation
The apps you create will always be defined to some extent by the hardware they’re intended to run on. We’ve already seen how the lack of a back button can end up affecting your UI and design and of course this relationship goes deeper.
When it comes to comparing iOS and Android hardware from a developer’s perspective, one word springs immediately to mind: fragmentation.
When it comes to comparing iOS and Android hardware from a developer’s perspective, one word springs immediately to mind: fragmentation. Unfortunately, developing for one Android device is going to mean developing for countless Android devices. That means different screen sizes, different DPIs and different aspect ratios. Beyond that, you also have fragmentation in terms of the Android versions that people are running. According to Open Signal, 5.6% of users were still on Gingerbread in 2015!
This becomes a problem for developers. Not only does it mean that we need to come up with flawlessly responsive designs (which ironically is one thing that Xcode supports better than Android Studio) but it also means we need to think hard about whether we want to add a new feature that will prevent a large portion of the market from being able to run our apps.
That said, there are also advantages to this fragmentation. Ultimately, this situation is born out of the open nature of Android, which means that there is a much broader range of hardware capable of running the OS including media streaming devices, wearables, TVs and in-car navitainment systems.
This means that you can potentially get a little more bang-for-your-buck by learning Android development as it will allow you to create apps for everything from watches to smart TVs. And in each case, you can find new markets and new opportunities. Perhaps the Play Store is too saturated for your liking? Then how about releasing an app for the Kindle, for smartwatches or for the Gear VR? I’m super happy I’m an Android developer right now rather than an iOS one, because it means I can start working on some cool VR projects…
Winner: iOS
While Android’s open nature is to be encouraged, the fragmentation still ultimately makes life difficult for developers and that means this round has to go to iOS. While iPhones are gradually getting more diverse, the situation is still considerably easier, which saves developers time (and bad reviews) and ultimately improves revenues.
Round 4: Publishing and Restrictions
As we’ve already seen, there are significant advantages to the open nature of Android. And the same can be said more broadly for Google’s generally laissez-faire approach.
For starters, Android allows access to more of the system’s inner workings, which lets you create things you just couldn’t make on iOS. This includes all manner of customization apps, launchers, floating apps and more. And when it comes to actually publishing apps on Android and iOS, Android clearly comes out on top from the developer’s point of view too. See, when iOS itself doesn’t limit what you’re able to create, Apple probably will. Apple obviously has a very clear idea regarding what kinds of apps it’s happy to support and is much more stringent when it comes to checking apps that developers submit.
Publishing to the Play Store vs the App Store
To publish an app on Android, all you need to do is sign up and upload your APK. It will then take a couple of hours before it’s live in the store and people can start downloading it. It costs a one-off payment of $25 and that’s it. That simple!
On iOS meanwhile, you need to pay a recurring annual fee of $99 and submit your app more formally for it to be tested by real-life humans. This can take a couple of days and there’s always a good chance the submission will be rejected. In some cases, this is at least understandable; Apple wouldn’t let you release a Genesis emulator for instance because of the potential legal issues. Likewise, anything that it deemed to be offensive or too low-brow would also be off the cards.
But then there are the more obscure reasons that iOS can reject an app. My friend built an insult-generator that used unusual words to amusing effect and had a very nice design (he’s a web designer). The app was rejected on the grounds that the words were made up! This in fact was not the case and so my friend added a dictionary element to the app that would explain the meaning of the word. He hoped this would also add an educational aspect. Again the app was rejected, this time because it ‘wasn’t fun or interesting’. Of course that’s their opinion but considering that there were similar apps in the App Store at that time with much less originality and far worse designs, he was understandably infuriated.
My best-selling app meanwhile was a multitasking app – the functionality of which simply would not have been allowed on iOS. And my other big app was a launcher. So…
Winner: Android
Apple’s approach surely has its benefits. Apart from anything else, it maintains a higher standard of app on the App Store which is good for the user. But you could definitely make the case that Apple goes too far in that direction and that this ends up causing problems for developers and even stifling creativity. And the firmware restrictions are of course one of the reasons many of us gravitated toward Android in the first place. Ultimately, developing for iOS could mean investing in a Mac, learning Xcode and Swift, investing hours and $$$ into development… only to have your app rejected. Thankfully, this danger doesn’t exist on Android.
Round 5: Profits
Of course we also need to think about the potential moolah you can earn developing for each platform and this is where Apple has the clear advantage.
There are many more devices out there running Android and the Play Store sees a much larger number of downloads accordingly. But despite this, the App Store still brings in significantly more revenue – to the tune of about 75% according to a report from App Annie. iOS users are simply happier to spend more on their app purchases and this is something you need to consider heavily before making your choice.
If you develop only for Android, then you are going to be losing out on a lot of potential revenue. The best decision will always be to go cross platform (which will give you access to the largest possible audience) but failing that, you’ll earn more money by being iOS exclusive. But hey, Android developers still earn more than Windows Phone developers!
Winner: iOS
If you have two identical apps with identical marketing campaigns, then you’re likely to earn more from the iOS version than the Android version. This doesn’t always hold true (as mentioned, you might be able to find a better route to market on Android) but it’s certainly the trend.
Conclusion
And the winner is… nobody! Each platform gets two wins each and one draw, making it a draw overall.
Cop-out I know. It’s just like all those superhero vs superhero comics where they reach a stalemate and eventually team up to defeat a common enemy… anticlimactic and ultimately unsatisfying (that’s my MO).
The weighting you give each of these points will come down to your own preferences and goals, and that will ultimately decide which platform is best for you.
