Strong answer: final variables are set once at runtime and cannot be reassigned. const variables are compile-time constants — their value must be known at compile time. In Flutter, const widgets are a key optimisation: a const Widget is created once and reused, never rebuilt during recomposition. This is why const constructors on StatelessWidgets are so valuable for performance — always add const where possible.

Strong answer: Dart’s sound null safety (stable since Dart 2.12) means types are non-nullable by default. String can never be null; String? can. This eliminates null reference exceptions at runtime by catching them at compile time. Key operators: ?. (null-aware access), ?? (null coalescing), ??= (null-aware assignment), ! (null assertion — throws if null, use sparingly), late (deferred initialisation — not null but initialised after declaration).

Strong answer: Mixins provide a way to reuse code across class hierarchies without traditional inheritance. A mixin is declared with mixin keyword and applied with with. Unlike abstract classes: (1) A class can use multiple mixins (with A, B, C), solving the multiple inheritance problem. (2) Mixins cannot be instantiated directly. (3) mixin on BaseClass restricts which classes can use the mixin. Flutter uses mixins extensively — e.g., TickerProviderStateMixin for animation.

Strong answer: dynamic bypasses all static type checking — any operation is allowed, errors appear at runtime. Object? is the root type with null safety; you must check the type before using it. Prefer Object? for APIs that accept any type while retaining type safety. Generics in Dart are covariant — List<Apple> is a subtype of List<Fruit>. This is unsound (can cause runtime errors with mutable collections) but pragmatic for Flutter’s use cases. Dart 3 introduced patterns and records for safer destructuring.

Strong answer: Extensions add methods to existing types without modifying or subclassing them. Dart syntax: extension StringX on String { bool get isEmail {...} }. Flutter use cases: adding helper methods to BuildContext (e.g., context.colorScheme, context.go('/route')), adding formatting to DateTime, adding utility methods to model classes, and wrapping widgets in convenience helpers. Extensions help reduce boilerplate and keep code readable without utility class proliferation.

Strong answer: Records are anonymous, immutable, typed aggregate types — like lightweight named tuples. Syntax: (int, String) pair = (42, 'hello'); or named: ({int age, String name}) person = (age: 25, name: 'Alice');. Use cases: returning multiple values from a function without creating a class, destructuring in pattern matching, grouping related values temporarily. Records are value types with structural equality. Combined with Dart 3 patterns (switch (record) { case (var x, var y) when x > 0: ... }), they enable powerful functional-style code.

Strong answer: Dart uses a generational, concurrent garbage collector. The young generation (new space) uses a semi-space copying collector for short-lived objects — very fast. The old generation uses incremental mark-and-sweep. Flutter implications: (1) Creating many short-lived widget objects (a common pattern) is optimised — they’re collected cheaply in young space. (2) Holding large objects in state prevents GC of the old generation. (3) Avoid allocating inside build() methods for objects that could be cached (e.g., TextStyle, decoration objects). (4) Profile GC pressure with Flutter DevTools memory profiler.

Strong answer: JIT (Just-In-Time): used in debug mode — enables hot reload/restart, faster development cycles, but larger binary and slower runtime. AOT (Ahead-Of-Time): used in release mode — compiles to native ARM code, smaller binary (dead code elimination), significantly faster runtime (no JIT overhead), but no hot reload. This is why Flutter debug performance is not representative of release performance. Profile mode uses AOT with some debug information — always use profile mode for performance benchmarking. Dart’s AOT compilation to native is why Flutter apps start faster than React Native (no JS bundle parsing).

Strong answer: Three trees: Widget tree (immutable configuration blueprints — cheap to create/destroy), Element tree (mutable, long-lived — Flutter’s reconciliation layer, matches widgets to rendered objects), Render tree (actual layout, painting, hit-testing). On rebuild, Flutter creates new widget objects but intelligently reconciles with the existing element tree — only updating elements whose configurations changed. This makes widget rebuilds cheap even when the tree is large, because new widget objects don’t mean new render objects.

Strong answer: BuildContext is a reference to a widget’s location in the widget tree. Common mistakes: (1) Using BuildContext across async gaps — after an await, the context may no longer be valid (mounted check required). (2) Using the wrong context for Navigator.of(context) or Theme.of(context) — context must be below the relevant ancestor. (3) Storing BuildContext in a ViewModel/Service — contexts should not live outside the widget lifecycle. (4) Not checking if (mounted) before using context after async operations in StatefulWidgets.

