Skip to content

Level 4 · Master Production

Goal: run Flutter like a professional — understand the pipeline well enough to reason about performance, structure an app so a team can change it for years, and get it built, tested, configured and shipped.

Three ideas carry this level:

  1. Measure, then change. Count rebuilds, layouts and paints; profile on devices; keep the numbers in tests so fixes don't rot.
  2. Boundaries are what make change cheap. Layers with inward dependencies, a single composition root, and tests that enforce the rules.
  3. Shipping is a pipeline, not an event. Formatting, analysis, tests, configuration, signing and upgrades — automated and repeated, small and often.

Modules

  1. The Rendering Pipeline & RenderObjects — a custom RenderBox, and which changes trigger layout vs paint
  2. Performance: Rebuilds, Jank & DevTools — profile mode, measured fixes, and a list-building myth corrected
  3. App Architecture: Layers & Dependency Injection — feature-first layers, a composition root, an architecture test
  4. Configuration, Flavors & --dart-define — validated compile-time config, native flavors, secrets
  5. CI for Flutter — a local CI script, a real first run that failed, and a GitHub Actions workflow
  6. Building & Publishing to the Stores — versioning, signing keys, App Bundles, TestFlight, privacy declarations
  7. Flutter on the Web & Desktop — JS vs Wasm builds measured, tests in Chrome, dart:io pitfalls, desktop expectations
  8. Plugins & dart:ffi — plugin anatomy, federated plugins, and C called from Dart for real
  9. Upgrades, Dependencies & Long-Lived Apps — pub outdated, dart fix, SDK pinning, an upgrade routine
  10. Capstone — A Production-Ready Expense Tracker — every layer, optimistic updates with rollback, undo, a11y, goldens, 15 tests

What you need before starting

How the examples were checked

Run with Flutter 3.44.8 / Dart 3.12.2. The CI script, web builds (JavaScript and Wasm), flutter test --platform chrome, keytool, dart fix, pub outdated and the C library for FFI (built with the system clang) were all run, and their output is shown. Timings and file sizes are from one machine and one app.

What wasn't run

Android, iOS and desktop builds, store uploads, profile-mode DevTools sessions and the GitHub Actions workflow were not run: on the course machine Android builds were blocked by unaccepted SDK licenses, Xcode wasn't installed, and no store accounts were used. Those parts are described from the documented process, are labelled in each lesson, and should be verified against current official documentation before you rely on them.