When clients first contact us about building a mobile app, they often wonder if they should build separate native mobile apps for both Android and iOS platforms, or if they should use a cross-platform framework.
In the past, cross-platform frameworks have gotten a bad rap, and for good reason. They were slow, they didn’t look or feel like a native application, and some were abandoned by their original developers. However, things have changed since then.
Cross-platform can achieve significant capital cost savings and make launching your mobile app easier. But that comes at the cost of design flexibility and platform risk. Before choosing, consider the tradeoffs carefully.
The first question to ask when choosing a native mobile tech stack is, “Does your target audience using Android or iOS?” Market share doesn’t tell the whole story, but it can be a good place to start. Currently in the US, mobile market share stands at 53% iOS and 47% Android. Worldwide, Android is stronger and holds a 76% to 22% edge over iOS. For a US-based product, it’s usually advisable to release to both platforms in order to reach the maximum number of potential users.
If you decide that you need software for both Android and iOS, you have to options:
- Native-Native: Develop the app twice, once on each platform, using the most up-to-date languages (Swift for iOS, Kotlin for Android). Leverage technologies and toolchains that are blessed by Apple and Google.
- Cross-Platform: Develop the app once-ish (more on that later), using a third-party cross-platform framework that allows you to have some code shared across both Android and iOS.
The decision to go cross-platform instead of native-native comes with several benefits and tradeoffs.
Benefits of Cross-Platform Mobile
1. Pseudo-homogenous Codebase
Modern cross-platform frameworks are written in languages that are also strongly represented on the back end. This allows your organization to focus on a single language for the client and server-side of the things and to hire developers who can more easily move between codebases. Some examples:
- Xamarin.Forms & ASP.NET Web APIs
React Native and Ionic are especially interesting because the development patterns applied in their respective frameworks can be applied to web application development: React.js and AngularJS, respectively.
2. Lower Costs
A shared codebase means less duplication of features across both Android and iOS applications, so the cost of initial build and follow-on updates should be less. Note that code sharing is not a silver bullet. It doesn’t cut costs in half. Plan on a cross-platform solution costing 150%-175% of a single native application.
As an example: if building in Swift on iOS would cost $200,000, budget $300,000-$350,000 to do it on a cross-platform framework. Reasons for extra overhead include: deploying to multiple app stores, extra effort testing on Android and iOS, framework-specific bugs, overhead in dev tooling (especially with Xamarin.Forms), and the need to write purely native code for each platform when dealing with lower-level abstractions and hardware integrations (e.g., Bluetooth).
3. Consistency of UI Components / Look & Feel
Frameworks like Xamarin.Forms and Ionic give you off-the-shelf UI components that will reduce the pain of UI differences between mobile platforms. The downside is that in some cases, the UI will deviate from native guidelines–Apple’s Human Interface Guidelines, for example. This problem is less pronounced today than it was a half-decade ago.
Tradeoffs with Cross-Platform Mobile
1. Updates and Maintenance
Apple and Google regularly update their mobile operating systems, adding new features and making changes to APIs. All mobile app developers should expect to spend time updating and maintaining their apps. Apps built with cross-platform frameworks have the additional complexity of waiting for the framework itself to update to support the new native features/APIs. Expect these updates to be delayed and take longer to implement when using a third-party cross-platform framework.
Generally speaking, all modern cross-platform frameworks can be made performant enough to be acceptable, but it sometimes takes more work to get them there. Performance problems can manifest as slow UI interactions (stutters while scrolling, slow navigation, etc.) and long start-up times. In our experience with Xamarin.Forms, development startup time was nearly always a concern, even for very simple apps. We’ve also had issues with slow animations on React Native. This is an issue that should be carefully tested during development as performance issues can really ruin the user experience.
3. Lack of Broad Adoption
If a third-party framework is not widely adopted by the development community, there is a real risk that it could be killed off due to lack of maintenance or suffer from very slow updates. Care should be taken to choose a framework that has either a broad, thriving open-source community contributing to it or is a backed by a major corporation. For these reasons, React Native could be a good choice since it checks both boxes: developed originally by Facebook and with a very strong OS community. Another strong option is Xamarin, which is backed by Microsoft’s commitment.
4. Development Environment
Development speed and quality are heavily impacted by the quality and efficiency of the environment where developers are working. We have found React Native’s development experience to be fantastic in this regard. React Native supports hot reloading: If you save a file, the app is reloaded in seconds within the simulator. This allows our developers to move through feature work much more quickly, especially when it comes to tweaking UI components and polishing the feel of an application. Xamarin.Forms, on the other hand, requires a lengthy recompilation step where a developer sits idle for 30-90 seconds before the simulator launches with the updated app.
Take care when making the decision to go with a cross-platform framework for native mobile app development. It’s not for everyone–Airbnb made waves last year when announcing it was leaving React Native. I’d love to hear below what other considerations contribute to your decision!