By Josephus Paye II • May 31, 2022 • Back to Home
In 2022, it’s not really clear what the best way to build a mobile app that is available to both iOS and Android users. Especially so if you’re a small team or a single developer and want to make something good, while, to a lesser extent, enjoying the process of doing it.
The first-party frameworks built by Apple and Google for building iOS and Android apps offer many advantages. The two big ones are quality and performance. Apps made using these frameworks look and feel at home on the platform, and perform well enough to meet most users’ expectations. In terms of quality, these frameworks have been built, documented, and optimized over many years by the platform vendors, who have the business incentive to keep them supported and viable in the long run. Also, they have been proven over and over by the many great apps that have been built with them.
One the other hand, choosing a first-party development framework has a number of disadvantages, the biggest one being development costs in terms of time and effort. If you want to build a great app on both platforms, you have to learn two completely different languages and tools and essentially build the same app twice.
Additionally, with the current transition on both platforms to a new generation of languages and frameworks, we’re currently in this liminal space where one could argue that it’s necessary to learn two languages and two frameworks (on each platform) if you want to build a great app that is also ready for the future. Specifically, on iOS, you could use Objective C + UIKit or the newer Swift + SwiftUI, and on Android, Java + Android Views or the newer Kotlin + Jetpack Compose. On each platform, the older language and framework combo provides a mature and proven option for development, while lacking modern affordances and capabilities. Conversely, the new languages and frameworks, though lacking in maturity and completeness, provide a modern development experience that arguably enables a faster time to market. As of May 2022, iOS developers are still mixed on whether it’s a good idea to go all-in on SwiftUI.
In my case, the development cost of building the same app twice is what removes the native first-party frameworks from the table. Such an endeavor might be feasible at the start, but the bigger the application grows, the more duplicate work you will have to do to keep the apps in sync. This leads to a slower pace of shipping, which can be a big reason why projects die. When it’s not easy to make quick, visible progress on a regular basis, you find your enthusiasm waning over time.
There are many development frameworks these days that purport to help you build apps for iOS and Android from a single codebase. But not many of those will end up producing something great. Admittedly, this is partly a matter of taste and opinion. However, there are a few questions we can ask about the product of a cross-platform development framework that will help us evaluate it’s quality:
There is also the consideration of developer experience. What it feels to use a framework goes a long way in helping a developer build a great app, and finish it on time. A framework with a pleasant development experience will offer most or all of the following:
With those considerations, we can make a list of popular cross-platform framework options that are roughly categorized into three types:
As someone with more experience with the web platform than any other platform, I was naturally drawn to the webview frameworks at first.
Frameworks like Ionic and Cordova provide you a webview injected with extra JS-wrapped versions of common native APIs, allowing you to write an app with HTML, CSS, and JS that’s very close, if not identical, to what you’d write for the web. Initially the two frameworks could be used together, with Cordova providing the native integration and Ionic providing the UI toolkit. But of late, Ionic has replaced Cordova with its own native integration layer.
The reusability appeal here is strong in terms of code, knowledge, and experience. This directly leads to savings in time and cost, and for a certain class of apps, the fit is great.
However, there’s a big price to pay: performance, and arguably, quality. Using the entire browser stack as the base to build on is not exactly light in terms of overhead, and there are certain challenges inherent to UIs on the web that you have to expend disproportionate effort to overcome: achieving a native look and feel, delivering consistently smooth animations, supporting rich interactions via gestures, etc.
As mobile hardware gets better and better, and browsers gain richer native-like APIs and get faster at rendering web interfaces, this gap is narrowing - but it’s certainly still wider than I’d like it to be.