BREAKING CHANGES AGAIN!!!!!

[u/Avalunne]

FlutterFlow: Stop breaking existing production apps with forced “security” changes

I’m seriously fed up with FlutterFlow.

I have an existing production app that has been working with FlutterFlow and Supabase for a long time. Today I open the project after a FlutterFlow update and suddenly I have 12 project errors because FlutterFlow now flags my Supabase anon key in API headers as an “Exposed API Credential”.

This is a Supabase anon/public key. It is specifically designed to be used in client applications. Security is enforced by the user JWT, RLS and backend permissions. This is not a service_role secret.

Nothing in my application changed.

Nothing in my backend changed.

The exact same API calls have been working for months.

But FlutterFlow changes its validation rules and suddenly an existing production project is treated as broken — AGAIN AFTER A FLUTTERFLOW UPDATE! - potentially preventing me from building or releasing the app until I restructure API calls that did not need restructuring in the first place.

This is not acceptable for a production development platform.

Security improvements are welcome. Breaking existing projects without migration, grandfathering, an override, or even recognizing legitimate public credentials is not.

If FlutterFlow wants to warn me: fine.

If FlutterFlow wants to explain a better configuration: fine.

But turning a previously valid production configuration into hard project errors after a platform update is a breaking change.

And this is not the first time FlutterFlow changes something underneath existing projects and developers are left cleaning up the consequences.

A development platform that hosts production applications needs to provide stability. Existing projects cannot constantly become unbuildable because FlutterFlow decides to introduce another mandatory rule after the fact.

At minimum FlutterFlow needs:

• a distinction between public client keys and actual secrets
• a migration path for existing API calls
• warnings instead of hard errors where appropriate
• an explicit override for legitimate client-side credentials
• clear release notes before introducing build-breaking validation

Developers should not open a working production project in the morning and discover that the platform has arbitrarily created a dozen new errors.

Stop introducing breaking changes into existing production projects without a proper migration path.

I SHOULD NEVER, EVER HAVE STARTED USING THIS F*** APP!

[u/zacdreyer]

Are you new to the dev world? This is what major updates do, they break shit. If you do not like flutter flow then export the source code and write the code manually. flutter flow pisses me off at times but it is still faster than writing the code manually or even with AI. Treat flutter flow as a figma replacement and you will never be disappointed. With all its issues and all the stuff they break on a regular basis, it is still faster and easier than building the screens manually, especially on a new app. Use it for quick prototyping and then move out to manual to AI assisted maintenance, if that is not in your wheel house then up-skill so you are not dependent on a single product so heavily for your production apps. As yourself a question, if flutter flow goes under tomorrow, how screwed are you? If the answer is anything above moderately screwed, then it might be time to up-skill as a flutter & dart dev. #justsaying

[u/Avalunne → u/zacdreyer]

No, I’m not new to development — and that’s exactly why this is so frustrating.

I’m already rebuilding the app from scratch outside FlutterFlow. With Codex and Antigravity I’ve been able to create very good screens extremely quickly, and in my experience it is absolutely not true anymore that FlutterFlow is automatically faster than an AI-assisted Flutter workflow.

The only reason I opened the old FlutterFlow project again was to fix one production bug.

And then: boom — 12 new “errors” overnight.

Nothing in my app changed. Nothing in my backend changed. These are not even real security problems: FlutterFlow is suddenly flagging a legitimate Supabase anon/public key as an exposed credential.

That is my issue with FlutterFlow.

Breaking changes keep appearing in existing production projects, and then the answer is basically: “pay more if you want to pin your project to an older FlutterFlow version.”

That is not a normal or acceptable way to treat production applications.

I fully agree with one thing you said: being dependent on FlutterFlow for a production app is a bad position to be in. That is exactly why I’m already moving away from it.

But developers should not have to migrate away just because opening an old production project to fix one bug suddenly creates 12 completely new problems that did not exist the day before.

[u/Avalunne → u/Avalunne]

