Flutter & React Native at Scale: Multi-Team Architecture

Q: How do you structure a Flutter or React Native app for multiple teams?

Around feature modules with enforced boundaries. Each feature (checkout, search, profile) lives in its own package owning its screens, state, and logic, exposing a small public API and its routes. Three layers with one-directional dependencies: the app shell composes features and wires navigation and dependency injection; features depend only on core packages (design system, networking, auth, analytics contracts); and no feature ever imports another feature — anything two features share moves down into core, deliberately. In Flutter this means pub workspaces with local packages managed by Melos; in React Native, yarn or pnpm workspaces under Nx or Turborepo, with TypeScript project references. The critical part teams skip: enforcement. Nx ships module-boundary lint rules; Flutter gets equivalents through import linting and CODEOWNERS. A boundary that exists only by convention erodes in weeks, because the first deadline-driven cross-feature import never gets reverted. Alongside the modules sits one platform team owning the shell, the core packages, and CI as an internal product. The structure mirrors the org (Conway's law works both directions), which is exactly why it scales: each tribe operates in its own package with its own review queue, and the shared surface area is small, versioned, and owned.

Q: When should a mobile team adopt a monorepo with Melos or Nx?

Around the point where three or more teams commit to the same app, or earlier if CI time and merge conflicts already dominate the retrospectives. Below that size the tooling is overhead: a single squad in a single package ships faster without workspace indirection. The signals that say now: pipeline runs rebuilding the entire app for one-screen changes, merge conflicts concentrated in a handful of shared files, releases blocked because unrelated features landed half-done, and any plan to share code between the mobile app and a web app (Nx holds React Native and React web in one workspace naturally, which is a genuine strategic advantage for JS-stack orgs). What the tooling buys concretely: affected-graph builds that test only changed modules plus a shell smoke suite, cutting typical runs from 45 minutes to 8-12; remote build caching that removes another 30-50% on warm builds; task orchestration across packages; and mechanical boundary enforcement. One honest warning from the field: adopting the monorepo tooling without doing the module extraction changes nothing — the graph is only as useful as the boundaries in it. Extract the design system first, prove the CI improvement on real numbers, then migrate feature by feature while normal delivery continues.

Q: Should a platform team review every mobile PR?

No, and the orgs that try it recreate the exact bottleneck modularization was meant to remove — a central queue, now with opinions. The platform team's job is paved roads: the app shell, the design system, core networking and auth packages, CI and the release train, lint rules that enforce module boundaries mechanically, and templates that make the right structure the default structure. Feature squads own their modules end to end, including reviews, tests, feature flags, and crash triage for their screens. The mechanical guardrails replace human gatekeeping: boundary lint rules catch forbidden imports in CI rather than in review comments; CODEOWNERS routes changes to core packages to platform automatically while feature-package changes route to the owning squad; and the affected graph keeps blast radius visible. Platform reviews the 5% of changes that touch shared surface, not the 95% that live inside a module. The cultural test we apply in audits: ask three squad engineers when platform last shipped something that made their week easier. If the answers are all about approvals and never about tools, the platform team has drifted from product to gate, and throughput numbers will show it — typically a two-to-four-day median time-to-merge on changes that should take hours.

Q: How do release trains and feature flags work for mobile apps?

The train is a fixed schedule: a release cut every week or fortnight, shipping whatever is merged and stable at cut time. Features that are not finished ride dark behind flags rather than delaying the train. This solves the coordination problem that kills multi-team mobile delivery, where one team's almost-ready feature holds four other teams' finished work hostage. App-store review latency (hours to days, plus staged rollout time) means true continuous deployment is impossible for mobile binaries, so the train plus flags is the honest equivalent. The mechanics that make it safe: a beta cohort gets the cut for around 48 hours; crash-free session rate above a threshold (99.8% is a common bar) gates promotion to staged rollout from 10% toward 100%; and when a feature spikes crashes mid-rollout, the response is flipping its flag off remotely — shipping continues, the offending feature goes dark, and the fix rides the next train instead of forcing an emergency binary. Over-the-air update channels (CodePush-style for React Native, Shorebird for Flutter) cover JS or Dart-level hotfixes between trains, within store-policy limits. The discipline the whole scheme depends on: flags get removed after full rollout. Flag debt compounds into a testing-matrix explosion — a codebase with 40 stale flags has two-to-the-forty theoretical states and no one testing any of them.

Q: Is Flutter or React Native better for large organizations?

Both run at serious scale in 2026, and in audits the failures we see are architecture and team-topology failures far more often than framework failures. The real differentiators: React Native shares language and often code with a web-React estate — one Nx workspace holding web and mobile, shared TypeScript domain logic, one hiring pool — and the New Architecture (JSI, Fabric, TurboModules) removed most of the historical performance penalty; its tax is JavaScript toolchain churn, which a platform team must actively curate. Flutter offers compile-time safety and a single self-rendered UI pipeline, which makes very large codebase refactors and pixel-consistency across devices calmer, with mature workspace tooling via Melos; its tax is a smaller senior-hiring pool and a separate stack from web. Both handle on-device AI, offline-first patterns, and native module needs adequately now. The decision procedure we recommend: choose by organizational reality (existing web-React investment and shared talent points to React Native; greenfield product where UI consistency is paramount points to Flutter), write the decision down as an ADR with its reasoning, and then stop relitigating it — because the modular architecture, monorepo discipline, and release process this article describes are identical either way, and they, not the framework, decide whether 25 engineers outship 8.

Q: What is a backend-for-frontend and why do mobile teams at scale need one?

A BFF is an API layer owned by the mobile team that aggregates and shapes backend data for the app's screens, so the client is not stitching together five microservices' responses on a mobile radio. At multi-team scale it earns its keep several ways. Performance: one round trip per screen instead of a waterfall, which matters enormously on high-latency mobile networks where each extra request costs 100-300 milliseconds. Team autonomy: backend services evolve their contracts without breaking shipped app versions, because the BFF absorbs the change — critical for mobile, where last year's binary is still installed on real phones and cannot be force-upgraded. Protocol sanity: the REST-versus-GraphQL-versus-gRPC decision gets made once at the BFF boundary rather than per service, and GraphQL specifically shines here since screens can query exactly the fields they render. Security: token handling, session policy, and rate limiting concentrate in one place instead of being reimplemented per service. The ownership rule that makes it work: the mobile platform team (or the squads collectively) owns the BFF, because an API shaped by backend teams for backend convenience recreates the original problem one hop away. Versioning discipline still applies — the BFF must support every app version still in the field, which is typically 12-18 months of trailing releases.

Q: How do you migrate a monolithic mobile app to modular architecture without stopping feature work?

Incrementally, one module at a time, with the strangler pattern rather than a freeze. The sequence that works in practice. First, extract the design system: it has the clearest boundary, every team benefits immediately, and it forces the workspace tooling (Melos, Nx) into place on a low-risk target. Second, measure and publish CI and merge-conflict baselines, because the migration needs visible wins to keep its mandate — before-and-after pipeline times are the currency. Third, pick the feature with the fewest tangled dependencies (rarely the biggest one) and extract it end to end: package, boundary lint, routes-as-contract, owning squad. Every subsequent extraction gets cheaper as core packages accumulate. Fourth, put the boundary lint rules in CI from day one so extracted modules cannot silently re-tangle while later ones are still in progress. What kills these migrations: the big-bang variant, where feature work freezes for two quarters while the org restructures everything — it exhausts political capital long before it delivers, and the half-finished state is worse than either endpoint. Also fatal: extracting modules without enforcement, which produces folder theater — the directory tree looks modular while the dependency graph remains a ball of mud, and CI still rebuilds the world. Expect a real migration at 20-30 engineers to run two to four quarters of background work, and to pay for itself in CI time alone before it finishes.

Q: How big should a mobile platform team be?

A useful field ratio: roughly one platform engineer per two to three feature squads, with a floor of two people — a platform team of one is an incident away from being a platform team of zero, and we have watched exactly that take an org's release train down for a month. For a 25-engineer mobile org (four squads plus leads), that means a platform team of two to three owning the app shell, design system, core packages, CI and build infrastructure, the release train, and developer experience. Under-staffing shows up predictably: the design system stagnates and squads fork components locally; CI degrades gradually because nobody owns the build graph; the release train needs a hero every cut; and paved-road tooling never materializes, so every squad solves the same problems differently. Over-staffing (or mis-chartering) shows up as gatekeeping: platform inserting itself into feature reviews, building elaborate abstractions nobody asked for, and optimizing metrics squads do not feel. The charter that keeps it healthy: platform is a product team, its customers are the squads, and its roadmap should answer squad pain in measurable terms — pipeline minutes, time-to-first-build for a new hire, design-system adoption rate. Review those numbers quarterly the way you would review any product's metrics, and resize accordingly.

Satyam Kumar

返回博客

ai-architecture

Flutter and React Native at Scale: When Many Teams Share One App

By Satyam KumarJuly 9, 20269 min read

flutter architecture react native architecture mobile monorepo feature modules melos nx monorepo turborepo modular mobile architecture mobile at scale release train feature flags design system package mobile ci cd team topologies conways law flutter vs react native mobile app architecture 2026

Flutter and React Native at Scale: When Many Teams Share One App

Frequently Asked Questions

分享这篇文章

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

人工智能和云架构师。帮助团队构建可扩展到数百万的系统。

LinkedIn GitHub

Flutter and React Native at Scale: When Many Teams Share One App

Frequently Asked Questions

分享这篇文章

Comments

Leave a comment