Comparing mobile development in iOS vs. Android (original) (raw)

When an organization builds a mobile app, many decisions come down to Android vs. iOS. The right approach can minimize development costs and support a positive user experience.

To effectively develop an app for iOS or Android, IT must understand how their development environments differ.

It's easy to get started in mobile software development -- administrators just have to pick the platform and language that their programmers already know, preferably the one that is free. But that choice doesn't take the cost of tools, the viability of the platform and various other factors into consideration. Which mobile devices are most popular with users? Is the team able to provide sufficient support? What is best for the organization?

Android and iOS both have different style guides. As a result, writing for both requires two teams. Otherwise, the app will have a look and feel that is unfamiliar to at least one user base. Organizations might be able to lock support down to a specific device and OS version for internal apps, but public-facing apps will have much more demanding users. Then there are watches and tablets to consider, along with the costs of training and long-term support.

Several decisions go into mobile app development, from design guidelines and layouts to distribution and monetization strategies. The OS the app caters to affects many of these decisions. Making conscious choices about what platforms to develop on can help ensure a smooth development process.

Understanding Google Android app development

The Android OS is free and open source. It comes with the Chrome browser, along with Gmail, Calendar and other Google apps. Hundreds of brands build Android devices, and they need to innovate on both features and price to stay relevant. This device fragmentation also means that organizations have to consider the different screen sizes and OS versions on the Android phones their users might have. With both initial app design and subsequent updates, Android developers must take extra time to ensure compatibility for different devices across their user base.

Because it is open source, developers can also compete to make development environments and compilers for Android. While Android has a strong Java tradition, Android apps do not run on the Java Virtual Machine. Instead, they run on the Android Runtime. Android's free integrated development environment (IDE), Android Studio, supports both Java and Kotlin. The two programming languages are similar, but Java is slowly being phased out, and Kotlin is less verbose.

Because Android is open, developers can build and deploy apps independently or on a third-party store.

The workflow for Android starts out in much the same way as traditional development. Programmers write code in an IDE and commit it to version control. A continuous integration/continuous delivery tool then builds the code into a package and deploys it. With deployment, the Android app becomes available in the Play Store once Google has reviewed and approved it, which can take a few days. Because Android is open, developers can build and deploy apps independently or on a third-party store. Still, those options lack the discoverability of the main Play Store.

If an IT team finds a bug on Monday and fixes it on Tuesday, the fix will not be live on the Google Play Store until Friday. Unlike a web deployment, which could take minutes, a new app deployment tends to involve more communication and coordination. To mitigate this challenge, it helps to be able to do separate releases for beta testers. This way, teams can keep both a "stable" version in the Play Store and a "latest" version in a special release.

Understanding Apple iOS app development

Because Apple is the only manufacturer of an integrated, closed system, it offers richer commercial support, as well as less choice for developers. The main development environment for iOS applications is Xcode, which runs on Apple platforms only. Organizations that live and breathe Microsoft Windows and .NET must purchase Mac computers for their programmers. The other option is to outsource, which will require a support plan when the main development contract ends.

While it is possible to program for Kotlin on iOS, this is a cross-platform mobile development approach, which has some drawbacks. Swift has become the standard programming language for iOS, which Apple touts as intuitive and easy to learn. Perhaps more importantly, Swift places an emphasis on code safety. This prevents the common C and C++ programming mistakes with object references, null pointers and out-of-bounds index references.

Developing for iOS in the Apple ecosystem offers several advantages. For example, launching an app on an Apple Watch is as simple as clicking "Show App on Apple Watch" from its paired iPhone. Xcode also supports VisionOS, the operating system for Apple's VR headset. SwiftUI, the UI extension for Swift, runs on all the platforms, which means developers can code for the Apple Watch, the iPhone, the iPad and the Vision Pro in the same environment.

The timeline for an app to undergo review before reaching the Apple App Store is typically about two days. However, the review process for nonstandard apps and new apps can take much longer, especially if they ask for numerous permissions. Apple's beta test tool, which lets users try versions of the software before it hits the App Store, is called TestFlight. Again, Android offers choices, while Apple offers one straightforward, prechosen experience.

