Lessons learned from crafting an in-house framework
summary
A custom Flutter framework with 200+ packages and a shared app template reduces per-app development time and cost by letting teams reuse UI, domain and data layers while keeping app-specific themes and pages. It moves from a slow monorepo to git submodules per package, publishes packages to a private package server, and relies on Freezed, Cubit, Fluttergen, multiply_result and Material widgets. Packages are layered (UI/domain/data), configurable via builder functions, CI integrates multiple repos, and components are field-tested on Play Store apps.
AI-written summary · about
chapters (13)
- 0:00Welcome
- 1:49Why we built it
- 3:15Inconsistent app development
- 6:04Framework goals and features
- 8:05Extractable components
- 11:23Flexible UI components
- 16:09Customizable UI screens
- 21:01Framework architecture layers
- 23:50Domain and data layer integration
- 30:42Managing 200+ packages
- 33:30Private package hosting
- 34:13Current improvements
- 35:59Final takeaways
related talks
30mAdding Flutter to your app - what are they not telling you?
09mFlutter for Enterprise: How your company should be building with Flutter at scale
30mFlutter at scale-experience from 25+ Flutter Devs working together on a mobile banking app
44mMultimodule Flutter App
32mBuilding Flutter apps in Lego style
37mTaming Legacy: Refactoring Patterns for Large Flutter Codebases
32m"Flutter: How we're building a UI framework for tomorrow at Google"
36mFlutter Add-to-App: The Good, the Bad and the Ugly