This is precisely the experience of my startup trying to rely on flutter. It's a constant battle. Moreover Android and iOS are different implementation with different capability with constantly evolving API. It's hard to keep cross platform code in sync many #ifdef with edge cases.
Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform is not as tedious.
I've been building a Flutter app and it has been fantastic. I'm using one shared library flutter_barcode and while it isn't perfect, but it shows how easy it is to create native solutions for both platforms and marry them within Dart/Flutter itself.
I can't see how duplicating code in Swift/Kotlin would be any better than just writing it once in Dart. Dart is also quite a nice language to work in. Easy to get up to speed and a nice mix of static/dynamic typing. The optional Provider api make state management a breeze, no more Stateful widgets.
I've also switched from REST to GraphQL. I was a long time hold out there, but now I really see the advantages.
Anyway, just throwing this out there as another data point.
I thought exactly like you and was my view, until I tried to make a small app in Flutter. My startup was trying to build something like Google Lens with AR, and no way to do it in flutter without native code easily.
I like dart lang and done some small apps in it. It's Javaesque with similar style and learning curve. But still prefer Swift which is closer to python (we use python for back-end development) and Kotlin which has some nice functional programming primitives.
Also UX and guidelines are not uniform across mobile platforms. Android and iOS works in their own way to integrate different input like voice, visual and keyboard. Also mobile platforms on Android and iPhone are constantly evolving with new sensors, capabilities. Keeping native SDK itself is a gigantic task not sure how to manage cross platform SDK's. I am sure cross platform SDK can work for some use cases, but I feel it will still be way behind native SDK.
If back-end can take care of all the business logic and front-end manages UI and states with small necessary local data for offline, the efforts spend to develop cross platform app using flutter or natively in Swift and Kotlin won't be very different.
I still prefer REST over GraphQL because I like predictable performance in query and standard interface. Zen of Python PEP-20, explicit is better than implicit.
GraphQL is a solution to a problem of trying to manage business logic on client side so that it can manage ad-hoc query and get ad-hoc results from back-end. It was designed for a problem faced by Facebook. I have seen enough GraphQL code and still stay with REST Architecture, sometimes use protocol buffers for performance intensive parts.
Could you explain what you think of the pros and cons of flutter VS IONIC?
I think flutter and it's astonishing number of issues on github + their lack of manpower + their lack of major features + the presence of major performance and behavior bugs + the extremely small lib ecosystem (dart) is a major, useless risk for a startup for the benefit of tech hype.
(just my point of view, don't take it personally)
Ionic lets me build a web app and publish it to any device pretty easily. I don't have to use their components either... in fact after using Ionic, you may not use Ionic anymore at all. All you need is Capacitor to publish it.
Flutter is it's own rendering engine, non-standard web language (Dart), and ecosystem. Ionic is just a CLI and collection of web components. Capacitor is Ionic's version of Cordova. It gives you access to device capabilities such as storage, camera, etc with very little code. So you can build a website, ask if it's Native on a device, and do more cool things if it is. Then push it to Android, iOS, and the Web.
Ionic supports Angular, React (now in RC0), and Vue (Beta). This allows you to learn popular frameworks while still developing with one code base.
Lastly, Ionic's Web Components are built using standard-compliant Web Components generated by a tool they made called StencilJS. So, now you can build a component in Stencil and publish it for simply the Web (No framework) or have them work with Angular, Vue or React. Larger corporations have started using StencilJS to manage their components when they use many frameworks. I use it because I don't know which framework I'll use next, or if I'll even use one.
Cordova is time tested and has a large community behind it. I choose Capacitor if it's available and then go to Cordova if it's not. Ionic has a collection of easy to use Cordova plugins (https://ionicframework.com/docs/native/overview). I have honestly found they they are not that well maintained. I ran into enough issues that I avoid them if I can. To be fair, the contributors are people contributing on their own free time with no financial incentive. Hence, I choose Capacitor when I can. They have a financial incentive (Ionic is open about this https://ionicframework.com/blog/ionic-2019-business-update/)
I joined when Capacitor was in beta and figured I'd use the up and coming. From research, it appeared there was a good reason Ionic created their own product. They didn't do it to simply stop using a tried and true product.
Also to be clear, Cordova is not an Ionic product. It was a great community thing for a while to talk to native devices.
I haven't tried Ionic myself, but I have tried both React Native and Flutter for a small project and found Flutter to be more enjoyable and productive.
I build a small ionic app when it was based on angularjs with dependency on Cordova and later moved to webview. I didn't like the experience and personally I still prefer Python syntax over Javascript, so that was another factor. Now I think IONIC has moved to web components using stencil.js as the base. Web Components is still an evolving standard and will still take time to gain traction, moreover the available documentation and help is limited.
So if you compare ionic vs flutter I will still go with flutter given it generate binary app store package file by compiling dart code into native platform code. But given choice between native vs flutter I think except few use cases native still makes more sense.
I get the API differences on these platforms but at least in terms of the UI Flutter seems like a good choice. I'd imagine it'd still be easier to stick to Flutter than write two separate native apps in most cases, it seems to have gotten tooling right.
So I'm also interested in hearing more elaboration on how Flutter has been a struggle for you.
That's my point, subtle difference in UX like gesture, swipe and touch controls in iOS results in additional UI code in dart to account for each platform. Not much help except for simple mobile apps doing simple crud operations.
If I use swift I get all the code examples and tons of documentation from Apple itself. In flutter I need to rely on some package which might not be supported, if my team takes over it's double the job fix the package bugs and also change the resulting changed in code, compile and test individually on iOS and Android.
Moreover with REST API architecture majority of the common code is in back-end. So building in Swift and kotlin for respective platform is not as tedious.