> its nearly better to write your business UI 3 times one for each platform.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?
You don’t do that though. You write your logic in a common languages and then the UI is an external layer you switch with build settings. The thing is, yiur choice is usually c|c++. Or an embedded language like lua. RN has gone the latter route and then extend it further by using React as a DSL for the UI.
> You write your logic in a common languages and then the UI is an external layer
Isn't reimplementing all your UI widgets, views, layouts and interactions for multiple platforms still a ton of work though? I'm not meaning people using things like React frameworks, but the suggestion of sticking to native only.
If you do that, then you intent to take advantage of the native framework (or a mature one like qt for some platform). They are really expansive and you can create an interface very quickly. You usually get animations, themability, navigation,… for free and you’re mostly arranging the layout and writing glue code.
Also, you usually get better tooling in regards to instrumentation and the like.
I can share a bit on this one.
I’m doing hybrid apps for the last 8 years and stick to Cordova on my day job but also tried Flutter and RN for a bit.
As I’ve seen some other comments about the iOS/Android look and feel (swiping gestures, etc.), Ionic (or the Cupertino package in Flutter) is the way to go. Without this, it would be a lot of trouble. However, as the recent iOS 26 update has shown, neither Ionic nor Flutter is going to support the new liquid glass design (yet). Since we never went with “our app must exactly match the (apple) design guides” this is not a problem for us but I’m sure others would love to be able to adapt the new liquid glass style.
I also never heard of any app being rejected due to being a hybrid app or not having the correct look and feel. Of course, you might see/feel that it’s not a native app but who cares.
Back in the days we even used a OTA plugin (it was a MS plugin, don’t remember the name) to automatically ship new .js/.html files without going through the review process. If I remember correctly Ionic still provides something like this.
When it comes to native stuff it get’s tricky. As always it really depends on the use case of the app. In our case we develop a navigation app using a native SDK to show a map + turn-by-turn nav + offline maps etc. This is probably the most non ideal use case for a hybrid app. We developed a few plugins to share data between js /native to initialize the map etc. However, the idea of sharing business logic is long gone. There’s so much stuff that’s happening natively and each time we implement it on Android, we have to switch to iOS and implement the Swift version of it.
Some others have also mentioned that a single person now has to know three platforms (iOS, android and Cordova (in our case with ionic + angular). This is true and the real downside. I’m quite familiar with iOS and android yet I’d never call myself a native iOS / Android developer. Yet, I’ve to write so much native code regarding permission handling, geolocation, threading (Ui/non-ui) and there’s always a ton to stuff happening from version to version (e.g. 16 KB Page Size on Android, iOS support for rotation the device/adaptive layout on iPadOS, etc). This is where a lot of time is lost. And the time is not only lost there but also with unmaintained outdated community plugins you suddenly need to understand and fix.
As a corollary, working with RN quite a lot, we just built an app for a client that was end to end finished and fully approved to both apps in a month, including pretty deep feature work and redesigning multiple screens. It includes the latest liquid glass native UI as well.
RN is a mess to get into, but once you've found a good stack you can really fly. We are working on a starter kit based off our experience that I think should represent the best possible starting point once it's released sometime before the EOY.
Anyone have any experience of doing this for a complex and long-life app?
Sounds like a nightmare that would increase friction and decrease development fun by x10 because of the huge overhead and tedium of having to keep your features and tests in sync across platform for every change you want to iterate on, and requiring developers be proficient at multiple stacks.
I get the usual complaints about bad webview implementations, but separate native codebases sounds like a prohibitively enormous tradeoff if most users only perceive the UX as being a little better than a good webview implementation. I feel like I'm missing something that native codebases is suggested as if it's a simple alternative, or this is coming from people that aren't actually involved in this?