The myth of the cross-platform mobile application is as old as the iOS + Android duopoly. Back in 2008, a small Canadian company called Nitobi Software released a JavaScript-based framework for cross-platform mobile applications called PhoneGap. Adobe snatched Nitobi in 2011, right after realizing that Steve Jobs was right, and that mobile apps based on Flash were nothing else than a chimera.
Adobe then took the commendable decision of donating PhoneGap to the Apache Foundation, becoming Apache Cordova (and featuring a decidedly wrong spelling of both a Spanish and an Argentine city name), and Adobe PhoneGap became a distribution thereof (think Linux or Kubernetes). Adobe finally announced its demise and shut it down in 2020. Dominus providebit, Dominus abstulit, sit nomen Domini benedictum.
And PhoneGap was far from the only option available; this author enumerated many others in October 2009. Interestingly, Java is not a prominent item in the list.
At the time of this writing, the crapps (cross-platform mobile apps) market is dominated by Xamarin (C#), Ionic (TypeScript), Dart (Flutter), and by the biggest software development scam of all time, React Native.
There are two major problems with crapps developed with the tools enumerated above. The first is the most obvious one: the abysmal level of user experience provided; we are not going to dive into this issue right now.
The second problem of crapps, however, is a bit more subtle and of economic nature; and is as important as it is ignored. It has to do with the law of diminishing returns. Said law
…defines a point on a production curve whereby producing an additional unit of output will result in a loss and is known as negative returns. Under diminishing returns, output remains positive, however productivity and efficiency decrease.
The hypothesis of this author is that, in the current duopoly situation, the cost of developing a crapp is actually higher than that of developing two apps using the officially sanctioned toolkits for iOS and Android apps.
You heard it right: by using any of these fancy cross-platform mobile app frameworks you are spending more money, and achieving a less-than-optimal result.
In other words, there is absolutely no economy of scale (or of any other kind) provided by using a cross-platform mobile app framework. Not even small economies. There is absolutely no advantage at all, whatsoever.
This bold claim is based on the personal experience of this author, who made a living by exclusively building mobile apps for those platforms from 2008 to 2019, and who also wrote two books about the subject of mobile apps based on web technologies.
Building a complicated, reasonable, interesting, stable, maintainable mobile app for iOS and Android is not just writing the code; there are many more factors that come into play. Let us mention just a few, those that are negatively impacted when working with cross-platform toolkits:
- Tightly monitoring battery consumption and memory usage;
- Integrating with hardware features, including wearable devices;
- Debugging, maintaining, and troubleshooting;
- Keeping up with new operating system features every year;
- Enabling widgets, and taking advantage of any kind of extensions;
- Offering non-cross platform compatible “native” features;
- … and many more.
Cross-platform mobile app frameworks kind of made sense during the short time when Windows Phone existed. In those times (and with careful design), adding a third build product for Windows Phone incurred a relatively low overhead compared with the rest of the development cost, but only for small, simple apps.
The reasons why teams choose cross-platform toolkits for their projects stems less from a technical standpoint than with the lack of unionization in the software industry. It is a simple way to business owners to reuse manpower from one project to the other, making a false economy and leading software developers to burnout and abuse.
Of course, all of the platforms enumerated above include some kind of “plugin system” enabling access to some iOS or Android specific features. The biggest problem with these plugins goes beyond maintainability (since most of them are not provided by the original framework developers); it is rather a conceptual and (again) economic issue.
This is the gist: the mere existence of those plugins highlights the fact that iOS and Android offer quite different user experiences and features, effectively killing the promise of those frameworks. This is a subtle issue, not considered by developers blinded by the quick “Hello World” experience shown in the tutorial.
As said above, this is a subtle issue; it is also, sadly, a massive one. The level of technical debt introduced by these frameworks render them useless for large projects, and can effectively sink whole companies.
Bluntly speaking, using a cross-platform mobile app framework is a great way to solve bugs in one platform, while inadvertently adding some more in the other.
In other words, they are another, spectacular example of a leaky abstraction.
All non-trivial abstractions, to some degree, are leaky.
As a software developer, I can only recommend using tested, boring, stable technologies for your mobile apps (or really, for any kind of app). Use Kotlin with Android Studio for your Android app. Use Xcode and Swift for your iOS application (but not SwiftUI, at least not yet at the time of this writing). Build two different apps, talking to the same REST backend; and push logic to that layer, so that you can reuse it where it makes sense. Use native components following the user experience guidelines set forth by Google and Apple. Make both apps eat as little battery as possible, and make them use as little memory as possible. Make each of them fast, using the tools provided by each vendor.
Apply the best ideas and the best patterns for each platform, separately.
And if you ever need to share code between your iOS and Android apps, you can always use C++; which was the solution adopted by Dropbox for almost a decade. You can encapsulate algorithms and data structures in a native library built with C++, and then make your Android and iOS app use that code. Complex? Yes. Based on boring and mature tools? You bet. Yielding really fast code? You have no idea.
Building separate apps for each platform means lower maintenance costs in the long run, and an optimal user experience everywhere.
Because, let us be frank; it does not seem like the duopoly will be over anytime soon. There will be Android and iOS for quite a while, and there are no viable competitors in the horizon from an economic point of view.
Cover photo by Lindsey LaMont on Unsplash.
