If you're adding a second customer organization to a Flutter app, start with one question before you touch any screen: at what exact moment does your process know which tenant it is running as? A multi tenant Flutter app is one binary serving several customer organizations, where tenant identity is part of every read and write instead of a column you remember to filter on. The backend half of that problem is well covered. The mobile half has failure modes that backend write-ups never reach, because a phone restores state before your first widget builds and can receive a push notification for a tenant it hasn't opened in weeks.
BookBed is the closest real example I can point to. Its case study describes a property management system I built solo from one Flutter codebase for iOS, Android, Web, macOS, Linux and Windows, on Firebase and Stripe, priced at 9 euros a month for up to twenty units. That is the small-customer, many-customers, one-binary shape this post is about. I won't claim its internals match every pattern below. Where I cite the platform, I link the source I checked on 30 September 2026, and where I recommend something, I label it as a recommendation.
What makes a Flutter multi-tenant app different from a backend one?
A Flutter app is multi-tenant when tenant identity is resolved once at session start and then carried implicitly by every layer below it, so no repository or cache can be built before the tenant is known.
Most teams reach for the storage question first, which is the multi-tenant SaaS question every backend article covers: a shared schema with a tenant_id column, a collection tree per tenant, or a database per tenant. Answer it, obviously. But that answer is portable. It's identical whether your client is a browser or a phone.
What a phone adds is state that outlives the process. A browser tab starts empty. A phone starts with a persisted auth session, a cached push registration, a local database file, and possibly a notification the user tapped to get here. Each of those is tenant-scoped, and all of them come back before your UI does. Get the order wrong and the app comes up authenticated as the right person inside the wrong organization. Every problem in the rest of this post is a variation on that ordering.
Tenant selection belongs to the session, not the screen
Treat tenant selection as an authentication concern, not a navigation concern. This is a recommendation, and the reasoning is structural: a picker screen after login is cheap to build and painful to remove, because everything built underneath quietly assumes the tenant is already known. The contract to aim for is that no repository can be constructed until a tenant exists, which puts the choice inside your auth state machine instead of downstream of it.
If you use a managed provider, read its tenant model early. Google Cloud Identity Platform supports tenants with their own users and identity providers, and its quota documentation lists 2 tenants per project without a billing instrument and unlimited with one. That's a development-time trap: the third seed tenant fails to create and the error doesn't obviously point at billing. The same page says there's no limit on identity providers per project or tenant, so per-tenant sign-in configuration is supported by design. Prototype the exact sign-in flow one of your customers would use on a real device before you commit a sprint to it.
For a B2B SaaS product where one person can belong to several organizations, add one more rule, also a recommendation: the tenant list is a property of the account, and the active tenant is a property of the session. Merge the two and switching organizations on a tablet can silently switch it on the phone as well.
How do you white-label a multi-tenant Flutter app?
Ship one binary with runtime theming until a customer needs their own store listing, then add a build-time flavor for that one customer. The split is about whose name appears in the store, not which shade of blue the buttons are.
Flutter flavors cover the second case, and they're compile-time by definition. The Flutter flavors guide says the appFlavor constant returns the name passed to --flavor during the run or build. A flavored tenant is a build artifact.
| Approach | Tenant identity comes from | Adding a tenant costs | Falls over when |
|---|---|---|---|
| Build-time flavors | --flavor passed at compile time | A build, a store listing, a review cycle | Every new tenant needs its own release and store review |
| Runtime config | Tenant document fetched right after auth | One database record | A customer demands their own icon on the home screen |
| Hybrid | Flavor for app identity, remote config for brand | Depends which tier they bought | Sales promises the top tier to a customer on the bottom one |
Start at runtime config and stay there longer than feels natural. A tenant-scoped theme record holding a seed color, a logo URL and a display name can feed ColorScheme.fromSeed, which the Flutter API reference describes as generating a color scheme from a seed color. Cache that record locally. It has to exist before the first frame on a cold launch, and a network fetch there shows the default theme for a moment before the brand appears.
Flavors earn their cost when a customer needs to be discoverable under their own brand, and that decision reaches past engineering. Google's white label best practices for Play recommend a separate developer account per client or client group. The stated reason is that a policy issue with one app can negatively affect every app in a shared account. The same page asks that each listing, even for a template app, carry its own description, icons, graphics and screenshots. A template listing cloned across many customers is how you meet the repetitive-content policy.
One recent change touches the runtime path. What's new in Flutter 3.47, published 12 August 2026, announced the 1.0 release of standalone material_ui and cupertino_ui packages that can ship fixes on weekly schedules. The post describes them as opt-in for this release, and the core SDK still includes the libraries. My inference is that this matters most when many brands share one binary and you want design-system fixes without an SDK upgrade, but I haven't tested it in a multi-tenant build. The tools I'd use around all of this are in my list of Flutter developer tools.
How do push notifications and deep links reach the right tenant?
Send pushes to registrations you store per user and tenant, and treat every deep link as an untrusted claim about which tenant its content belongs to.
Why FCM topics are the wrong tenant boundary
Firebase's topic messaging documentation says topics are best suited for publicly available information such as weather alerts, and recommends targeting registration tokens for fast, secure delivery to single devices or small groups. It also documents that one app instance can subscribe to no more than 2000 topics, and that adding or removing subscriptions is limited to 3,000 QPS per project. Tenant-private notifications don't fit a mechanism documented for public information, so my recommendation is not to hang them on topic names.
The pattern I'd use is a registration table you own. Firebase's guide to FCM registration management recommends storing registrations on your server with a timestamp, refreshing that timestamp regularly, and removing stale ones. It also says an Android registration inactive for 270 days expires. Key each row by user and tenant, fan out server-side from code you can audit, and delete the row on sign-out. Route the payload through the same tenant check your API uses, because a booking identifier from tenant A opened in a session for tenant B is a permission check you probably have on the server and probably lack in the deep link handler.
Deep linking into the correct tenant
A deep link arrives before your app knows who anybody is. The link fires, Flutter boots, the router wants a route, and your auth state machine is still restoring the session. Resolve it in this order:
- Park the link. Capture the incoming URI in a pending-intent holder and show a splash. Don't let the router act on it.
- Restore the session. Auth first, including the tenant.
- Read the tenant from the link, not the session. Treat it as untrusted input.
- Compare, then branch. Same tenant as the session: navigate. A different tenant the user belongs to: switch, then navigate. A tenant the user doesn't belong to: show a plain "you don't have access to this" screen, because the user is usually signed into the wrong account and needs to be told so.
- Replay the parked link exactly once. Clear the holder afterwards, or the link fires again on the next resume.
There's also a platform trap. Android's App Links verification documentation states that on Android 11 (API level 30) and lower, the system makes your app the default handler only if it finds a matching Digital Asset Links file for all hosts in the manifest. If you give eight tenants vanity domains and one file goes missing, my reading is that verification fails for the whole app on those versions. Consider one canonical domain with the tenant in the path, and price per-tenant vanity domains as a premium feature.
Switching tenants inside a live session
Switching has to tear down more than it seems. Repositories, streams, the local database handle, image caches keyed by ID, and any provider holding a snapshot all belong to the old tenant. The simplest implementation is to dispose the whole dependency graph and rebuild it from the root, exactly as a sign-out does. It's slower, and it's correct. Test it explicitly, because nobody notices it until a customer sees another organization's data for one frame.
What should you check in your own app this week?
Open the app and find the point where your process learns its tenant. If the answer is "after the first screen renders", the problems above are already in your codebase, and the fix is a bootstrap change rather than a feature: move tenant resolution into the auth state machine, make the router wait on it, and only then argue about theming.
Then count the rows in your push registration table. How many belong to a user who hasn't opened that tenant in months, and what removes them today?