Strong answer: In a Row: mainAxis is horizontal, crossAxis is vertical. In a Column: mainAxis is vertical, crossAxis is horizontal. MainAxisAlignment controls spacing between children along the main axis (start, end, center, spaceBetween, spaceAround, spaceEvenly). CrossAxisAlignment aligns children along the cross axis (start, end, center, stretch, baseline). Common mistake: using crossAxisAlignment: CrossAxisAlignment.stretch without the parent having bounded constraints causes layout overflow errors.

Strong answer: Keys help Flutter identify which widgets correspond to which elements when the widget tree changes. Without keys, Flutter uses widget type and position for reconciliation. Use keys when: (1) Reordering widgets of the same type in a list — keys preserve the associated State. (2) Moving a stateful widget from one location in the tree to another. (3) GlobalKey — access a widget’s state or find its size/position. Key types: ValueKey (by value), ObjectKey (by object identity), UniqueKey (always different — forces rebuild), GlobalKey (cross-tree access, use sparingly).

Strong answer: CustomPainter gives direct access to the Canvas API for custom drawing. Implement paint(Canvas canvas, Size size) for drawing logic and shouldRepaint() to control when to repaint (return false if nothing changed). Canvas operations: drawPath, drawCircle, drawImage, drawArc etc. Use for: custom chart components, drawing apps, complex decorative elements that can’t be composed from standard widgets, game UI elements. Performance: CustomPainter runs on the raster thread — keep it efficient, avoid complex computations in paint().

Strong answer: InheritedWidget is Flutter’s mechanism for passing data down the widget tree efficiently without drilling through constructors. When an InheritedWidget’s data changes, only descendant widgets that called context.dependOnInheritedWidgetOfExactType<T>() are rebuilt. Provider wraps InheritedWidget with a more convenient API. Riverpod intentionally avoids InheritedWidget (that’s a key design choice) — instead using a global ProviderContainer, which is why Riverpod providers don’t need BuildContext and work outside the widget tree.

Strong answer: Implicit animations (AnimatedContainer, AnimatedOpacity, TweenAnimationBuilder): specify the target value and duration — Flutter interpolates automatically. Use for simple property animations. Explicit animations (AnimationController + Tween + AnimatedBuilder): full control over animation playback, curves, sequencing, and composition. Use for: complex sequences, physics-based animations, animations that respond to gestures, composing multiple animations. AnimationController manages timing, Tween interpolates values, CurvedAnimation applies easing. Hero animations handle cross-route transitions.

Strong answer: Impeller is Flutter’s new rendering engine, default on iOS since Flutter 3.10 and Android in 3.16+. Problem it solves: Skia’s shader compilation happens at first use, causing “jank” (dropped frames) the first time a new rendering effect is encountered. Impeller pre-compiles all shaders at build time using a smaller, predictable shader set — eliminating first-frame jank. The trade-off: slightly different rendering quality in some edge cases and the initial implementation missed some effects. By 2026, Impeller is stable on both platforms. Developers should test on both Impeller and Skia if targeting broad device support.

Strong answer: Flutter’s layout algorithm: constraints go down, sizes go up, parents position children. Each widget receives BoxConstraints (min/max width and height) from its parent, chooses a size within those constraints, and reports it back. Common issues: Unbounded constraints (infinite height/width) cause “constraints are infinite” errors — happens when a ListView is inside a Column without constraints. Tight constraints (min==max) leave no sizing choice. Understanding constraint flow explains why SizedBox.expand(), Expanded, and Flexible work the way they do.

Strong answer: Flutter uses logical pixels (dp/pt) — sizes specified in logical pixels are automatically scaled by the device pixel ratio. Key practices: (1) Use MediaQuery.of(context).devicePixelRatio only when you need actual physical pixels (e.g., image resolution). (2) Use LayoutBuilder for responsive layouts that adapt to available width. (3) MediaQuery.of(context).size for screen-size-relative sizing. (4) For text: textScaleFactor-aware sizing. (5) For precise custom drawing in CustomPainter, work in logical pixels — the canvas handles density automatically.

