We often need to estimate development projects which have both iOS and Android. It's tempting to say that Android will be the same, but what we have found is that Android takes more effort.
The rule of thumb in Silicon Valley is that it takes two to three times the work for an app with an equivalent level of polish as a "world class" iOS app. That may be true for some applications, but is generally excessive when you are first starting.
We generally see about 30 to 50 percent more time required to build the initial Android app compared to iOS. Then the effort increases again when we need to support a wider range of devices or for applications which are more dependent on the hardware, e.g. using video or Bluetooth, or have complex user interfaces.
There are a number of reasons for this, primarily coming down to quality of developer tools, platform fragmentation and testing effort:
1. The development tools for Android are not as productive as for iOS
Apple provides the very mature Xcode integrated development environment for iOS, and everything works well out of the box. Tools like Interface Builder make it easy to lay out UIs graphically, the debugger and profiler are easier to use, and the simulator compiles the app to run natively and quickly on the dev machine.
Android developers use Android Studio or general purpose IDEs like Eclipse. They have to set up their environment from multiple pieces and plugins. Build performance is much slower than on iOS (minutes instead of seconds), making iteration slow. The app runs ARM CPU code in an emulator, which is slower than the actual hardware.
2. Java is a lower-level language than Objective-C or Swift
Objective-C and the new Swift programming language are higher level, making coding more efficient. Android apps typically have 40% more code than iOS apps.
Apple has also made some fundamental design decisions which give a better customer experience. A common programming mistake in both platforms is a null pointer exception. On iOS, this results in an empty result object. On Android, it results in a crash, which gives a poor user experience and perception of quality. For the developer, it wastes time as they need to restart the app and go back to where they were working whenever a crash occurs.
3. Android APIs are lower level and less complete than for iOS
Android often requires a 3rd party library where iOS has functions in the standard framework. This makes it harder to use multiple libraries together and requires the developer to spend time finding and evaluating library options.
High level widgets and consistent UI make prototyping easier on iOS. For example, the CoreData API on iOS makes it easy for developers to work with data "objects" and store them without considering the low level details. Android developers need to use raw SQL with databases or other 3rd party frameworks.
Custom screen animations are easier to implement in iOS, and have hardware acceleration making them faster and more energy efficient.
4. The iPhone has a limited number of display aspect ratios and resolutions
For iPhone, it is reasonable to design for specific screen sizes, making "pixel perfect" UI mockups in Photoshop and implementing them exactly in the app. Testing on a few devices covers all the important resolutions, and it is practical to test on all the iOS devices in the market.
Android has many different screens, effectively every variation possible is on the market. This analysis and visualization of Android device fragmentation is good, though a bit old. Here are up to date stats for Android from the Google Play Store.
There was a joke was that Samsung didn't know what the right screen aspect ratio was, so they made every variation and counted what people actually bought.
Because device capabilities vary widely, developers have to work in "logical" device-independent pixels and translate into device pixels. Text may have different thickness at different screen resolutions, causing differences in appearance, margins and line breaks.
Developers need to use dynamic layouts which change the relationship between elements to accommodate different screen aspect ratios. Spacing between elements is fundamentally variable. Instead of using the drag-and-drop Interface Builder like in iOS, developers generally need to code user interfaces in XML text files.
Sometimes these dynamic layouts result in poor results. A tall and narrow display may have too much space between vertical elements and unsightly line breaks, and an especially wide display may have blank spaces on the sides of the screen. It is possible to create special optimized layouts for different screens, but that requires extra work and can only cover a subset of the market.
5. Android hardware is highly variable and software support is buggy
iOS hardware is powerful, at the top end of the market. It is reasonable for iOS developers to only target newer devices, as users upgrade regularly. Apple aggressively stops supporting older hardware with newer OS releases, pushing people to upgrade.
Android has some extremely low end devices, often of poor quality and unbalanced resources, e.g. low end tablets run phone chips combined with big displays and may not have enough RAM to handle the screen.
On iOS, each app gets the hardware to itself when it's running. On Android, apps may be sharing resources with other apps running in the background. The app is also limited by the OS from using all the resources that are available.
The iPhone uses the GPU to accelerate the user interface, and has APIs to support animations. This gives better performance for scrolling or fancy UI effects with no additional work for the developer. The iPhone has advanced features like fingerprint recognition or advanced Bluetooth, and they generally work without issues.
The normal process for Android hardware support is as follows: Google releases a new Android version. Chip manufacturers like Qualcomm or Allwinner add drivers to support the special features of their chips, e.g. audio / video codecs. This takes a few weeks or months, depending on their relationship with Google and their access to pre-release versions of Android. Mobile device manufacturers choose chips from the manufacturer and get a reference kernel and hardware design. They may use it as is, or may customize it to differentiate themselves. They may have more or less software engineering ability in house, and may not even have complete datasheets for all the features of the chips they use.
The result is that there may be bugs in hardware support which cause strange results and crashes when using features like video or Bluetooth. Mass market apps need to work with all of the devices in the market, so they can't assume advanced hardware features. Developers need to design for the lowest common denominator, provide fallbacks and do more performance optimization, which takes more development time. Carrier and OEM preload agreements can force Class A support for marginal hardware.
In applications which have millions of users, we can expect to see crashes due to broken hardware, e.g. bad RAM. Debugging these problems can be extremely difficult, because there is not fundamentally anything wrong with the software.
6. Android has many OS variations
Most iOS users are running the latest operating system release within a week of the release. More than 95% of users with up-to-date hardware run it immediately. Overall more than 80% of users run the latest release.
Android users rely in their device manufacturer and carrier to provide OS updates, and most do not. They expect users to buy new devices and consider the new OS to be an incentive to buy.
The result is that less than five percent of Android users are running the latest Android OS release months later. About 30% run the previous release family, 30% are two releases back, 30% are three back, and less than 5% run very old releases. New OS penetration comes as people get new phones every two years. In developing markets, significant percentages of customers run used phones until they die or run low end hardware that can't handle the latest OS.
Manufacturers such as Samsung differentiate themselves by customizing the user interface. This takes time and may result in unique platform bugs or incompatibilities. Some manufacturers modify how the OS works in fundamental ways, e.g. automatically saving a copy of every photo the user takes in a gallery. This causes problems for health-related apps which need to maintain privacy of patient data.
7. Apple is more secure than Android
Apple differentiates itself with security and privacy compared to Google. Apple sells phones and Google sells advertising. Outside of niche devices like the Pixel, Google does not control the hardware. It makes money from services, not hardware, so it wants the most users possible no matter what they are. Apple supports features like finger print recognition and hardware security modules.
Google does not police the app store for quality the way that Apple does, and carrier- or 3rd-party app stores are common. Users may install pirate apps or side-load unsigned apps. The OS is more likely to be "jailbroken". Users may be less sophisticated and install malware, or they may customize everything up to the point of installing custom firmware.
iOS apps are restricted in what they can do. Android apps can do almost anything, including running in the background and capturing keystrokes, listening to the microphone, reading the user's location and sending everything to the net.
Android devices often have external storage and support plugging in USB devices. iOS devices require permission from Apple to connect hardware.
The result is that creating high security apps on Android is much harder, as they need to operate in a hostile environment.
8. Testing effort
Creating a high quality app is already more difficult, then we need to test on a wide range of devices.
Applications with many users must test on tens or hundreds of devices. Developers must debug problems on devices that they don't have access to, so they rely on issue reports from users or software which records crash dumps and sends cryptic reports.
This effort can significantly increase the cost of developing an application as the user base increases. It's necessary to make explicit decisions about which devices will be tested and define release criteria and issue triage based on the impact of issues on the user base.
This consulting company found an average of 30% more time for Android on their projects when making the same apps on both platforms, with a lot of variation
Discussion of development issues: