Flutter: if you want a pixel perfect version of your app that looks similar on Android and iOS. Some quite popular apps use it and make a shit ton of money, for example Headspace. More here: https://flutterhunt.com/
React Native: totally viable, because core business logic is the same. If you want native UI elements and all the iOS Liquid Glass stuff, but don’t want to have to completely separate code based, React Native is a viable option if you don’t mind installing lots of third party packages for functionality you get out of the box in Flutter or true native apps.
Native mobile: I have one smaller app with quite a custom calendar view, written with Claude Code natively for Android and iOS. Coding agents help and you get maximum control. Mentally, it’s a bit cumbersome to direct you agent to do everything twice. While one platform can serve as a reference implementation for the other, it’s kinda annoying mentally "to do the same feature all over again and test and direct the agent". But it’s doable.
KMP: No experience, I just hate most things around Android.
PWA: That ship has sailed. Nobody knows about PWAs, most PWAs are bad. It’s a bummer really.
Capacitor: make an SPA (offline-first preferably), and use native code plugins via Capacitor. Still quite feasible, comparable to Flutter in the sense that you need to build a custom UI or use a fake version of Liquid Glass and Material. I use Ionic for that, but it’s a bit dated (still on Material v2). Heavily depends on your skills as a web dev to get good UX.
Native was always the best. It was just time consuming, requiring a bigger team. Now with AI helping out, it's probably the best option by far. I still like Flutter a lot though because you can get stuff done fairly quickly and even apply Material design to the iOS apps or vice versa if you want to (if it's a business app where the design doesn't matter too much). Or if you e.g. target win32
Even with AI, maintaining feature parity between Android, iOS, Windows, Linux, and Mac is extremely complex. Flutter makes it so much easier. If I were doing native, I'd probably have to drop all desktop platforms.
In most cases yes but if you don’t want native elements and you want your app to look exactly the same on android as on iOS then flutter is a better choice. Assuming you don’t have any performance limitiations.
I use Ableton, Figma, and Emacs regularly. I have a decade (or more) of muscle memory around these apps. If they suddenly decided to adopt the look, feel, and conventions of their underlying host platform, I’d be very upset.
If I’m using Emacs, I don’t want to use Cmd+S to save my files on macOS and Ctrl+S on Windows. I’ve already memorized C-x C-s. I don’t want Ableton to adopt whatever new design language Apple or Microsoft is chasing this week. I want to open the app and find the UI controls looking and behaving exactly the same as they’ve looked and behaved since I started using it in 2014. I want to write code, make music, do design. I don’t want to be frustrated because the button for enabling the metronome is 15px to the left on Windows vs. macOS.
Apps that look and feel native only make sense in two cases:
1. The app is tied to the platform. E.g. Logic Pro. It can integrate deeply into macOS and use the native widget set because it will never run on any other platform. Same for Bear, Things, Pixelmator, Omni Group apps, etc.
2. The app is a replaceable, throw-away utility. I call these “fungible apps”. For example, it doesn’t really matter which Mastodon or Bluesky client you use. There are hundreds of them, and they’re not complex enough that the loss of familiarity or muscle memory matters very much. You can use one client on Windows, a different one on macOS, and a third one on Linux, and it’ll be fine. They can all be native to their platforms, or not. The interaction model is simple enough that you can afford to have a different one on every platform.
For apps that really matter—the apps I use to put food on the table—I absolutely want them to look and feel exactly the same on every platform. The app is the OS, the actual OS is just a hardware abstraction layer.
Can Flutter be used to build apps like Figma or Ableton or Emacs? I actually don’t think so. It’s a poor toolkit for building anything that must last for more than 3-5 years. If you care about longevity, there are basically only three options in 2026: Qt, Electron, or roll your own like Zed/Sublime.
(Adding this as a comment because I'm over my edit window.)
I want to add a third category to the categories that make sense as native apps: apps that are built by the platform vendor (and potentially shipped with the platform).
GNOME apps are built with GTK+, KDE apps are built with Qt, and macOS apps are built with SwiftUI/AppKit. This is how it should be. Microsoft is the only outlier here, shipping apps built with everything from Win32 to React Native to Electron to their own WebView2.
Regarding Microsoft - that's a sad story indeed. The only reason they don't use Win32/GDI+ etc is because it's harder and you ideally want to do that in C++ to get the true powers available to you.
I've recently had to do some win32 stuff in a Flutter app and it's amazing what you can do, but it's pretty hard, even with an AI to help you.
So the "lazy" devs go to work using React Native and Electron rather for apps inside of Windows shipped by Microsoft. Crazy, but it's to meet deadlines.
For end user apps, I want them to look according to the OS, at least on Apple devices. That's what picky customers. For stuff where design does not matter much, such as enterprise apps that "put food on the table", as you say, I use Flutter and still get a very decent result.
But with sufficient time and effort, proper native iOS/macOS wins every time.
I don't think you'd want to in most cases, but adapting to different platforms takes energy and thought. For business CRUD apps you may just want to ignore that and get something out that works well.
I see Tata Neu and BigBasket there. That I guess flutterhunt team put there as a joke (and not as a showcase), didn't they? At least in terms of quality? Because god I've used these apps!
Further:
> I just hate most things around Android.
and yet you say
> React Native: totally viable
It's just strange someone "hating things about Android" and then is "totally viable" about things react native. This must be some "personal" sort of hatred. I am saying this as someone who has always struggled and cursed the toolings around Android and then started appreciating it once I had to deal with "xcode world" and things "web dev". React native? That was another level of nightmare relatively speaking from development perspective.
I've built apps with millions of users using flutter. Quicker, faster and easier for building cross-platform apps if you know what you are doing.
This is coming from a native framework evangelist for many years, and then just tried flutter early days (which was far more difficult than how easy it is today). Now I write almost all my projects in flutter/dart where I can, especially with AI the speed from idea to production is insane.
Flutter is quite good for shipping quickly and a set of decent same/similar apps. You lose some "quality" and a lot of "native performance" and feel (yes, that's important distinction here. So the usage, if still it will be used, will be limited to that I believe.
KMP I guess missed the ship and that ship has sailed quite deep into the ocean now. PWA won't be a choice anymore except for the "niche" usage.
React Native? I guess there will be use cases for this (at least for a while) as it is deeply entrenched into too many apps and many of those are very famous apps. Besides there's always been automasochism for the reason to pick react native.. so that's there :D
I will also expect native to pickup now (unless we only see single person tech teams now) because of AI. I mean as LLMs started getting better at coding my first thought as a native dev was - hah, hopefully people won't have to deal with such monstrosities in even small teams now.
Also, not having to see a package.json with a trillion entries (and counting) alone can put all these choices above RN for me.
Every time we tried it, it resulted in a worse experience than we knew could be done using native stacks. It is like using sand as a foundation for your house. Random version updates break random things. As soon as you need something a bit advanced on the platform, you are stuck with some barely supported library. Easy to start, hard to maintain and hard to ship a solid product.
I’ve been a React Native developer for 8 years, I’ve written many apps with it professionally and personally. Until recently, I would have recommended it wholeheartedly.
This weekend I had an idea I set out to experiment with: if I have an existing React Native app, how much effort would it take an LLM to rewrite it into genuinely native apps. My idea being I no longer need to write cross-platform code and pay the intermediary framework costs, I’d get direct access to the underlying platform. Instead, I could just spec the features I need in the app and the LLM can build it.
It took me a year to build the original app to production quality by hand. My “twins”, as they’ve become known, were at 80% completion in three days of on-off work.
I’m pretty much convinced my experiment was a success. Which sorta terrifies me that I’ve specialised in a technology that can be, for all intents and purposes, be entirely erased.
The only caveat I can find is it is still a great technology for doing cross-platform mobile and web. Using something like Tamagui (as rough as that can be sometimes) allows genuine code sharing across all platforms.
Sucks most that I’m now actively looking for a new React Native role.
I really believe this is the way forward, native platform UI built by AI.
I'm trying it now with an app and so far it's working really well. I build what I can cross platform, the non-ui stuff, then have AI build the UI for each platform.
It even implemented native low-level graphics on each platform: metal, vulkan, and d3d12. It builds SwiftUI on Apple platforms, WinUI3 on Windows, GTK4 on Linux, Compose on Android. The cross platform stuff is Zig with a C ABI.
And yeah, it's a bit terrifying how fast you can iterate. I've built for all these platforms in about a month. It would have taken at least a year, maybe more before. I haven't even optimized the process by having AI agents follow my lead automatically, so as I finish features on the primary platform they could start building the others by watching. Requires some setup I haven't tackled yet (VMs for all platforms with agents waiting).
Be careful, I’ve been using AI to translate my Swift code to Kotlin and sometimes it makes some mistakes that are invisible to you, because the languages are so similar, but it will bite you in the ass eventually, because there are subtle changes between the platforms
I am sure you are right but if you tell the LLM to be careful with those it should easily avoid those mistakes. But yeah first you need to know what to look for.
Not saying that LLM development isn't fast, but doing a re-implementation of something you know in-and-out is almost always going to be faster, as you skip the probably most time intensive step of product research and requirement engineering.
Absolutely, but that doesn’t discount that it’s now feasible to spec a feature once and have it built for me on both apps. I’m doing the same process on a new project I’m working on and it’s built both apps simultaneously as I’d hoped.
I get the impression that more are going for native mobile, KMP or PWA.