Back in 2015, I was working as a freelance native iOS developer. I know Objective C — it’s the only language I can write in my sleep. Swift is still working on ABI compatibility issues, and I’m still on the fence.
When I decided to re-enter the job market, everyone wanted React Native.
I’m new in this field. Every engineering blog, mainly Airbnb, preaches the advantages of “write once, publish anywhere.” My friends advised me to switch to cross-platform or retire immediately.
If someone offers me the opportunity, trust my engineering skills in the Windows + iOS space, I can learn native Android on the job.
But I hesitate to study RN. LinkedIn’s abandonment of its HTML5-based cross-platform app in 2013 is fresh in my mind. Although React Native is completely Native when executed, it doesn’t have the same raw feel as Objective C or Java.
My hesitation was soon confirmed:
I read in the news that Facebook, the creator of RN, announced it was switching its iOS home page (news stream) to the Kit component, a framework built on Objective C++. They borrowed a lot from React’s declarative approach, but implemented everything in Objective C++ to take advantage of the true power of the iOS architecture — something that even Swift doesn’t yet offer.
Most commonly used applications today rely on C++ or some variation of it (JNI for android, Objective C++ for iOS).
Fast forward to 2020.
Airbnb abandoned its continued use of RN back in 2019. This caused enough stir in the engineering community to force a rethink. In the same year of 2019, Apple released SwiftUI, a declarative UI framework designed to once again lure new developers through its Swift disaster (though now stable).
What’s the death knell for cross-platform: Cross-platform applications have inherent drawbacks. As the market continues to change, now that the market has matured, they will either improve or die.
Apple is consolidating
Apple already dominates when it comes to developer revenue
It’s an open secret that hasn’t changed. Despite its large market share, Android lags far behind Apple in terms of app revenue. That’s not just because Android leads in lower-income parts of the world, but because its core business is licensing, not making hardware.
As a result, the iOS + iDevice update is more in line with the needs of its high-paying customers.
Apple’s system is very mature in terms of mobile experience
That’s despite the fact that many smartphone innovations have been led by non-Apple manufacturers.
With tighter control over the operating system and hardware, Apple has done a better job of delivering the superior + personalized experience that high-value users are looking for on mobile devices.
With Apple’s latest effort to become a privacy-centric software ecosystem, it’s clear that apple will continue to dominate the enterprise mobile solutions space.
For developers, the revenue split between Apple and Android is pretty simple:
- Apple development => high value paying users => app sales revenue
- Android development => low value users => AD revenue
Apple recently forced apps to request user rights to share advertising data. This is a direct blow to companies whose only asset is advertising data — notably Facebook and Google.
It should be no coincidence that Facebook and Google happened to be the creators of React Native and Flutter.
You can easily see what this means for App developers: further understanding your ideal user base. Make your choices early and choose your toolset accordingly.
For example, if you don’t want to advertise, you’d better develop an Apple app first. After verification, develop android apps. Such fragmentary solutions have little incentive for cross-platform development. As long as the team stays the same, the common code base requirements are easily met.
Apple Silicon is Apple’s trump card in the app economy
Unless some disruptive hardware company comes out of the darkness.
Google is a sizeable challenger, but not a formidable one. Its main purpose in mobile is not to sell software, but to master user data. Without winning on hardware, as it has publicly admitted, it will be hard for Google to break that balance. Android adoption depends directly on the hardware manufacturers it licenses.
With Apple Silicon, Apple has integrated its developer community. It has already paid developers more. Now with Apple Silicon, iOS developers can easily migrate to the new Apple Mac.
This move makes it more profitable to develop Apple apps using its own tools: XCode, Playground, etc., using Apple Silicon powered Macs because it has complete control over its hardware. There’s a much clearer incentive to get everyone on board with one platform, at least initially, and no developer or startup is going to miss that advantage.
Cross-platform is about incremental improvement, not innovation
It’s an incremental improvement that tells the monopolist:
Now, I challenge you to innovate. I can’t make a better IDE or hardware, but I can take away some of the revenue or developers you get from it.
Time and again, cross-platform tools present themselves as a panacea for every platform-related problem.
Without the underlying hardware, they become challengers to monopolies, which have high barriers to entry costs. The cost of a Mac machine versus a Windows machine is the most cited metric.
Another reason for their rapid adoption is not their ability to create better experiences, but developers’ dissatisfaction with proprietary platforms.
Every $10 million-plus startup hires a mobile developer to maintain a code base that ultimately relies on support from remote GitHub contributors
They can be open source. Quickstart programs, Youtube tutorials, and $100 templates fill the developer’s information stream, but it’s almost impossible to find evidence:
Cross-platform apps can do things that aren’t easy to do native! (5 lines of code vs. 3 classes!) . Don’t look at the customization possibilities offered natively versus the underlying mechanics of 5 lines of code.
It offers the unique advantage of a common business logic that no startup can resist. Eventually, every $10 million startup hires a mobile developer to maintain a common code base that ultimately relies on GitHub contributors to support it. What these companies don’t realize is that common business logic must be clearly documented (huh? What is that?) and concise specifications (but we’re agile!). Maintenance.
Fortunately, if these startups can get past a revenue point, and if there is a loss of developers, growth strategies step in, and the app Store/Play Store degradation + investor pressure causes founders to reconsider their initial decision to pursue a quick but messy solution. This explains why LinkedIn, Facebook iOS, Airbnb, and countless other apps have adopted native solutions in the late stages.
However, the number of budding startups never waned, and the market for cross-platform developers never dried up. Long live the spirit of resistance! But here’s the thing: if you know C++ (or Objective C and its variants) or Java, your skills will be relevant for decades to come. If you adorn your resume with a fancy cross-platform open source toolset, be prepared to overhaul it every 3-5 years.
Cross-platform sucks
They are developed for distribution, not maintenance.
In cross-platform apps, confusion is constant.
Today’s cross-platform products offer almost 100% native code — that’s for sure. Xamarin, React Native, and Flutter — all promise 100% Native execution.
They are different from previous PWA applications running in browsers and html5-based.
But by design, it is the opposite of every code organization principle. They consist of more than 500 packages downloaded from completely different unmonitored source code rather than native libraries, mimicking Web development methods. One can imagine the risks of adopting this approach in mobile development, where the source code is seen as open rather than within the boundaries of a server controlled by the developer.
Cross-platform tools are easy to adopt because they provide a higher level of abstraction that is easier for beginners to understand. They incorporate differences between different underlying native apis. They take the most common features, leaving the rest of the customization to the developers.
Consider a hypothetical function F implemented in native iOS and Android as follows:
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 provides the following functions:
function f (int a, int b)
If you want to take full advantage of these two features, you have to find C, P, Q, and R tweaks in native code (i.e., Objective C and Java).
In my last organization, due to the shortcomings of the existing Flutter notification package, developers had to develop in the following areas:
1.Dart
2. The iOS plugin
3. Smart refrigerator
Because Flutter developers are only familiar with XCode or Android Studio and not proficient in Objective C or Kotlin APIS, this is considered a flaw.
Most cross-platform enthusiasts are college students who created their first software in a library and can’t forget their “first love”. They build cross-platform apps for distribution, not maintenance.
But when you’re forced to download a package to implement a simple function, such as device information, the real pain starts.
Most cross-platform enthusiasts are college students who created their first software in a library and can’t forget their “first love”.
On average, while a mobile application developer saves only 20% of his time developing a single code base (as opposed to 50%, due to requirements transformation + customization), package management takes up more than 70% of maintainers’ time.
A React Native application suffers from some very serious feature + performance related issues that are discovered later in the development cycle.
A typical Flutter app is much larger in size than native developers’ IPA and APK.
In my last organization, I modified over 70 files to deal with compatibility breaks in Flutter’s Equatable implementation.
This wasn’t painful until I understood the reason behind it: early hash algorithms produced identical hashes for the exchange of attribute values within an object!
In other words, the following objects will produce the same hash value in the old flawed implementation unless you explicitly override the Equatable hash function, which was never a mandatory requirement before 1.0!
Object is A:
x = 3, y = 4
Object B:
x = 4, y = 3
Imagine checking all 500 + packages for equality check vulnerabilities… 😧
I asked my architect why A data-intensive application like ours had adopted Flutter in the first place.
His answer was classic:
“Managers often say that one of the goals of Agile is to avoid worthless operations, such as documentation. The common code base is our documentation and our only source.”
Cross-platform is a dependency without dependencies
This problem is not inherent to cross-platform. But this problem is tightly tied to cross-platform through open source sharing.
The library owner has incredible power
This problem exists for two reasons.
First, GitHub (and its competitors) is unrated, but accountable to national laws. It can destroy anything at any time through legal reorganization.
Second, the library owner has incredible power over the contributors’ work, no matter how big the library is.
The tyranny of library owners has become notorious in the blockchain world, where founding contributors have the upper hand in setting the rules for the issuance of blockchain coins.
All the header companies (including FAAMG) are already using open source to make their SDKS available + open to bug fixes. Companies hire developers to maintain a sense of community, focus on developers’ interests, and release features based on public demand.
If they don’t, their core product will suffer.
This is not the case with cross-platform vendors. In fact, they had no response to serious bugs or critical enhancement requests. Therefore, there are no consequences for them for mishandling the GitHub issue.
If Flutter had serious bugs, Google would not have made any dent in the already paltry Pixel sales or huge search traffic.
If React Native lacks a feature, Facebook’s AD revenue won’t shrink.
But if Android/Kotlin or iOS/Swift had a serious bug, Google and Apple would certainly suffer — Google in terms of licensing revenue and Apple in terms of iPhone sales. Developers take a 30% cut in revenue.
Thus, unlike native platform owners who release fixes in the middle of the night, cross-platform developers are deaf to developer requests.
A better responder would write a formal response to the questions and unilaterally close them without follow-up. Without proper documentation, the only recourse for developers is to delve into the package/library code, fix the problems, and then release their application.
Sometimes they are coaxed into giving back by library developers without any incentive, all in the spirit of open source.
For a developer who has been promised an efficient cross-platform implementation, these are two disadvantages: more time spent on bugs + feature requests are open source.
But it gets worse.
To make matters worse, their PR is sometimes rejected or ignored by library owners in order to keep their record books clean.
Unless well-paid cross-platform library owners treat their low-paid fellow innovators equally, the situation will only worsen.
Cross-platform projects are bound to be a huge incremental change masquerading as innovation as experienced developers move to better platform-native solutions.
conclusion
Cross-platform development will soon mean single-platform development for multiple devices
Of all the mobile developers, Apple is the only one whose true line of business is hardware. With the unification of their platforms, it sends a clear message to developers: You are vital to our services business, and we care about your growth.
It is too early to predict long-term market dominance. Google has the wherewithal to fuel its native Android platform and make it more attractive to developers.
While Apple alone can’t shake up the cross-platform community, it can certainly force its competitors to adopt a more structured, maintainable and less glitch-prone mobile development approach.
The cross-platform development space will soon mean single-platform development for multiple devices, as well. The early days of.NET.
Startups better not be cross-platform. The lure of a common code base must be replaced by good old documentation to foster true universal business logic in the minds of developers.
Your customers deserve the best unified experience that native platforms offer.
Your developer? Rest (no pun intended) + respect.
The author | Pen all come from the top of the front end The translator | Zhang Jianxin