The End of Cross-Platform as We Know It
In 2015 I was a native iOS developer working as a freelancer. I knew Objective C — the only language I could type in my sleep. Swift was still struggling with ABI compatibility, and I was waiting.
When I decided to reenter the job market, everyone wanted React Native.
It was the new kid on the block. Every engineering blog, mainly including Airbnb, shouted from the rooftop about the advantages of write once, ship everywhere. My friends advised me to move to cross-platform, or retire soon.
I was partly OK to learn native Android on the job, if someone offered me that opportunity, trusting my engineering skills in Windows + iOS world.
But I hesitated to go for RN. LinkedIn dumping its HTML5 based cross platform app in 2013 was fresh in my memory. Though React Native was perfectly native in terms of execution, it failed to betray the native feeling the way Objective C / Java did.
My hesitation was validated soon:
I read about the news wherein Facebook — the creator of RN — announced switching its iOS app main page (the Newsfeed) to component Kit — a framework created based on Objective C++. They heavily borrowed the declarative approach of React, but implemented everything using Objective C++ to harness the true power of iOS architecture — something even Swift is unable to deliver today.
Most frequently used apps today rely on C++ or some of its variants (JNI for Android and Objective C++ for iOS).
Fast forward to 2020.
Airbnb has famously moved on from RN already in 2019. It created enough buzz across the engineering community to force a rethink. In the same year 2019, Apple released SwiftUI, a declarative UI framework to woo newbie developers once again past its Swift misadventures (now stabilized though).
What makes the bell ring for Cross-Platform:
Cross-platform apps suffer already from their inherent flaws. Time is ripe now for them to take improve or die, with changing market equations.
#1 — Apple Is Consolidating:
#1: Apple is already reigning when it comes to developer revenue
It’s an open secret and has never changed. Despite its market share, Android lags far behind Apple in revenues earned from apps. This is not only because Android leads in low-income parts of the world, but also because Android’s core business line is licensing, not hardware making.
As a result, iOS + iDevice updates are more in line with its higher-paying user demands.
#2: Apple’s Systems are quite matured for mobile experiences:
Despite non-Apple manufacturers leading many smartphone innovations.
Due to its tighter control on OS & hardware together, Apple is much better poised to provide superior + personalized experience that high-value users seek in a mobile device.
Due to its recent drive to become a privacy-focused software ecosystem, Apple will continue to be dominant in enterprise mobility solutions as well, for obvious reasons.
To a developer, revenue split up between Apple and Android is oversimplified like this:
Developing for Apple => High Value, Paying Users => Revenue from app sales
Developing for Android => Low Value Users => Revenue from advertising
Apple recently made it mandatory to ask for user permission to share advertising data. It was a direct blow to companies whose sole asset is advertising data —obviously Facebook and Google.
It’s not a coincidence that they happen to be makers of React Native & Flutter.
One can easily see what this means for app developers: Be clearer (more than earlier) about your ideal user-base. Make your choice sooner than later, and choose your toolset accordingly.
For example, if advertising is not on your mind, you may be better off developing for Apple first. After validation, ship to Android. Such a fragmented approach has little incentive to go with cross-platform development. As long as the team remains the same, common codebase requirement can be easily fulfilled.
#3: Apple Silicon is Apple’s trump card in the app economy:
Plus, the pie for desktop development on the mac is going to be much bigger than it is today.
Until & unless some disruptive hardware company comes out of the dark.
Google is a sizable challenger, but not a formidable one. Its main aim to be in the mobile space is not to sell software, but to be on top of user data. Without winning on hardware, as it already confessed publicly, it is difficult to tilt this balance. Adoption of Android is directly depending upon the hardware manufacturers it licenses to.
With Apple Silicon, Apple has unified its developer community. It was already paying developers more. Now with Apple Silicon, iOS developers can easily ship to new Apple macs.
Plus, the pie for desktop development on the mac is going to be much much bigger, given the killer performance of M1 macs.
The move has made it much more lucrative to develop for Apple, using its own tools: XCode, Playground, and such, using Apple Silicon powered macs, because it enjoys complete control of its hardware. There are clearer incentives for going all into a single platform, at least initially, and no developers/startups would miss that advantage.
#2 — Cross-Platform is a nudge, not innovation:
It’s a nudge telling monopolies:
Here, I challenge you to innovate. I can’t make a better IDE/hardware, but I can deprive you of some of your earnings/developers coming off of them.
Time and again, cross-platform tools offer themselves as a panacea for every platform-specific problem.
Without underlying hardware, they are simply a challenger to monopolies who often have high-cost entry barriers. The cost of a Mac machine vs that of windows is the most cited criteria.
Another reason for their quick adoption is not their superior capability to create better experiences, but the developer grievances with proprietory platforms.
Every $10M+ startup hires a mobile dev to maintain a common-codebase that’s eventually hanging on the support of a remote GitHub contributor
They are available as open-source. Quick-start projects, Youtube tutorials and $100 templates flood developers’ feed with poorly founded premises:
- What can be achieved with cross-platform apps that is not easily done using native! (5 lines of code vs 3 classes!). Don’t look at the possibility of customizations that native offers vs what those 5 lines hide under the hood.
- It offers the unique advantage of common business logic — an offer any startup can’t resist. As a result, every $10M+ startup hires one mobile dev to maintain a common-codebase that’s eventually hanging on the support of a GitHub contributor. What companies don’t realize is the fact that common business logic must be maintained by clear documentation (eh? what’s that) and concise specs (but we are Agile!)
- Luckily, if those startups make it past a revenue point, and if there is developer churn, growth strategies kick in, and dwindling rating on app store/play store + investor pressures force the founders to rethink their original decisions of going for quick + dirty solutions. That explains later adoption of native for LinkedIn, Facebook for iOS, Airbnb, and countless others.
- Yet, budding startup numbers never dwindle, and the market for cross-platform developers never dries up. Long live the spirit of revolt! But here is the reality check: If you know C++ (or Objective C and its variants) or Java, your skills will remain relevant after decades. If you spruce up your CV with a fancy cross-platform open-source toolset, be prepared for a complete shakedown every 3–5 years.
#3 — Cross-Platform Sucks. Period.
They are developed to be shipped, not maintained.
When it comes to cross-platform, confusion pursues.
Today’s cross-platform offerings produce nearly 100% native code — there is no doubt about it. Xamarin, React Native, and Flutter (?) — all promise 100% native execution.
They are unlike PWAs that run in browser and HTML5 of yesteryears.
Update: I could be wrong in my above claim about Flutter producing 100% native code — for further details, please read this quite insightful article aimed at Flutter.
In design, every cross-platform toolset (what else?!) is a complete antithesis of every code-organization principle. They are made of 500+ packages downloaded from disparate, unmonitored sources (instead of from native libraries), mimicking the web development approach. Adopting this approach for mobile development — whose source code is deemed public (= vulnerable to reverse engineering), not within the boundaries of a server controlled by developers, one can only imagine the risks.
Cross-platform tools are easily adopted because they provide higher-level abstractions that beginner programmers easily understand. They amalgamate the differences between different underlying native APIs. They adopt the most common denominator functionality and leave the rest of the customization to developers.
Imagine a hypothetical functionality F that has the following implementations in native iOS and Android:
iOS: function f (int a, int b, int c)
Android: function f (int a, int b, int p, int q, int r)
A typical cross-platform package would provide the following:
function f (int a, int b)
If you want the full power of both platforms, you must figure out c, p, q, and r tweaking in native code i.e. Objective C and Java.
In my last organization, due to shortcomings of existing Flutter notification packages, developers had to develop in:
i) Dart
ii) iOS plugin
iii) Android plugin
It came off as buggy, because Flutter devs were only familiar with XCode / Android Studio, not well-versed in Objective C / Kotlin APIs.
Most cross-platform enthusiasts are college kids who created their first software in those libraries, and can’t forget their first love. They build cross-platform apps to be shipped, not maintained.
The real hell starts when you are forced to download a package to implement a simple feature such as device info.
Most cross-platform enthusiasts are college kids who created their first software in those libraries, and can’t forget their first love.
On average, while a mobile app developer saves only 20% time developing a singular code-base (against 50%, because of requirement conversion + customizations), package management eats up 70%+ time of the maintainer.
A react native app suffers from some very serious capability + performance-related problems that are unearthed later in the development cycle.
A typical flutter app is oversized compared to natively developer IPA and APK.
In my last organization, I altered 70+ dart files in response to a compatibility break in Flutter’s Equatable implementation.
That wasn’t painful until I came to know the reasoning behind it: The earlier hashing algorithm produced the same hash for interchanging values of properties within an object!
In other words, the following objects will produce the same hash in the older, buggy implementation, unless you explicitly overrode the Equatable hashing function, which was never a mandatory requirement prior to 1.0!
Object A:
x = 3, y = 4
Object B:
x = 4, y = 3
Imagine checking all your 500+ packages for an equality check vulnerability….😧
I questioned my architect why Flutter was adopted in the first place for a data-intensive app like ours.
His response was worth the weight of his words in gold:
“One of the goals of Agile, cited by management, is to avoid non-value yielding operations, such as documentation. Common code-base is our documentation and a single source of truth.”
#4 — Cross-Platform is an undependable dependency:
This problem is not inherent to cross-platform. But it is tightly coupled with it being shared via open-source.
Repo-owners hold uncanny powers
The problem exists due to two reasons.
First, GitHub (and its counterparts) is uncurated, yet answerable to the laws of the land. It can take down anything any time upon a legal shakeup.
Second, repo-owners hold uncanny powers over the work of contributors, no matter how big it is.
The tyranny of repo-owners is infamous already in the blockchain world, where founding contributors hold the upper hand in setting the rules for coin distribution.
Open source has been utilized by all leading companies (including FAAMG) to make their SDKs available + open for bug fixes. Companies hired developers en-mass to maintain a sense of community, watch over the developers’ interests, and ship features based on popular demand.
When they don’t, their core offerings suffered.
Not in the case for cross-platform providers. There is virtually no incentive involved for them to respond to serious bugs or crucial enhancement requests. As a result, there are no consequences to mishandling of GitHub issues.
If Flutter got serious bugs, Google won’t see any decline in already negligible Pixel sales or its mammoth search volume.
If React Native lacked a feature, Facebook ad revenues won’t flinch.
But if Android/Kotlin or iOS/Swift gets serious vulnerability, Google and Apple will surely suffer — Google from licensing revenues and Apple from iPhone sales. And revenues lost by the 30% developers cut.
So unlike those native platform owners who release hotfixes at midnight, cross-platform developers provide cold shoulders to developer requests.
Better responders write a formal response to issues, and closes them unilaterally, with no follow-ups. In the absence of proper documentation, the only way for developers is to delve deeper into the package/library code, fix the issue, and ship their apps.
Sometimes, they are enticed by library developers to contribute back, which is again without any incentives, all in the spirit of open source.
To a developer who was promised an efficient cross-platform implementation, it is 2 down: More time spent on bug + feature requests open-sourced.
But there’s worse.
To add insult to injury, their PRs are sometimes rejected/neglected by repo-owners, citing it as a non-issue to keep their record book clean.
Until high-salaried cross-platform repo owners treat their low-salaried peer innovators as equal, things are only likely to deteriorate.
Their cross-platform project is doomed to remain a great nudge disguised as innovation, as experienced developers transition to better, platform-native solutions.
Conclusion:
Cross-platform development will quickly begin to mean single platform development for multiple devices
Out of all mobile development makers, Apple is the only company whose true line of business is hardware. With the unification of their platforms, it has sent a clear message to its developers: You are crucial to our services business, and we care for your growth.
It’s too early to forecast its longtime market dominancy. Google has deep pockets to fuel its native Android platform and make it more enticeable to developers.
While Apple alone cannot shake the entire cross-platform community, it is surely in a position to force its rivals to adopt a more structured, more maintainable, and less failure-prone approach towards mobile development.
The word cross-platform development will quickly begin to mean single platform development for multiple devices, like .NET in its early days.
Startups will do well to lay cross-platform at rest. The lure of the common codebase must be replaced with good old documentation, to cultivate truly common business logic in developers’ minds.
Your customer deserves the best-unified experience offered by native platforms.
Your developers? Rest (no pun intended) + Respect.