Founders often ask whether they should build their app twice, once for iOS in Swift and once for Android in Kotlin, or once in Flutter. I have shipped Flutter apps for staff management, site access control, marketplaces, games and internal tools, so here is my honest take.
What Flutter is good at
Flutter, Google's UI toolkit, compiles one Dart codebase to iOS, Android, web and desktop. For product teams that means:
- One codebase, one team. Features land on both platforms at the same time.
- Consistent UI. Flutter draws its own widgets, so designs look the same everywhere.
- Fast iteration. Hot reload makes UI work quick.
- Mature ecosystem. Firebase, maps, payments, push notifications and camera all have solid packages.
Where native still wins
- Apps built around AR, advanced camera pipelines or custom audio processing.
- Products that must adopt new OS features on day one (widgets, watch apps, new system APIs).
- Very small apps where an existing native team is already in place.
Even then, Flutter can call native code through platform channels, so a mostly-Flutter app with a few native modules is common.
Cost and timeline
| Flutter | Two native apps | |
|---|---|---|
| Codebases | 1 | 2 |
| Typical team | 1–2 developers | 2–4 developers |
| Feature parity | Built in | Needs coordination |
| Bug fixing | Once | Often twice |
For an MVP, one Flutter developer working with a backend developer, or one full-stack developer covering both, is usually enough.
Performance
For forms, lists, maps, charts and commerce flows, users cannot tell a well-built Flutter app from a native one. Performance problems usually come from heavy work on the UI thread or rebuilding too much of the widget tree, both fixable with standard practice.
App Store and Play Store review
Store review does not care what framework you used. It cares about content, privacy, payments and business model. One example from my own work: a staff-only app was rejected under App Store Guideline 3.2 because it was not meant for the general public. The fix was Apple's unlisted app distribution, not a rewrite. I wrote about that in a separate post.
My recommendation
Start with Flutter unless your core feature needs deep native hardware access. Put the business logic in a clean API (I usually use Laravel), keep the app thin, and you can always add native modules later.
Need an app on both stores? Send me your idea and I will tell you honestly whether Flutter fits.