Alternatives to iOS or Android application development

Organizations don't necessarily have to choose between the iOS platform and the Android platform. Three alternatives to consider are cross-platform mobile development, hybrid applications and progressive web applications (PWAs).

Cross-platform mobile development involves creating source code in a single programming platform, then having that platform build from the single set of source code across different OSes. Examples of cross-platform development tools include React Native and Flutter. React Native is a mobile and web app framework where programmers write code using a JavaScript library. Flutter is an open source framework where programmers write code in Dart, which compiles down to target iOS, Android, web, Mac, PC or even Linux applications. Microsoft also offers the .NET toolchain to write mobile apps in C# for iOS or Android.

Another option is to develop a hybrid app. Hybrid apps combine a traditional application with an embedded, possibly full-sized web browser, pointing to a website. This cross between native and web development enables programmers to write in HTML5, CSS and JavaScript, like they would with a web app. Users then download the application from an app store, like they would with a native app. Hybrid apps can also use some device-specific resources via internal APIs.

Developers can also build a PWA, or a website that acts as if it is a mobile app. Similar to a hybrid app, a PWA uses web technologies such as HTML and JavaScript. To provide a suitable UX for mobile users, it will resize to fit the device's screen. It can also appear on the device's home screen, send push notifications and work offline. The user feels like they are double-clicking a mobile app, but the programmer only has to write one webpage that works for both desktop and mobile. Unlike a hybrid app, though, a PWA doesn't use OS-specific APIs and wouldn't be available on an app store, instead running in a browser.

Both hybrid apps and PWAs can create challenges around security and consistency for login. Most mobile apps enable cached auto-login or at least the use of Face ID. Making the hybrid web experience seamless can require extra precautions, such as using Apple's Keychain services or the AccountManager functionality in the Android API.

The idea of "write once, run anywhere" is attractive, but it has a few major drawbacks. First, the user interface standards between iOS and Android are different. Apple users navigate through tabs at the bottom. The Android standard is the navigation bar at the bottom, which doesn't exist for Apple. Android has a "back" button, while in iOS the standard is an "up" button in the hierarchy. Programmers will need to code to one standard or the other. The users that are left behind might experience friction and discomfort. In addition, cross-compiled frameworks are inevitably written by an external provider, addressing at least two moving targets. They're designed to help an organization take shortcuts.

One thing to consider for cross-platform support is what that software will do. It might, for example, call other APIs for login, search and other commands. In that case, the app could mostly be a user interface, glue code and display code. If teams can create the APIs and UI design once, it might not be too much effort to write the UI and API client code twice. This does mean adding two sets of programming knowledge to the organization. However, in the age of online training and approachable tool sets, that might be a solvable problem.

How to choose a development approach

To find the right approach, admins should evaluate the demographics of their customer base and the needs of their IT team. According to StatCounter, Android holds about 70% of the global market share, making the OS a better pick for organizations that have a larger international presence. Of course, this might differ based on the region and the customer's role. In the U.S. specifically, Apple has over 50% of the market share, whereas Android has about 42%.

Large Java shops might want to start with Android, with its tradition and support of Java. Likewise, a .NET shop that isn't worried about supporting smartwatches and virtual headsets might want to start with .NET's multiplatform support. Marketing and creative agencies might have Apple devices on every desk or find it easier to get started with Xcode and iOS.

Outside of these clear choices, there are two components to the decision: a business analysis of which OS is better for the app's target audience, and a technical analysis of which OS makes sense for the development team. It can be intimidating for an organization to invest in learning different programming languages and platforms. Consider setting aside a little time to try both and experiment. It's a lot cheaper to conduct some failed experiments than to restart a failed deployment after a year of going all-in with one approach.

Author's note: The author would like to thank Michelle Bernardon and Rob Vander Sloot for their peer review and feedback. They made the article better.

Matt Heusser is managing director at Excelon Development, where he recruits, trains and conducts software testing and development.