Flutter Cross-Platform Apps
Flutter is a good stack when shared branded UI across Android, iOS, desktop, and sometimes web matters more than fully platform-native feel.
The practical model is not “write once and ignore platforms”. The practical model is shared Dart and Flutter UI, plus explicit platform work for plugins, permissions, packaging, signing, store review, native APIs, accessibility, and release testing.
Default Recommendation
For Research Lab apps, start with Flutter when the app needs:
| Need | Flutter fit |
|---|---|
| Shared mobile UI | Strong, especially Android plus iOS |
| Branded desktop companion | Good when native platform depth is moderate |
| Web preview or app-like web target | Useful when SEO and smallest possible bundle are not primary |
| Heavy native APIs | Possible, but platform channels/plugins become core work |
| Fully native platform feel | Usually choose native Android/iOS instead |
Starter Stance
Start small:
- One Flutter app.
- One feature-first
lib/structure. - Local widget state for ephemeral UI.
- A simple app-state layer only when state crosses screens or must persist.
- Repository/service boundaries when data touches storage, network, or plugins.
- Target-platform smoke tests before claiming done.
Do not add Riverpod, Bloc, Drift, Firebase, custom plugins, flavors, or CI release automation until the app has a concrete reason.
Read First
- System overview - Flutter layers, runtime, engine, framework, widgets, and platform embedders.
- App architecture ladder - smallest maintainable app shape, then UI/data/repository/MVVM as complexity grows.
- Platform boundaries - when to use packages, plugins, platform channels, Pigeon, FFI, platform views, and web interop.
- Dart for Flutter - Dart concepts that directly affect Flutter code.
- Widgets and rendering - widget composition, stateful widgets, layout, keys, Material, and Cupertino.
- State management decisions - state scope first, package choice second.
- Quality gates - the minimum checks an agent must run before claiming done.
- AI agent guardrails - how agents should work safely in Flutter repos.
Contents
Architecture
Concepts
- Dart for Flutter
- Widgets and rendering
- State management decisions
- Platform support
- Packages, plugins, and pub
- Local data options
Quickstart
How-To
- Choose Flutter
- Add a package or plugin
- Call platform code
- Persist local data
- Test a Flutter app
- Release Android
- Release iOS
- Release desktop and web
- Profile performance
- Check accessibility
Deep Dives
- State management tradeoffs
- Local-first Flutter
- Platform channels and plugins
- Release surface area
- Performance and rendering
- AI agent guardrails
Walkthroughs
Troubleshooting
Notes
Minimum Done Criteria
A Flutter feature is not done until the target-platform evidence exists:
| Area | Proof |
|---|---|
| Static quality | flutter analyze, formatted Dart, no unexplained generated diffs |
| Unit/widget behavior | flutter test covers state, widgets, repositories, and edge cases |
| Platform integration | Plugin/platform channel paths tested on each target family used |
| Local data | Migration, backup/export, and restore paths tested before release |
| Accessibility | Labels, tap targets, contrast, scaling, and screen-reader smoke covered |
| Performance | Profile-mode or release-mode measurement on representative hardware |
| Release | Android/iOS/desktop/web build artifacts generated and smoke-tested |
Gotcha: Debug mode and hot reload prove developer iteration only. They do not prove release performance, store readiness, platform packaging, or native integration.