Key Takeaway
FlutterFlow gives you three scopes for state: app state (global, lives for the whole session and can persist to disk), page state (local to one screen), and component state (local to a reusable widget). Use the narrowest scope that works. Reach for app state only when a value is genuinely shared across pages, because every app-state change can trigger broad rebuilds and slow your app down.
If you have built more than a couple of screens in FlutterFlow, you have already hit the question: where should this value live? Should the logged-in user go in app state? Does a toggle on one page belong in page state? Why does my whole app rebuild when I update one variable? This guide explains the three state scopes in FlutterFlow, when to use each, how to persist values, how to pass parameters between pages, and the common mistakes that quietly make apps slow.
This is accurate as of 2026. FlutterFlow updates its editor often, so menu labels may shift slightly, but the underlying model has been stable for a long time.
The three state scopes in FlutterFlow
FlutterFlow maps directly onto how Flutter itself thinks about state, just with a visual layer on top. There are three places a variable can live.
App state (global)
App state is a global variable available to every page and component in your project. You define it once under the App State panel, give it a type (String, Integer, Boolean, a data type, or a list), and then read or set it anywhere. App state can also be set to persist, which writes it to the device so it survives an app restart.
App state is the right home for things that are truly global: the signed-in user record, an auth token, a theme preference (light or dark), a shopping cart, or a list of favorites. These follow the user around the whole app, so a single shared source of truth makes sense.
Page state (local to a screen)
Page state is a variable that exists only while a given page is open. In FlutterFlow these are the Page State variables you define on a specific page, plus the local state attached to widgets like a text field's value or a switch's on/off position. When the user leaves the page, that state is gone unless you deliberately saved it somewhere.
Page state is where most of your variables should live. A search box's current text, whether a filter panel is expanded, the selected tab, a form's draft values: all of this is local to one screen and has no business being global.
Component state (local to a reusable widget)
Component state belongs to a FlutterFlow component, which is a reusable widget you build once and drop onto many pages. Each instance of the component gets its own copy of that state. If you build a custom rating widget and place three of them on a page, each one tracks its own value independently. Component state keeps reusable pieces self-contained so they do not step on each other.
App state vs page state: a side-by-side comparison
The single most searched FlutterFlow state question is app state versus page state. Here is the short version, then the table.
| Question | App State | Page State | Component State |
|---|---|---|---|
| Where can you read it? | Anywhere in the app | Only on that page | Only inside that component instance |
| How long does it live? | The whole session, or forever if you persist it | Until you leave the page | Until the component is removed |
| Can it survive a restart? | Yes, if persisted | No | No |
| Rebuild cost when it changes | Can be high, may rebuild widgets across the app | Low, scoped to the page | Low, scoped to the instance |
| Good for | User, auth, cart, theme | Form drafts, filters, selected tab | Self-contained reusable UI |
The rule that keeps apps fast: use the narrowest scope that still works. Default to page or component state. Promote a value to app state only when you can point at two or more pages that genuinely need to read the same value.
How to persist state across app restarts
Page and component state are temporary by design. If you need a value to survive the app closing and reopening, you have a few options in FlutterFlow.
- Persisted app state. When you create an app-state field, turn on the persist toggle. FlutterFlow stores it on the device so it is restored on launch. This is the simplest path for small things like a theme choice or an onboarding-complete flag.
- Your backend. For anything that must follow the user across devices, such as their profile, orders, or saved items, store it in Firebase or Supabase rather than on the device. Load it into app state when the app opens.
- Authentication. The logged-in user is handled by FlutterFlow's auth integration, so you usually do not need to persist credentials by hand. Read the current user instead of copying it into a separate persisted variable.
A useful habit: persist preferences and flags locally, but keep the real data of record in your backend. Local persistence is convenience, not a database.
Passing parameters between pages
A very common pattern is a list page that opens a detail page: tap a product, see that product. You do not need app state for this. FlutterFlow lets you define page parameters on the destination page, then pass values into them when you navigate.
The flow looks like this:
- Open the detail page and add a page parameter, for example
productIdof type String, or a parameter typed to your product data type. - On the list page, add a Navigate To action on the item tap and set the parameter value, usually from the tapped item in the list.
- On the detail page, read the parameter and use it to query the single record or to populate the UI directly.
Page parameters are the cleanest way to move data forward through navigation. They keep each page self-contained and avoid a pile of global variables that you have to remember to clear. Reach for app state only when the value needs to be read by pages that are not directly in the navigation chain, like a cart badge that shows in your nav bar everywhere.
Common pitfalls (and how to avoid them)
1. Over-using app state
This is the number one issue we see in FlutterFlow projects. It is tempting to make everything an app-state variable because then you can read it anywhere. The cost shows up later: a tangle of global variables, unclear ownership, and values that linger between screens when they should have been reset. If a variable is only used on one page, it should be page state. Be strict about this from the start.
2. Rebuild costs from global updates
When app state changes, FlutterFlow rebuilds widgets that depend on it. If a value updates frequently, such as a counter or a scroll position, putting it in app state can cause a lot of rebuild work and visible jank. Keep frequently changing values local, and reserve app state for things that change occasionally.
3. Forgetting to reset state
Because app state persists for the session, a value set on one visit is still there on the next. A common bug: a user edits a form, leaves, comes back, and sees the old draft because it was stored globally and never cleared. Page state avoids this automatically since it resets when you leave. If you do use app state for a draft, clear it explicitly when you are done.
4. Reading state before it is set
If a widget reads an app-state value that has not loaded yet, you can get nulls or blank UI on first paint. Set initial values, load data in an On Page Load action, and show a loading state while a backend query runs.
5. Storing derived values instead of computing them
Avoid saving things you can calculate. If you have a cart in app state, do not also store the total as a separate variable you have to keep in sync. Compute the total from the cart at display time. One source of truth, fewer bugs.
A simple decision checklist
When you create a new variable, ask in order:
- Does only one widget instance use it? Use component state.
- Does only one page use it? Use page state.
- Is it needed by a page I am navigating to? Pass it as a page parameter.
- Is it read across many unrelated pages for the whole session? Now app state is justified.
- Does it need to survive a restart? Persist app state, or store it in your backend.
FAQ
What is the difference between app state and page state in FlutterFlow?
App state is global and available to every page and component, and it can persist across restarts. Page state is local to a single screen and is cleared when you leave that screen. Use page state by default and promote to app state only when a value is shared across multiple pages.
How do I make FlutterFlow state persist after closing the app?
For small values, enable the persist option on an app-state field so FlutterFlow saves it to the device. For real user data that should sync across devices, store it in your backend like Firebase or Supabase and load it into app state when the app opens. Page and component state never persist on their own.
How do I pass data between two pages in FlutterFlow?
Define a page parameter on the destination page, then set its value in the Navigate To action on the source page. The destination page reads the parameter to display the right content. This is cleaner than using global app state for navigation data.
Why does my FlutterFlow app rebuild or feel slow when state changes?
Updating app state can rebuild widgets across the app that depend on that value. If a frequently changing value lives in app state, those rebuilds add up and cause jank. Keep fast-changing values in page or component state, and use app state only for values that change occasionally.
When should I use component state versus page state?
Use component state for reusable widgets where each copy needs its own independent value, like a rating widget you place several times on one screen. Use page state for values tied to the page as a whole, like which tab is selected or the current filter.
The bottom line
FlutterFlow's state model is not complicated once you internalize one rule: use the narrowest scope that works, and only go global when you truly must. Default to page and component state, pass data forward with page parameters, persist only what needs to survive a restart, and treat your backend as the real source of truth. Do that and most of the slow, buggy, hard-to-reason-about behavior simply does not happen.
That said, getting state architecture right is exactly the kind of work that decides whether an app stays fast and maintainable a year from now, and it is easy to get wrong while you are also juggling design, backend, App Store submission, and everything else. If you would rather not own that, Rehost is a done-for-you operator based in Los Angeles. We design, build, host, monitor, and operate custom apps and websites for you. Your team never logs into a builder or a dashboard; you send a plain message and we ship the change. You still own the app, the App Store and Google Play developer accounts, the domain, the code repo, and your customer data, all portable if you ever leave.
Pricing is month to month with no setup fee, billed by monthly active users, starting around $950/mo as of 2026. A custom website typically launches in under a week and a full app build in about two weeks. You can estimate your cost with the app calculator, see the details on how the done-for-you model works, or just tell us what you are trying to build.