Strong answer: setState: local UI state within a single StatefulWidget — for simple, self-contained state. Provider: InheritedWidget wrapper, well-established, good for moderate complexity. Riverpod: compile-safe, testable, no BuildContext dependency — recommended for new projects in 2026. Bloc/Cubit: strict unidirectional flow, excellent for complex business logic and large teams where predictability matters. GetX: all-in-one but opinionated and couples concerns — generally avoided on teams with strong architecture standards. MobX: reactive, code-generation based.

Strong answer: Provider: simple read-only value. StateProvider: simple mutable value. NotifierProvider: complex synchronous state with methods (replaces StateNotifierProvider in Riverpod 2.x). AsyncNotifierProvider: for async state — handles loading/error/data states automatically. FutureProvider: simple async value. StreamProvider: stream of values. ref: the way providers access each other (ref.watch triggers rebuild on change, ref.read reads without subscribing, ref.listen for side effects without rebuild). With code generation (Riverpod 2.x), annotate with @riverpod — recommended over manual provider creation.

Strong answer: BLoC (Business Logic Component) enforces unidirectional data flow: UI emits Events → Bloc processes them → emits States → UI rebuilds. Cubit is a simplified version: UI calls methods directly on Cubit → Cubit emits States. Bloc is better when: events have complex transformation logic, you need event transformers (debouncing, throttling), and you want full traceability. Cubit is better when: the state transitions are simple, less boilerplate is desired. Both are tested the same way (bloc_test library) and use the same BlocProvider/BlocBuilder widget layer.

Strong answer: Navigator 1.0: imperative (Navigator.push/pop) — simple but doesn’t handle deep links or web URLs well. Navigator 2.0 (Router API): declarative, full control over the back stack, complex to implement directly. GoRouter: builds on Navigator 2.0 with a simpler URL-based API — the recommended solution in 2026. GoRouter features: URL-based routing, deep links, redirects (for auth), ShellRoute for nested navigation (bottom nav bar), StatefulShellRoute for persistent navigation state. context.go('/route') for navigation, context.push for stacking.

Strong answer: Multiple layers: (1) FlutterError.onError: catches Flutter framework errors (layout errors, rendering errors). (2) PlatformDispatcher.instance.onError: catches unhandled Dart errors. (3) runZonedGuarded(): catches all errors in a zone including async errors. (4) Error boundaries in UI: wrap subtrees with ErrorWidget.builder customised to show a recovery UI instead of the red screen. (5) In production: send to Crashlytics/Sentry inside the error handlers. (6) Result types (like Dartz Either or custom Result) for expected errors in business logic — don’t use exceptions for expected failures.

Strong answer: Freezed is a code generation library for immutable data classes, unions, and sealed classes in Dart. It generates: copyWith(), ==, hashCode, toString(), and pattern matching for union types. Flutter use cases: (1) Immutable state classes for BLoC/Riverpod — state is replaced, not mutated. (2) Sealed union types for states (loading/error/success). (3) API model classes with fromJson/toJson via json_serializable integration. The generated code eliminates massive amounts of boilerplate while ensuring correctness of equality and immutability.

Strong answer: provider.family creates a parametrised provider — e.g., userProvider.family(userId) creates a separate provider instance per userId. Family providers are cached by parameter, so ref.watch(userProvider(123)) from any widget returns the same instance. ProviderScope overrides allow replacing providers in tests or for subtree-scoped state. provider.autoDispose disposes the provider when no widget is watching it — essential for preventing memory leaks with family providers (otherwise all cached instances accumulate). Combine: userProvider.family.autoDispose.

Strong answer: Optimistic update pattern: (1) Immediately update local state to reflect the expected result. (2) Trigger the network request. (3) On success: confirm (state is already correct). (4) On failure: roll back to previous state and show error. Implementation in Riverpod Notifier: store previous state, emit optimistic state, await API call, on catch emit previousState and show error via a separate event mechanism (SharedFlow/error Notifier). This gives a snappy UI while maintaining correctness. Critical: the rollback must restore the exact previous state, not just clear the optimistic change.

Strong answer: Architecture: (1) FeatureFlagService that fetches flags from Firebase Remote Config or LaunchDarkly on app start. (2) Wrap service in a Riverpod Provider — widgets ref.watch(featureFlagProvider).isEnabled('new_checkout'). (3) Provider allows easy testing — override in tests with controlled flags. (4) Hot reload-compatible: flags update without restart via Remote Config real-time listener. (5) Analytics events track which variant a user was in. For A/B tests: deterministic bucketing by user ID ensures consistent experience, flags propagate as part of the initial app load before first meaningful render.

