Can we access your project?
Current Behavior
Since this morning, August 26, 2026, typography across my existing project has suddenly reverted to what appears to be FlutterFlow's default Theme Text Style values.
Yesterday, August 25, the project was rendering correctly.
The issue affects the entire application, not one specific page, and occurs with both:
standard Text widgets
RichText / RichTextSpan widgets
For example, on the attached ClearInstructions page, a heading that previously used my customized responsive typography is now displayed as Display Large at 57 px / FontWeight 400, making it much larger and thinner than before.
Other typography properties have also changed. For example, the Continuer button text was previously white and is now grey.
The important exception is that texts where I later manually overrode individual typography values still appear correct. For example, if I manually changed a font size from 22 to 23 or manually changed its font weight, that explicit override remains intact.
The regression appears specifically to affect typography that relies on the existing customized FlutterFlow Theme Text Styles.
This is also not limited to the editor. I can reproduce it in:
FlutterFlow Desktop Editor
FlutterFlow in Chrome
Test Mode
iOS Simulator
I also tested an older snapshot from August 25, 2026 at 22:15, created while the application was still rendering correctly. The snapshot now shows the exact same typography regression.
I compared the current project with that snapshot:
theme.yaml is byte-for-byte identical
the complete widget tree of an affected page (quiz2) is identical
This makes it appear that the stored project itself has not changed, but that FlutterFlow is now interpreting the same typography configuration differently.
Expected Behavior
Existing customized Theme Text Styles should keep the same font sizes, weights, colors and responsive values after a FlutterFlow update.
An unchanged project or historical snapshot should render the same way it did before the update.
Typography configured differently for mobile, tablet and desktop should continue to use those customized responsive values instead of reverting to FlutterFlow defaults.
Steps to Reproduce
Steps to Reproduce
Open project doggeniusv1-ips3f5 in FlutterFlow Desktop 7.0.73 on macOS.
Open an existing page that uses the project's customized Theme Text Styles, for example ClearInstructions.
Use the mobile viewport around 393 × 852.
Inspect the main heading.
Observe that its Display Large style now resolves to approximately 57 px / 400 Normal, which is not how it rendered before August 26.
Inspect other existing theme-based text styles and observe incorrect sizes, weights and/or colors.
Run the project in Test Mode and observe the same typography regression.
Run the project in an iOS Simulator and observe the same regression.
Open the August 25, 2026 22:15 snapshot.
Observe that the historical snapshot now renders with the same incorrect typography, even though its stored theme and widget configuration are unchanged.
Compare this with text where typography was later manually overridden on the individual widget: those explicit manual overrides still render correctly.
This regression affects existing projects/styles, so I have not been able to reproduce it meaningfully from a new blank project.
Reproducible from Blank
Bug Report Code (Required)
IT4slMmA7ZF2obhA0KX2K+5R/SAWOUc1U78oscp/awggfbLLBIYuP/WkVFVuUsfjdHNIPESmmkI0pdrMhvPtOMYDHxSWG7Z4zaVIThWVeFOnUZOBDbqWW3RPP+BbGUCP3J+rvAhNCNVtS1os3GCUfumiVj3AGJjEIndISq/LZO4=
Visual documentation
I attached three screenshots of the same visible regression:
Screenshot 1 — FlutterFlow Test Mode
Shows the ClearInstructions page at approximately 393 × 852. The heading is much larger and thinner than intended.
Screenshot 2 — iOS Simulator
Shows that the same typography regression occurs in the generated/runtime application and is not limited to the FlutterFlow editor.
Screenshot 3 — FlutterFlow Editor
Shows the affected heading selected in the editor. FlutterFlow currently resolves its Theme Text Style as:
Display Large
57 px
400 / Normal
The screenshots also show other typography differences, including the incorrect text styling of the Continuer button.
Environment
FlutterFlow version: Desktop 7.0.73
Platform: macOS Desktop + Web
Browser: Chrome
Operating system affected: macOS
Project ID: doggeniusv1-ips3f5
Example viewport: 393 × 852
Runtime also tested on: iOS Simulator
FlutterFlow Desktop Editor: affected
Chrome Editor: affected
Test Mode: affected
iOS Simulator: affected
Standard Text widgets: affected
RichText / RichTextSpan widgets: affected
Additional Information
This is currently a very urgent and blocking issue for my application.
I had a major application update planned, but I have had to cancel/postpone it because typography and layouts are now broken across a large part of the project.
The application is already live and I am continuously losing users while I am unable to safely continue with the planned update.
Manually rebuilding the typography would take an extremely long time because the issue affects styles throughout the project. I also cannot be confident that manually recreating every previous responsive font size, weight and color would reproduce the application exactly as it looked before this regression.
More importantly, I am concerned that manually compensating for the bug now could create another problem if FlutterFlow later restores the previous Theme Text Style behavior.
I have already spent significant time investigating the issue, including comparing snapshots and project files and investigating through Codex and the FlutterFlow MCP tooling, but I have not been able to restore the previous typography behavior.
Could the FlutterFlow team please advise whether:
-
I should wait for a fix because this is a known/regression issue that can restore the previous Theme Text Style behavior, or
-
I need to manually rebuild all of my typography settings myself?
If this is a FlutterFlow regression, an indication of whether a fix or workaround is expected would be extremely helpful, because manually rebuilding the typography across the entire application would require a very significant amount of work and could still fail to reproduce the previous design accurately.
Any help or prioritization would be greatly appreciated, as this issue is currently blocking the application's next major release.
Can we access your project?
Current Behavior
Since this morning, August 26, 2026, typography across my existing project has suddenly reverted to what appears to be FlutterFlow's default Theme Text Style values.
Yesterday, August 25, the project was rendering correctly.
The issue affects the entire application, not one specific page, and occurs with both:
standard Text widgets
RichText / RichTextSpan widgets
For example, on the attached ClearInstructions page, a heading that previously used my customized responsive typography is now displayed as Display Large at 57 px / FontWeight 400, making it much larger and thinner than before.
Other typography properties have also changed. For example, the Continuer button text was previously white and is now grey.
The important exception is that texts where I later manually overrode individual typography values still appear correct. For example, if I manually changed a font size from 22 to 23 or manually changed its font weight, that explicit override remains intact.
The regression appears specifically to affect typography that relies on the existing customized FlutterFlow Theme Text Styles.
This is also not limited to the editor. I can reproduce it in:
FlutterFlow Desktop Editor
FlutterFlow in Chrome
Test Mode
iOS Simulator
I also tested an older snapshot from August 25, 2026 at 22:15, created while the application was still rendering correctly. The snapshot now shows the exact same typography regression.
I compared the current project with that snapshot:
theme.yaml is byte-for-byte identical
the complete widget tree of an affected page (quiz2) is identical
This makes it appear that the stored project itself has not changed, but that FlutterFlow is now interpreting the same typography configuration differently.
Expected Behavior
Existing customized Theme Text Styles should keep the same font sizes, weights, colors and responsive values after a FlutterFlow update.
An unchanged project or historical snapshot should render the same way it did before the update.
Typography configured differently for mobile, tablet and desktop should continue to use those customized responsive values instead of reverting to FlutterFlow defaults.
Steps to Reproduce
Steps to Reproduce
Open project doggeniusv1-ips3f5 in FlutterFlow Desktop 7.0.73 on macOS.
Open an existing page that uses the project's customized Theme Text Styles, for example ClearInstructions.
Use the mobile viewport around 393 × 852.
Inspect the main heading.
Observe that its Display Large style now resolves to approximately 57 px / 400 Normal, which is not how it rendered before August 26.
Inspect other existing theme-based text styles and observe incorrect sizes, weights and/or colors.
Run the project in Test Mode and observe the same typography regression.
Run the project in an iOS Simulator and observe the same regression.
Open the August 25, 2026 22:15 snapshot.
Observe that the historical snapshot now renders with the same incorrect typography, even though its stored theme and widget configuration are unchanged.
Compare this with text where typography was later manually overridden on the individual widget: those explicit manual overrides still render correctly.
This regression affects existing projects/styles, so I have not been able to reproduce it meaningfully from a new blank project.
Reproducible from Blank
Bug Report Code (Required)
IT4slMmA7ZF2obhA0KX2K+5R/SAWOUc1U78oscp/awggfbLLBIYuP/WkVFVuUsfjdHNIPESmmkI0pdrMhvPtOMYDHxSWG7Z4zaVIThWVeFOnUZOBDbqWW3RPP+BbGUCP3J+rvAhNCNVtS1os3GCUfumiVj3AGJjEIndISq/LZO4=
Visual documentation
I attached three screenshots of the same visible regression:
Screenshot 1 — FlutterFlow Test Mode
Shows the ClearInstructions page at approximately 393 × 852. The heading is much larger and thinner than intended.
Screenshot 2 — iOS Simulator
Shows that the same typography regression occurs in the generated/runtime application and is not limited to the FlutterFlow editor.
Screenshot 3 — FlutterFlow Editor
Shows the affected heading selected in the editor. FlutterFlow currently resolves its Theme Text Style as:
Display Large
57 px
400 / Normal
The screenshots also show other typography differences, including the incorrect text styling of the Continuer button.
Environment
Additional Information
This is currently a very urgent and blocking issue for my application.
I had a major application update planned, but I have had to cancel/postpone it because typography and layouts are now broken across a large part of the project.
The application is already live and I am continuously losing users while I am unable to safely continue with the planned update.
Manually rebuilding the typography would take an extremely long time because the issue affects styles throughout the project. I also cannot be confident that manually recreating every previous responsive font size, weight and color would reproduce the application exactly as it looked before this regression.
More importantly, I am concerned that manually compensating for the bug now could create another problem if FlutterFlow later restores the previous Theme Text Style behavior.
I have already spent significant time investigating the issue, including comparing snapshots and project files and investigating through Codex and the FlutterFlow MCP tooling, but I have not been able to restore the previous typography behavior.
Could the FlutterFlow team please advise whether:
I should wait for a fix because this is a known/regression issue that can restore the previous Theme Text Style behavior, or
I need to manually rebuild all of my typography settings myself?
If this is a FlutterFlow regression, an indication of whether a fix or workaround is expected would be extremely helpful, because manually rebuilding the typography across the entire application would require a very significant amount of work and could still fail to reproduce the previous design accurately.
Any help or prioritization would be greatly appreciated, as this issue is currently blocking the application's next major release.