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.
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.
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.)
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.
For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers.
At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.
I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar.
It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix.
Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.
Flutter is a breath of fresh air after building and maintaining the same app over and over again for several platforms.
Are you talking about Dart?
If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is.
It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm?
What's the point of dealing with a half baked ecosystem when there are much better languages available?
I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.
I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency).
Problems we had:
* Deploying to devices was painfully slow compared to native stack.
* We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio.
* Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment.
When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure.
Did it get any better?
There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/