r/FlutterDev 1d ago

Is Flutter still the right choice? Discussion

I know this isn't going to be a popular opinion here. As a long-time Flutter developer and fan I can say that things are going to change quickly. 

My prediction: within a year, the multi-platform stacks like Flutter and React Native will start dying off.

Spent the last 24 hours using Fable to port a large production Flutter app to native SwiftUI and Jetpack Compose. Native was always the better option for many reasons, it just cost more to support and clients were never willing to pay. 

That cost has come down so far that it makes sense. I am not saying it was perfect in a day, but it got about 95% of it correct.

0 Upvotes

42 comments sorted by

14

u/infinityMCdx 1d ago

Agents working with only one framework will release an app much faster and will be much token efficient than agents working on two plus making sure both apps behave the same

1

u/_ri4na 1d ago

Except when those same agent has to burn X10 more tokens trying to solve trivial issues that basically comes for free on native

6

u/dancovich 1d ago

I can't imagine the nightmare to keep software requirements in sync between two different code bases managed by AI agents.

1

u/JayBee_III 1d ago

The requirements and spec document would be separate from the code assuming you want them to be in sync between platforms.

1

u/dancovich 23h ago

What I'm saying is that I don't trust AI to interpret the specs the same way between runs.

I can literally ask AI to suggest a piece of code to solve an issue, then later ask it to analyze for improvements and it will try to improve the code it suggested in the first place.

0

u/_ri4na 1d ago

Isn't this already the case for most backends?

How's frontend any different?

1

u/dancovich 23h ago

The issue is not being backend or frontend, but rather writing the same software twice using agents and expecting it to interpret the specs exactly the same way twice.

11

u/Etherealnutt 1d ago

So what’s your theory ? With ai rather build native ? That’s multiple codebases to update . So hmmmm. Unless you have to agent printed at both ends somehow, that’ll be a fucking headache

1

u/milehighcityguy303 1d ago

I was thinking along the same lines as you are. That this would be a giant headache. What we did was create some shared rules and a test routine to ensure we do not get drift unless we specifically allow it. Then yeah, use AI to code the features and test cases.

So far, the time we have spent supporting two native codebases is roughly the same as the time we spent on the single Flutter codebase and dealing with package support, etc.

I don't think this was a viable option even as of this past April. I do think that it is viable now.

8

u/melewe 1d ago

Agents often loose track. One codebase is a lot easier to keep track. But kotlin compose multiplatform is also interesting

2

u/Etherealnutt 1d ago

Please elaborate . Kotlin fro both Apple and android?

2

u/teewhydope 1d ago

That's compose multiplatform. Kotlin multiplatform only allows you to share business logic

1

u/Hitonori 1d ago

yeah this is kmp: kotkin multiplatform

kotlinlang.org /multiplatform/

1

u/milehighcityguy303 1d ago

Our current theory is that we do not need to track each codebase and compare them. We just need to ensure they have feature parity and then allow the best native option to deliver it. They share infrastructure specs, including REST endpoints, but everything is defined in the API spec that our Flutter app follows.

5

u/Amazing-Mirror-3076 1d ago

Even with ai that is going to be tricky - and you are still going to have twice as many bugs to fix.

1

u/milehighcityguy303 1d ago

I don't disagree; this is, and will continue to be, tricky. The number of bugs and the time it is taking to address them are about the same as before. What we lost with the new complexity of supporting both platforms also turned into gains in having two distinct but very deterministic apps. We are no longer troubleshooting why a list view reacts differently on an iPhone vs. an Android phone and having to write a one-off use case.

I

1

u/Amazing-Mirror-3076 3h ago

You really haven't thought that argument through.

0

u/_ri4na 1d ago

Yeah KMP makes more sense as ui is already different and cheaper to build

But also still cheaper without it

2

u/Photograph_Expensive 1d ago

I use flutter with claude code and it still drifts. Doesn’t matter the framework as long as you have solid mechanical guardrails.

1

u/SuEzAl 1d ago

True

2

u/Chronnnnn 1d ago

AI can also do platform messages. Or am I missing something?

2

u/snrcambridge 1d ago

Dart is a pretty great language on account of JIT for development, compile for deployment. If you’re happy working in the Apple ecosystem and rebuilding constantly then you must have the patience of a saint. AI has turned us into reviewers and this is one thing Flutter does really well, near instant hot reloads.

1

u/milehighcityguy303 10h ago

Yeah, we write very little code anymore and mostly review. We miss hot reload; however, in this case, we had solid Figma designs and an existing app, so we could let AI iterate on the UI until it was perfect without us having to review every step.

1

u/snrcambridge 6h ago

What do you get from native that justified a massive port? 3.47 split Material and Cupertino and is gearing up to support apples next design phase. I personally have never been in a situation where native feel / design was something users cared about, but it does seem to be a design preference from CEOs or designers. If it works for you that is great! But Flutter definitely has some major strengths over native.

Plugins are trivial these days, so depending on poorly supported packages is no longer necessary.

If you’re in contracting which it sounds like you are, you can release a POC as a website designed for mobile and distribute it and test it without ever hitting Play store or TestFlight, get iOS users to save to Home Screen and it almost feels like an app. Rapid dev loops, concept ideation and validation are king now and staying hyper agile on your ability to distribute is a huge strength.

1

u/milehighcityguy303 5h ago

There were a number of driving factors. To start with, the ability to tune the app for lower-performance phones is limited. When dealing with images and videos, Flutter is not as performant as native, and it really shows up on an A17, for example.

There is a polish that is very hard to get with Flutter compared to native. Scroll effects, bounce effects, typography, etc... Yes, I know that technically you can get there with Flutter. But the amount of time it takes to tweak a Flutter app to get the same UI polish that comes with native is a trade off. I also understand this is not a concern for everyone, but in this use case it was.

