Android vs. iOS Development: Key Differences

When developing a mobile app it is typical to develop both an Android and iOS version at the same time. Deciding whether to use a cross-platform development tool or to stick with the tools available is not a simple decision, especially since cross-platform tools have their own quirks. Here we highlight some of the key differences between Android and iOS development using their own tools and languages to show that going native isn’t as daunting as you might think.

Cross-platform Development

Before we get stuck into the detail, we must at least mention some of the tools that are available for cross-platform development. The trend setter in this domain was PhoneGap, purchased by Adobe in 2011, which enables the development of mobile apps for Android, iOS, Windows and more using HTML, JavaScript and CSS. If your app is fairly simple then this might be a sensible way forward, but the gains you make in cross-platform development can be let down by performance and a lack of native features. Other cross-platform tools say they overcome these limitations, such as Appcelerator and Xamarin to pick just two, but these require you to learn how to use proprietary libraries, or even expect you to develop platform-specific code in their adopted language. In other words, you are still having to learn the basic development paradigms of both platforms. Here then, we help spell these out.

Development Tools

We start with the required development tools for Android and iOS. Android has adopted Android Studio, which is a free version of JetBrains' IntelliJ IDEA. (Previously the go-to tool was Eclipse.) With everything you would expect of an IDE, Android Studio allows you to write and test Android apps using both Java and native development in C or C++, running the apps on connected devices or a simulator. The IDE seamlessly brings together all of the dependencies, tooltip help, documentation and source control and all for free on Windows or Mac.

iOS development follows the strict 'closed loop' philosophy of Steve Jobs. You must use Xcode on a Mac to develop iOS apps (even underneath the likes of Xamarin), and if you want to test on a real device, you have to pay an annual subscription (currently ￡79), although you can use the simulator for free. However, you do have a choice on what language to use for development — either Objective C or Swift. Objective C at face value looks tricky, but as a superset of C and with C++ an option, once you get past the verbose veneer, it is a straightforward language to adopt. Swift was developed in response to some of the difficulties people faced with transitioning to Objective C and offers a cleaner syntax and approach, plus it is fully compatible with Objective C so that you can easily mix the languages together in the same app. Xcode is a basic IDE which supports context-sensitive code completion, source code control, documentation and debubgging, but is not as full featured as Android Studio or perhaps as easy to use. Nonetheless, it comes with third-party packages you can add, which make life a little more bearable.

Java and Objective C/Swift are very different languages. Both are object oriented, and both do automatic clean-up of objects using 'garbage collection' (Objective C recently with ARC), allowing you to focus on the functionality and to worry less about object allocation and deallocation, yet they each have a different approach to object orientation.

In a nutshell, Java's object oriented approach provides for class hierarchies with dynamic binding. Single class inheritance is provided through concrete and abstract classes using a range of variable and method visibilities. Multiple inheritance is provided through (method signature-only) interfaces.

Objective C/Swift also provides class hierarchies with dynamic binding, but does not have a clean concept of visibility (public or implementation-only), and does not provide abstract classes. Single class inheritance is used together with protocols, which are equivalent to Java's interfaces. However, while Objective C does not have abstract classes, it does offer class categories and extensions which enable you to add functionality to an existing class, even when you don't have access to its source code — something that Java does not allow.

In other words, with a little careful practice, it is fairly easy to translate Java into Objective C/Swift or vice versa without too much change in the approach. Just do not expect to be able to translate concepts such as protected visibility or abstract classes between the two, but there are ways to work around these.

App Framework

The big difference between the two platforms is in their overall approach to the framework of an app. By framework we mean how you define the components of an app, an app's lifecycle and flow, and the underlying capabilities.

Provided your app has the correct permissions, Android essentially lets you do anything. Beyond the basics of an app which has a series of connected screens, in Android you can write background services which can run all the time, or in response to specific events, write home screen widgets, or stand-alone data providers. On iOS you are fixed to being able to just provide an app which consists of a series of connected screens. They may well use data providers underneath, but background tasks are strictly controlled so that you cannot write separate services or anything outside of the 'closed loop'. (And if you think you have a way of getting around the restrictions, every iOS app goes through a review by Apple before it can be released to iTunes, maintaining the 'closed loop'.)

To put this as an analogy, Android is like having a box of Lego so that you can make whatever toy car you want with whatever blocks you need — 3 wheels or 10, engine in the back or front, you can even add wings just like Chitty Chitty Bang Bang. iOS on the other hand is like having a ready-made toy car. You might be able to choose which make, model or colour, go for the convertible option or not, but at the end of the day, under the hood it's been put together for you and you are just adding the way you drive it.

At this point you might think that Android seems to be coming out on top, especially given that it holds a majority of devices in the market. However, the flexibility that Android provides can make it a very daunting prospect — where do you start building? iOS, on the other hand, is easier as it is clear where your app starts and to what other screens it transitions using storyboards. Android does not have any concept of a storyboard, and all the logic linking together the screens of the app has to be provided by you in code or via the app's manifest (definition of components).

All this means is that, if you're coming from Android, iOS looks very restrictive, while the language might be a bit difficult to grasp. If you're coming from iOS, Android has a steep initial learning curve because it's very difficult to know where to start, plus you will end up writing non-trivial code to, say, handle a segue from one screen to another.

Differences at a Glance

Summarising the key differences, we have:

Of course, there are many aspects which are the same, such as both support comprehensive internationalisation, bundling of resources and strategies for providing different user interface layouts for the various phones and tablets. There are also subtler differences around the use of security, such as Android's previous requirement, now being deprecated, of granting permissions on installation, rather than on first use, which is the way that iOS handles this.

Nonetheless, for those of you transitioning from one platform to the other, the differences are not fundamental. If, for example, you are providing a typical app which uses screens, data and maybe sensors, then translating from one platform to the other is a straightforward affair which will require re-definition of the user interface elements, then translation of the business logic and supporting classes. Strategies for dealing with sensors are very similar in that you register for sensor updates and receive these via listener objects. Problems may only arise if you want to do something beyond the norm, such as running processes in the background, which are possible in Android but not in iOS.

The upshot is that building an app for both Android and iOS should not be a difficult prospect, and once you have a working design for one platform, translating to the other should not take as long as the original development. Using cross-platform development tools, you may get a slight reduction in the development time, but only for a typical app. Such cross-platform tools will normally require you to re-define user interfaces and their controllers anyway, then anything out of the ordinary may not be supported or more difficult to integrate.

We can help

Digital processing is at the heart of innovation. It may be that you have a difficult or complex problem. Pervasive Intelligence have the expertise to cut through the complexity to give you a solution you can use in the real-world.

If you would like to know more, or are interested in what support we can provide, take a look at what we can offer and book a free consultation. To receive similar insight, just follow us on LinkedIn.