I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.
Very few companies have ever failed because their tech stack didn't scale well.
If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten.
Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity.
I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front.
Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite.
So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.
1. JSON parsing
2. Network calls
3. Background downloading
4. Notifications
5. Camera access
6. Password/contact/code auto fill
7. VoiceOver
8. Web Views
9. JavaScript bridging
10. Encryption
11. And many more
Almost every app needs some combination of those and in some of these cases you’re forced to use a native solution. What ends up happening is that a significant amount of developer resources gets wasted bridging many of these things with massive bug logs to go with them. It’s why at this point I refuse to do anything but native in my career.
Point well taken! If I may ask, would you say that
1. it's a problem inherent to developing on mobile (whatever the underlying reasons, hardware iterations, idk), and that OS APIs are indeed trying to solve as best they can (it's just a hard problem),
or rather
2. that it's a problem somehow created by OS vendors of their own volition? (a.k.a "evil microsoft walled garden", cue "Apple's take on that" and Google's similar moves for Android and we think Fuschia) In essence a business-driven reality.
I actually don't care about "evil" (hence the wording, it's funny) when it's just business strategy; my deeper question is really about the problem space.
Like, is this forever (native versus cross on a fast-iterating platform), is this industrial politics or technical limitations, could some other platform do it "better" (thinking of SailfishOS, or the Linux phones like the Pine project etc.)
Well if they're doing it like that, it's indeed not much better than hara-kiri. There are better ways :)
How you do it is incrementally, avoiding too-major changes at once, and progressively moving from codebase A (cross-platform framework) towards codebase B (new native thing). But it happens at the integration level, i.e. you build with increasingly more % from B, but during the whole A->B transition it'll be a hybrid build.
E.g. part Flutter / part native.
1. You begin with "let's take camera stuff out of Flutter and re-implement our related features using native APIs": this instantly makes two apps (iOS, Android) with 90-99% code in common, just a fork to handle camera APIs separately (by the way, the state of API affairs often forced you to do this to some extent for any non-trivial use-case; I'd wager it used to be the state of most feature-rich apps in the 2010s).
2. Then you proceed with another component of your app. Rinse and repeat until you've got 90% from B and the remaining stuff is structural.
3. All that remains is to remove Flutter entirely from the equation and rewrite your core app logic: what glues all of the above components together; all of which at that stage are already rewritten for native and tested independently (critical to your success).
Along the way you never truly break UX, it's more of a classic "ongoing development" thing with details changing here and there, and hopefully better UX each step since your move to native must be motivated by something worth it for the client-side (otherwise it's likely your server API model that needs refactoring).
That's how the now-default-consensual approach to how you change stacks without breaking UX, nor your company. Full rewrites on wholly new tech is just asking for cataclysm: you literally do that to yourself, to your own code and users. It's also the only reasonable way I know for small teams, one-man shows, etc.
Just out of interest, are there any clear examples where this happened, ever? Can anyone name any?
What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?
The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future.
SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.
Then there are several kinds of workflows that are quite doable as mobile Web. One just has to take into consideration that 3G isn't broadband, nor a mobile display a last generation 25" screen.