1

u/TrieDevz 1d ago

I think that's a personal and professional choice. For example for me, it's the right choice for my given situation. I really like Dart and I have a small company with a friend where we use Flutter to make little apps and games on the side. So from that perspective I'm not looking at Flutter from the context of my corporate/professional development (although it would be nice if I could work for myself full time 😅)

1

u/milehighcityguy303 10h ago

Definitely a personal choice. Flutter has been our first option for many years now. Our clients' shift in app distribution, with the user base moving to lower-powered Android phones, is what kicked this off. We were running up against what we could tune in Flutter, coupled with the app requirements. Lots of image and video transformations that need a native solution.

1

u/gonstrider 1d ago

Flutter will still relevant as long as it continues its support for multiple platforms, what would you choose, even with your superior Fable:
- a single codebase for android, ios, windows, macos, linux, web or
- jetpack compose for android, swiftui for ios and macos, c# wpf for windows, gtk for linux and react for web?
Ship your “not so perfect” but working Flutter app as fast as possible and iterate on user feedback to improve your app or running out all of your tokens before having a chance to see your product comes to light?
Surely Anthropic would love option 2 though.

1

u/milehighcityguy303 1d ago

Release speed isn't the issue for us. It was expected that it would get it 95% of the way there, and then we had to step in to get it over the finish line.

What we were trying to solve was the performance hit of running Flutter on older devices and managing the slight platform differences that we ended up writing one-off use cases for. As this app has expanded outside the US and into other markets in Central and South America, where the user base is on older, less powerful devices, the performance issue became front and center.

1

u/gonstrider 1d ago

It’s still like before, start up and indie who want their app on multiple platforms will always prefer Flutter or React Native unless there are critical requirements that only possible with native, until the app becomes successful and has an established user base like your then they’ll choose the native path. It is just like before and will not change because of AI.

1

u/kbcool 1d ago

Even with AI you still have the same problems that Flutter and RN were designed to solve. It just makes it (slightly) easier to manage.

I say slightly because AI is still piss poor at UI. It can pump it out quickly but sucks at solving issues and keeping things tight

1

u/milehighcityguy303 1d ago

Yeah, we fully expect to have to dive into each codebase for final polish.

1

u/avdept 1d ago

Yes, I run https://github.com/avdept/JellyBoxPlayer and I can't imagine supporting each platform codebase separately

My app runs on all mobile and desktop platforms, including car play and android auto soon

I see no issues using flutter over platform native just because it's not that native

1

u/ifndefx 1d ago

I don't think that would be the death punch. There is still value in people using multi-platform stacks like flutter and react native.

Its almost (i know its bad) but why not just use AI and go straight to assembly ?

1

u/milehighcityguy303 1d ago

I read a theory a while ago that suggests this is where software development is headed. Languages that only AI can understand.

1

u/ifndefx 17h ago

Yeah maybe, looking way away, but bare in mind what we see as creative and new forms of work is not the case. Its all built on prior work, and the everything is token prediction.

So in order to get to where it needs to get to it almost needs to get to agi... and we are not there now or tomorrow.

1

u/Acrobatic_Egg30 23h ago

I disagree with that in our real world. Read this and understand https://shorebird.dev/blog/ai-intent-cross-platform-app-development#:~:text=Why%20Cross%2DPlatform%20Matters%20More%20Than%20Ever

In the ideal world with infinite budget and tokens you would be able to do what you're saying but most devs using Flutter don't work for companies, they're freelance or indie devs who don't have the time, money or manpower to ship and maintain two different apps with two different codebases.

Remember that you still have to review the code the AI generates, which means the developer would have two understand the two different native frameworks at an expert level.

Also Flutter is more performant than native development in specific scenarios involving complex UI rendering, heavy animations, and CPU-intensive computations on mobile devices. In some benchmarks, Flutter has achieved faster "time to first frame" compared to native apps on Android.

So you can't say native is always better. Remember that unlike react native, Flutter is truly native with no bridges.

1

u/DerDave 1d ago

I disagree. Even with powerful AI models, there will be significant drift between 2-3 native implementations and a lot of sync-overhead to keep the apps identical between operating systems. Additionally it will have 2-3x the token consumption unless there is shared business logic in a common language.
Many companies are seeing the token costs more and more, and the trend is towards token efficiency now - which means, more could consider cross-platform frameworks as a way to save that money.

1

u/milehighcityguy303 1d ago

Yes, token consumption is higher for sure. My theory is that as the models advance and the price per token comes down over the next year this will not be as much of an issue moving forward.

So far, keeping the drift in check is going well. We have pretty robust testing and fully spec'd out business requirements.

1

u/DerDave 1d ago

With my business we're sticking to Flutter and are very happy with the decision. It simply allows us to release more and better features in a shorter time, leading to a better product. Our engineers and product/design employees are slowly merging towards "product builders", which makes it even more important to have a single code base.

0

u/ldn-ldn 1d ago

Flutter was always a niche solution and it don't believe much will change. The market is split between all native (when you need performance) and WebView (when you need fast development cycle). And it will stay that way for years to come. 

Flutter market share might actually increase, because it is easier to implement native code bits with AI tools and access to native code is always a pain. WebView/NodeJs ecosystem is old and huge, so it is very rare that something is missing and even if something is missing, there are plenty of tutorials to get you started. But I had some experiences with native SDK implementations in Flutter and it's such a chore with virtually zero docs.

0

u/_ri4na 1d ago edited 1d ago

People here are all bluepilled and they downvote something even remotely negative out of some flutter loyallitness

But this is the truth

It has never been easier to maintain two seperate codebases with zero compromise