Strong answer: Architecture layers: (1) Local database (Drift/Isar) as single source of truth — all UI reads from local. (2) Repository syncs network to local DB, returns streams from DB. (3) Riverpod StreamProvider watches the DB stream — UI automatically updates when data changes. (4) Mutations: write locally first (optimistic), queue network request, retry on connectivity. (5) Connectivity monitoring via connectivity_plus — trigger sync when online. (6) Conflict resolution strategy (last-write-wins or server-wins) defined at Repository level. (7) Sync status exposed as separate provider for UI to show “syncing” indicators.

Strong answer: Future: represents a single async value — completes once with a value or error. Stream: represents a sequence of async events — zero or more values over time. Types of Streams: single-subscription (can only have one listener — HTTP responses, file reads) and broadcast (multiple listeners — UI events, WebSocket messages). In Flutter: use Future for one-time data fetching, Stream for real-time data (database updates, WebSocket, user location). FutureBuilder and StreamBuilder widgets handle the async lifecycle in the UI layer.

Strong answer: Dart is single-threaded — async/await is concurrency (interleaved execution on one thread), not parallelism. Isolates are true parallel execution — separate memory heaps, communicate via message passing (no shared state). Use async/await for: I/O-bound work (network, file reads) that doesn’t need the CPU — it frees the thread while waiting. Use Isolates for: CPU-intensive work that would block the UI thread — JSON parsing of large payloads, image processing, encryption, complex data transformation. Flutter’s compute() is a convenience wrapper for one-off Isolate tasks.

Strong answer: compute(function, argument) spawns a new Isolate, runs the function with the argument, and returns the result — automatic lifecycle management. Limitations: (1) Only one argument (workaround: pass a record or map). (2) Function must be top-level or static (cannot be a closure that captures state). (3) Spawning overhead (~100ms) — not worth it for small tasks. (4) For repeated use (e.g., an image processing pipeline), spawning a new Isolate each time is wasteful. Better: use Isolate.spawn directly with a ReceivePort for a long-lived Isolate, or the new Isolate groups API in newer Dart versions. The isolate package provides a worker pool abstraction.

Strong answer: Pattern: (1) Text field’s onChanged callback emits the query to a StreamController or Riverpod StateProvider. (2) Debounce the stream — wait for 300ms of inactivity before triggering the API call (using RxDart’s debounceTime or a manual Timer). (3) Cancel the previous in-flight request before making a new one — use a CancelToken (Dio) or switchMap stream operator. (4) Show a loading indicator during search. (5) Handle the empty query state — don’t search for empty strings. Riverpod approach: use ref.watch(queryProvider) in an AsyncNotifier and ref.debounce.

Strong answer: Use the web_socket_channel package. Architecture: (1) Encapsulate WebSocket in a Service class with a StreamController that the rest of the app observes. (2) Reconnection: listen to connectivity changes (connectivity_plus) — on network restore, re-establish connection. (3) Exponential backoff for reconnection attempts (2s, 4s, 8s, max 60s). (4) Heartbeat/ping mechanism to detect silent disconnections. (5) Message queue for messages sent while offline — flush on reconnect. (6) Expose connection state (connecting/connected/disconnected) as a Stream for the UI to show appropriate indicators.

Strong answer: Isolate groups (Dart 2.15+): isolates within a group share their code via a shared heap for code, reducing memory overhead and spawning time significantly (from 100ms to ~1ms). Shared code, separate data heaps. Isolate.spawn() within the same group is much faster. TransferableTypedData: allows transferring large binary data between isolates without copying — the original becomes unusable (ownership transfer). This is critical for image processing pipelines that need to pass large Uint8List buffers between isolates efficiently.

Strong answer: Architecture: (1) WebSocket connection to a presence server (or Firebase Realtime Database/Supabase). (2) Presence service publishes local cursor position on pointer events (throttled to ~10fps). (3) Receives remote cursor positions, updates a Map in a StateNotifier. (4) Overlay widget renders cursor indicators for each remote user using Stack + Positioned, animated with TweenAnimationBuilder for smooth movement. (5) CRDT (Conflict-free Replicated Data Type) for document content merging. (6) Offline handling: buffer local operations, rebase on reconnect. Tools: Yjs for CRDT, Supabase Realtime for presence.