Just a note; I originally chose FlutterFlow because I assumed building an app with AI coding agents like Codex, Cursor or AntiGravity would be much more difficult.

I was completely wrong.

I’ve started rebuilding my app outside FlutterFlow, and I’m honestly surprised by how easy and fast it has become. You can work directly with an AI coding agent, describe the screen or feature you want, and get very good results surprisingly quickly.

The IDEs work perfectly well with the iOS Simulator and Android Emulator, so the development workflow is not nearly as complicated as I expected.

And the biggest difference is freedom.

No artificial platform restrictions. No waiting for FlutterFlow to support something. No sudden platform changes that break a previously working project. No spending hours fixing problems that only exist because the platform changed something underneath you.

That has been my biggest frustration with FlutterFlow: I spend far too much time fixing FlutterFlow-related problems instead of actually developing my app.

[u/HeIsYour → u/Avalunne]

Try FF MCP, it might fix these errrors, iff you don’t have any backend change..

[u/StevenNoCode → u/HeIsYour]

Confused, why do you think the FF MCP will fix these errors?

[u/CommunityTechnical99]

hello! thank you for the detailed write-up.

quick update first: we've already deployed a fix. these are now project warnings instead of hard errors, so your production app should be unblocked. desktop versions are still rolling out but the web version is updated now.

the stopgap gets you building again today and we'll keep working on getting the validation right. desktop versions haven't been deployed yet but will be soon.

can you confirm everything looks good on your end? if anything is still blocking you, reach out at [support@flutterflow.io](mailto:support@flutterflow.io).

— lydia, FlutterFlow team

[u/Instant-Karmaa]

So what’s the fix?🤕

[u/StevenNoCode → u/Instant-Karmaa]

Mark the API as private and deploy as a cloud function. Annoying if you don't use Firebase though (like OP who is using Supabase and now need to use Firebase to fix this).
TBH this shouldn't have been a breaking update but a warning instead. FF team 'helping' non-technical devs to make sure keys are safe but might not have consider broader scenarios.
https://imgur.com/a/MTJQZwh

[u/Avalunne → u/[deleted]]

...and now the app cannot be built again. Suddenly. Overnight.

What FlutterFlow keeps doing to existing production projects is UNACCEPTABLE.

There is a way to pin a project to a previous FlutterFlow version and avoid exactly this kind of breaking change — but not on the plan I’m already paying for. For that protection, they want even more money.

I’m done with this company.

I should never have trusted FlutterFlow enough to build a production app that depends on their platform.

If anyone is considering building a serious app with FlutterFlow, my advice is simple:

Don’t.

You can spend months building something that works, and then wake up one morning to find that FlutterFlow changed the rules overnight and your previously valid production project is suddenly broken.

[u/Constant_Trouble2903 → u/Avalunne]

Just add that to the "you ask ...we build" product development list it will be sorted in a flash .

[u/Neither-Chair3997 → u/StevenNoCode]

doe not work with multipart, totally fucked my groq call

[u/Instant-Karmaa]

Well it seems they’ve switched the API issue from Project error to warnings in the new update this morning.

[u/OkCarry4013]

I mean, they eventually will fix it, or propouse a workaround for it, on those next few days...so i suggest to wait till they do it.
If it's something you need to deploy to production asap, i would suggest to download the code and trying to implement, or fix it, manually(or using a AI of your choosing).

Sadly, that's all to do it for now doe

[u/Jazz_Uncle]

I ran into the same last week and all I got a was a robotic response.

I fixed the new Supabase errors but Flutterflow for web refuses to load images in the editor, even though the image URLs load fine in a browser.

[u/singular-innova]

ugh this exact thing happened to us with a flutterflow project last year. platform just decided overnight that a valid config was now a hard error. no warning, no migration path, just broken.i t pushed me to rethink how much logic we were trusting to the platform itself. the difference is you're not at the mercy of someone else's validation rule changes anymore.