As an iOS engineer with native and flutter experience, not needing access to hardware and OS specific APIs is a BIG assumption, I used to not need access until I needed them and it was somewhat painful most of the time, either support was not there how we needed it or some APIs were awkward to use.

I'd also say that the write once support on all devices is definitely not a 100% thing. There is definitely a lot of tweaking for adding support to specific platforms and devices (think iPad vs iPhone vs Android Phone vs Android Tablet). I've also found it that its a lot easier (when compared to native development) to create code that needs to be heavily refactored out when adding support for additional devices while also making sure to not braking things on other platforms. This last point complicates development because then you are forced to be familiar on how to test and debug on each platform, making sure that changes or issues fixed on a specific one don't break the other ones; this for sure adds a ton of development and testing time, specially when you go beyond just android phones and iPhones.

Where flutter has shined for us though has been for internal tools that we deploy and for which the UI is not designer-driven or that don't have stringent design and performance requirements.

Now don't get me wrong; I'm well invested in flutter but it does not come without its compromises, specially on iOS being second in line support after Android. It definitely gets you quicker to market with an MVP on more platforms compared to pure native development.

The idea is that over time as the ecosystem matures, you will need less and less need for platform channels because there will be more plugins available on pub.dev. Personally I think the Flutter team is taking too much on their plate porting it to Linux/Mac/Windows/Web at the same time. I would rather see them make the iOS and Android implementations rock solid and create great plugins for hardware & OS specific APIs.

FWIW, my buddy and I built and launched a simple iOS app (Export Health!) in the App Store in two weeks using SwiftUI. The whole app is basically one file and under 1MB including all the iOS extras. Both of us are professional engineers but only had minor exposure to iOS before building this app.

A few years back I built internal apps at work using React Native. Warts aside, it was a great dev experience and was able to re-use code 100%. However, having to ensure all was well with both iOS and Android (and indeed sometimes there were edge cases) slowed me down.

SwiftUI and the Combine framework provides a similar dev experience I felt using React Native. Moreover, app previews in XCode make it straightforward to paint different application states and iOS settings. Building for one platform also reduces the quality check surface, allowing you to spend more time focusing on product.

If cross platform is a necessity from the onset (e.g. internal app for work where all employees need access but may have different phones) then starting with non-native makes sense. However I personally recommend anyone looking to build a product as an app to focus on iOS first and use SwiftUI. I reckon you will move faster, have a smaller code base, and a better app. All of which are conducive to finding PMF if you intend to make a business out of your product

Upvoting you because the downvoting was unfair.

Nevertheless I think your position is naive; most interesting and engaging apps need more information than you can get from a generic tool alone.

It feels like SwiftUI, and other native tools, are embracing the advantages of some of these other cross platform tools: declarative, rapidly-iterable, abstracted.

I feel SwiftUI markedly lowers the 'barrier to entry'.

Crossplatform tools may serve your purpose better, but I think it's unfair to say that, at least for SwiftUI, native development may not be as 'joyful'. A list view in SwiftUi is List {}.

I agree - native development is bad. I had an iPhone app that I built using native Apple stuff and it was miserable. And the whole time you're struggling with their buggy UI framework you can't even take solace in that you're learning useful skills because it's all specific to Apple development. From the programming language to the frameworks/APIs you use.

It's so domain specific that IMO it's not worth trying to do that kind of work unless it's your main career. I ended up taking the app I had built down because I kept getting support requests for bugs I didn't know how to fix and the idea of going into the code to add more features filled me with a sense of dread. The app was doing somewhat well too, it had about 1000 DAU.

I built another app for the CDC in React Native, which has its own foibles but is overall much easier. I'm not sure how successful Flutter will be overall because you can't leverage outside skills and you have to learn a different language.

Have you used Flutter web? It performs extremely poorly and is completely inaccessible.