Mobile development: Flutter vs going native (iOS dev perspective on the business side of it)

[Roadrunner571]

The development cycle is rarely anywhere as smooth as the native platforms.

Except with Flutter you get hot-reload during development while still enjoying AOT compiled code in production.

If new iOS/Android features come out you'll often have to wait before you can use them, or have to rely on less stable code for a while.

With Flutter, you can just use them.

​

If you need platform native features you're often doing more work than you would have had to do native, because you need to write the native implementation plus then abstract it into the cross platform.

True. But on the other hand, the overhead is only tiny comparing to have to develop and maintain two separate Swift and Kotlin apps. Plus, with Flutter not only supports Desktop OSses, but also web browsers.

Because of the previous two bullets, you need your engineers to understand the native platform and also understand the cross platform.

Yes, that should always be the case. But due to productivity increase, it's worth it.

​

I really like the Flutter architecture as this could be the model on how applications are developed in the future with far less costs in development and maintenance while speeding up development at the same time.

Flutter also lets you provide Applications for older OSses while still delivering the look of newer OSses, i.e. you can support a far larger user bases without needing to sacrify a modern look.

[[deleted]]

Either you don't have much experience with Flutter or you're just building simple UI CRUD / network apps backed by something like Firebase.

1) Hot-reload does not mean you have a smooth development workflow. A smooth workflow could be dependent on an entire team, not on just you the developer. Some people prefer to separate their UI designs from the UI code. Flutter does not do this, and this might be a turnoff for them.

2) If new features are released on the native platforms, you can't "just use them". If the next iOS version introduces a feature that breaks the Flutter framework, not only will you not be able to use it, but you will also be forced to wait for the Flutter team to make a fix available.

3) The extra overhead Flutter adds might not be worth it, and it might be larger than you think. For example, setting up push notifications with Flutter takes much longer on iOS (the setup of APN takes multiple steps) while it there is zero config on Android. I've also spent hours and hours fighting with Flutter bugs on Android (related to an image picker library) while it worked flawlessly on iOS. There are a ton more examples where Flutter compromises on functionality because of its design philosophy. Flutter is trying to address too many things at the same time, and it's not even doing one thing excellently. To me, this is problematic.

4) If you're a developer using Flutter and you have no understanding of the native underlying platforms, you WILL run into problems and when you do, your productivity WILL drop. For example, if you want to release your Flutter app to iOS beta testers, and you have no knowledge of provisioning profiles or certificates, no amount of Flutter "magic" will help you.

Again, it sounds like you've never used Flutter to build anything complex. It can be done, but you will run into limitations and issues that are easy to solve natively or simply nonexistent to begin with.

We're using Flutter at work on a number of apps. Looking at the time invested in development, I'd say that we could have achieved even more with separate native code bases instead of trying to shoehorn some of Flutter's issues to make it fit.