Strong answer: Tool chain: Flutter DevTools → Performance tab (frame timeline, identify jank: frames above 16ms), Widget rebuild tracker (which widgets rebuild unnecessarily), Memory profiler (leaks, allocations). Common fixes: (1) const constructors — prevent rebuilds. (2) Move expensive builds into separate widgets with their own rebuild scope. (3) Use ListView.builder not ListView for long lists. (4) Cache complex computations with useMemoized (hooks) or derived providers (Riverpod). (5) Move image decoding to Isolate. (6) Avoid Opacity widget (uses compositing layer) — prefer alpha in paint or AnimatedOpacity with offstage.

Strong answer: Unit tests: pure Dart, no Flutter framework, test business logic in isolation. Widget tests: test a widget tree in a lightweight test environment (no device needed) using WidgetTester — pump, find, interact. Integration tests: run on real device/emulator with integration_test package — test complete user flows end-to-end. Testing pyramid: many unit tests (fast, isolated), moderate widget tests, few integration tests (slow, flaky). Key tools: mockito/mocktail for mocking, bloc_test for BLoC, riverpod override for Riverpod providers in tests.

Strong answer: Wrap the widget in a ProviderScope with overrides parameter. Use ProviderScope(overrides: [myProvider.overrideWithValue(MockService())], child: MyWidget()). For async providers, use overrideWith to return controlled values without actual network calls. Use container.read() in tests to assert provider state. The ProviderContainer in unit tests (without Flutter): final container = ProviderContainer(overrides: [...]); addTearDown(container.dispose);. This makes Riverpod-based apps highly testable without complex mocking setups.

Strong answer: (1) Build with --split-debug-info and --obfuscate — symbols in separate file, smaller binary. (2) Use app bundles (AAB on Android) — Play Store delivers per-ABI splits. (3) Tree-shaking is automatic — unused code removed. (4) Icon fonts: import only the icons used (FontAwesome ProBuilder, Material Icons subset). (5) Image assets: WebP instead of PNG, appropriate resolutions only. (6) Analyse with flutter build apk --analyze-size — outputs code size breakdown. (7) Avoid large dependency trees — each package adds to binary. (8) Deferred components (Android): load feature code on demand.

Strong answer: Golden tests compare a widget’s rendered output against a stored “golden” screenshot file. expectLater(find.byType(MyWidget), matchesGoldenFile('golden/my_widget.png')). Advantages: catches visual regressions automatically, documents expected appearance, tests layout across sizes. Pitfalls: (1) Platform-dependent rendering — goldens generated on macOS won’t match CI Linux rendering. Fix: use alchemist or golden_toolkit packages with platform-independent rendering. (2) Font rendering differences. (3) High maintenance — any design change requires updating goldens. Best practice: use for stable, high-value components; avoid for frequently changing screens.

Strong answer: Flutter has multiple threads: (1) UI thread (Dart main isolate): runs Dart code, builds widget tree, generates layer tree. (2) Raster thread: takes layer tree, calls graphics API (Impeller/Skia), draws to GPU. (3) IO thread: loads assets, decodes images. Jank sources: (a) UI thread overloaded — heavy computations in build(), synchronous I/O. (b) Raster thread overloaded — complex clip paths, shader compilation (pre-Impeller), large image decoding. (c) GC pauses on UI thread. Profile each thread separately in DevTools — the frame chart shows UI thread and raster thread timelines independently.

Strong answer: Pipeline stages: (1) Static analysis: flutter analyze + custom lint rules (flutter_lints, very_good_analysis). (2) Tests: unit + widget + golden on every PR. (3) Integration tests on emulator matrix (different OS versions). (4) Build: flutter build apk --release and IPA. (5) Code signing: manage certificates/keystores in CI secrets. (6) Distribution: Firebase App Distribution for QA builds, Fastlane for App Store/Play Store submission. Tools: GitHub Actions (most common), Codemagic (Flutter-specific, easiest), Bitrise. Key: flavors/build types for dev/staging/production environments with different API endpoints and Firebase projects.

Strong answer: Flutter DevTools includes: (1) Widget Inspector — visualise widget tree, highlight rebuild areas, identify excessive rebuilds. (2) Performance — frame timeline, identify jank, per-frame CPU/raster thread costs. (3) CPU Profiler — call tree for CPU hotspots. (4) Memory — heap usage, object allocation, GC events, detect memory leaks (retained objects after navigation). (5) Network — HTTP traffic inspection. (6) Logging — structured app logs. (7) App Size tool — breakdown of binary size by library. In 2026, DevTools has improved Riverpod integration showing provider state live. Use profile mode (not debug) for accurate performance data.

