Most startups need a mobile app. Developing for both iOS and Android can be time-consuming and costly, leading many to consider cross-platform tools for writing once and running on multiple platforms.
These tools are enticing, offering simpler, higher-level development and compatibility with iOS and Android. However, except for a limited range of applications, cross-platform tools often disappoint in various ways. There’s a risk of investing more, not less, in development effort.
This article briefly reviews the history of cross-platform tools, explores their shortcomings and explains why developers of non-trivial ross-platform apps face a continual uphill struggle.
A Brief History of Cross-Platform
AppForge, predating the iPhone, was probably the first cross-platform mobile development platform, enabling development for Symbian, Windows Mobile, RIM BlackBerry and Palm OS from a single codebase. This is old stuff but please bear with me for some lingering learnings.
My experience using this powerful yet simple tool revealed that despite its cross-platform claim, slight code variations were needed for Symbian and Windows Mobile due to differing user interfaces. New features often lagged behind the native OSs. Oracle’s acquisition and subsequent abandonment of AppForge in 2007 imparted three key lessons that persist in modern cross-platform tools:
- Supporting different user interfaces with a single code set is challenging. For a genuinely native look and feel, which makes apps feel ‘right’ and appear professional, you’ll need native OS widgets and distinct UI code for each OS.
- Keeping up with evolving native OS platforms is a colossal task for cross-platform tool developers.
- The tool’s longevity is as secure as the commitment of its backing team or company.
Since then, tools like PhoneGap/Apache Cordova, Rhomobile, CodenameOne, Appcelerator Titanium, Xamarin, React Native, RxJava and Flutter have emerged.
There’s been a focus on HTML/Javascript, familiar to non-mobile developers and supported by mature Javascript runtimes.
During my mobile career, I avoided cross-platform tools, sceptical of the ‘future is mobile web’ mantra. These tools often posed more problems than solutions. It’s notable that Mark Zuckerberg and AirBnB expressed regret over opting for HTML5 and React Native, respectively.
Despite ongoing developments, cross-platform tools still face challenges. Flutter, for instance, has a very large number of outstanding issues on GitHub and RxJava’s popularity on Android has waned, overshadowed by Kotlin.
The Problems
Cross-platform tools inherently face several issues. Although some can be mitigated with significant development effort, it’s often not financially viable for cross platform providers to maintain this level of commitment. This is due to the constant updates required to match the ever-evolving native iOS and Android platforms and the expanding array of target devices.
For developers, what begins as a straightforward project can quickly grow complex with the addition of real-world features.
Performance – Any abstraction by a tool leads to performance loss. The extent depends on the quality of the higher-level tool. Efficient coding is becoming a lost art. Abstractions added by cross-platform developers, while helpful for understanding, can significantly reduce performance.
Losing OS-level performance features – iOS and Android have finely tuned APIs for threading, scrolling, gesture support, animation and view recycling, often hardware-accelerated. Replicating these features at a higher level typically results in noticeably slower interfaces.
Adopting different idioms leads to performance drops – For instance, React Native’s reliance on serialised JSON can be costly for data-heavy tasks, and its single-threaded nature limits throughput. Performance isn’t just about speed; app size matters too. Cross-platform runtimes supporting all features can be bulky, often bundled with the app regardless of feature usage.
Look and feel – Web-based tools use WebViews, subsets of standard web browsers. Achieving a look and feel close to native Android and iOS requires significant effort due to browser fragmentation. Another challenge is keeping up with the evolving aesthetics of iOS and Android. If a tool simulates rather than utilises actual OS widgets, apps may suddenly appear outdated.
Features – Cross-platform tools bridge or cross-compile features from the native platforms, requiring specific code within the tool for each feature. This is especially true for tools using WebViews, as direct browser access to many APIs is limited Common features include navigation, phone functionalities, specialist libraries and programming idioms. However, as apps evolve, they often need more complex features, leading to the realisation that the platform cannot support a critical function, often forcing a shift to native development or more complex, a Frankenstein mix of cross-platform and native.
WebViews
The expectation that HTML abstracts away platform fragmentation is misguided. Real applications using bridging code in browsers encounter similar fragmentation issues to native development.
WebViews introduce additional fragmentation due to varied HTML support across devices and manufacturers. Achieving functionality across multiple devices can be exceedingly difficult. WebViews also present unique web-based security vulnerabilities, especially on Android.
Breaking Changes in the Native Platform
Native iOS and Android APIs evolve, leading to deprecated APIs and occasionally breaking changes. This can render apps incompatible with updated OS versions. Cross-platform tool users rely on the tool provider to keep pace with these changes, often a daunting task.
Apple Policing
Cross-platform apps risk rejection from the Apple App Store, as Apple may deem them ‘non-app-like’, produced by an app generation service, cross-compiled or using external code. Apple’s stance is that HTML5 apps belong in Safari, not as standalone apps, and their App Store policies are subject to change.
Summary
Using cross-platform tools often leads to unforeseen complexities and limitations. While suitable for simple or short-lived apps and prototypes, critical business apps should ideally be developed with native iOS and Android tools and languages.