Strong answer: Platform channels allow Dart code to communicate with native iOS (Swift/ObjC) and Android (Kotlin/Java) code. Three types: (1) MethodChannel: request/response — Dart calls a named method, native returns a result. Used for one-off operations. (2) EventChannel: native to Dart stream — for continuous data (sensor events, location updates). (3) BasicMessageChannel: bidirectional messaging with a codec. Messages are serialised using StandardMessageCodec (supports primitives, maps, lists). The Pigeon package generates type-safe channel code from a schema, eliminating stringly-typed channel calls.

Strong answer: Flutter Web (stable since 3.0): renders via CanvasKit (Skia/WASM — pixel-perfect but larger download) or HTML renderer (smaller, better for sext-heavy pages, less consistent). Limitations: SEO (content is canvas-rendered, not DOM), initial load size (CanvasKit WASM ~1.5MB), accessibility still maturing. Flutter Desktop (Windows/macOS/Linux stable): production-ready for internal/enterprise apps, plugin ecosystem smaller than mobile. Compose Multiplatform is a competitive alternative for teams preferring Kotlin. Key 2026 use case: Flutter for mobile with progressive web app (PWA) for a lightweight web presence of the same codebase.

Strong answer: Firebase Cloud Messaging (FCM) via firebase_messaging package. Key states: foreground (app open — FCM calls onMessage), background (app backgrounded — system shows notification), terminated (app closed — notification tap launches app with payload). Implementation: request permission, get FCM token, send to backend. Handle notification taps: use getInitialMessage() (terminated state) and onMessageOpenedApp stream (background). Local notifications via flutter_local_notifications for foreground display. Platform-specific: APNs certificate for iOS, proper notification channels for Android 8+.

Strong answer: Use in_app_purchase (official Flutter package supporting both App Store and Play Store). Flow: (1) Initialise and listen to purchaseStream. (2) Query available products. (3) Initiate purchase with buyNonConsumable or buyConsumable. (4) On purchase update: verify receipt server-side (never trust client-side verification). (5) Unlock content after server confirms. (6) Handle PurchaseStatus.restored for restoring previous purchases. Critical: always verify receipts on your server against Apple/Google APIs — client-only verification is exploitable. Handle pending purchases (payment processing delays).

Strong answer: KMP (Kotlin Multiplatform) shares business logic (networking, data models, repositories) across iOS and Android while keeping native UI. Compose Multiplatform extends this to share UI. The Flutter vs KMP+CMP question in 2026: Flutter offers a single codebase including UI but is a different paradigm from native. KMP+CMP allows native iOS/Android UI skills to apply, with Kotlin already familiar to Android devs, and increasingly preferred by companies with strong native iOS/Android teams who don’t want to learn Dart. Flutter has stronger tooling and a larger package ecosystem. The choice depends on team background and iOS UI requirements.

Strong answer: Key practices: (1) Secure storage: flutter_secure_storage uses iOS Keychain and Android Keystore — never store tokens in SharedPreferences. (2) Certificate pinning: dio with custom HttpClient and certificate verification. (3) Obfuscation: --obfuscate flag in release builds. (4) Root/jailbreak detection: flutter_jailbreak_detection. (5) Same no mobile screenshot: FLAG_SECURE on Android, privacy screenshot on iOS. (6) Biometric auth: local_auth package. (7) Network: enforce TLS, validate SSL certificates. (8) ProGuard/R8 rules to protect sensitive logic from reverse engineering on Android.

Strong answer: Architecture decisions: (1) Feature-first folder structure (not layer-first) — each feature contains its own UI, state, data, and domain code. Reduces merge conflicts. (2) Riverpod with code generation for state management — compile-safe, testable. (3) Freezed for all state/model classes. (4) GoRouter with ShellRoute for navigation — centralised route definitions. (5) Modularisation: separate Dart packages per feature domain, app package imports them. (6) Shared design system package: all components, colours, typography — design team owns it. (7) Very Good Analysis lint rules for consistency. (8) Melos for monorepo management. (9) CI: GitHub Actions, Codemagic for distribution. (10) Feature flags from Firebase Remote Config via Riverpod providers.