target 01 · ios
AOT native ARM compile. Impeller renderer default. Cupertino widgets for platform-idiomatic UI.
§
§ · flutter development
Flutter, one language, five targets.
One Dart codebase ships to iOS, Android, web, Windows, macOS, Linux, and embedded systems. Identical UI on every platform. Impeller renderer. No JavaScript bridge.
On this page
§ 01 · one language, five targets
Flutter compiles one Dart codebase to five runtimes.
Flutter's core idea is simple: draw every pixel yourself instead of bridging to native widgets. The upside is pixel-identical UI on every platform. One codebase compiles to iOS, Android, web, Windows, macOS, Linux, and embedded targets without compromise.
The trade-off is larger binary size and fewer platform-native affordances. If "one UI everywhere" matters more than perfect native feel, Flutter wins.
in short
- One Dart codebase compiles to iOS, Android, web, Windows, macOS, Linux, Impeller renderer draws every pixel directly.
- State stack: Riverpod + freezed for new builds; BLoC for enterprise; Provider only on legacy migrations.
- Native integrations via Platform Channels (MethodChannel/EventChannel); well-maintained pub.dev packages cover most cases.
- Performance target: 60 FPS at rest on mid-tier Android, < 16ms frame budget verified against Flutter perf docs.
- Four engagement shapes: 2-week audit (refundable), new build, React Native → Flutter migration, retainer. Client owns code and infra.
target 02 · android
AOT native ARM + x64. Material 3 default. Impeller opt-in.
target 03 · web
Dart → JS or WASM. CanvasKit for pixel parity, HTML renderer for lighter output. Right for internal tools.
target 04 · desktop
macOS, Windows, Linux stable. Native windowing, menus, file system.
target 05 · embedded
ARM Linux, automotive, kiosk via Flutter Embedder. Specialist territory.
§ 02 · the widget bloom
One tree. Five runtimes.
One Flutter widget tree renders identically on every platform. Flutter owns the rendering layer, not the OS. Watch how Dart compiles to each of the five targets.
§ 03 · flutter vs react native
Two good frameworks. Two different teams.
This choice is never about right or wrong. It's about team fit. Flutter wins when you need pixel-identical UI across iOS, Android, web, and desktop from one codebase. React Native wins when your team already writes React and wants to share components across platforms.
| dimension | Flutter | React Native |
|---|---|---|
| rendering | Impeller (Flutter owns pixels) | bridges to native widgets |
| UI parity across platforms | pixel-identical | native-feeling on each |
| target platforms | iOS, Android, web, desktop, embedded | iOS, Android (web/desktop via 3rd party) |
| language | Dart | TypeScript |
| binary size | larger (ships renderer) | smaller |
| OTA updates | not official; via Shorebird | EAS Update first-class |
| best for | multi-platform, UI-consistent, Dart teams | React teams, mobile-first, OTA velocity |
§ 04 · state management
Riverpod first. BLoC for enterprise.
Flutter's state story has stabilized. For new builds, we pick Riverpod plus freezed for immutable data. Use BLoC for enterprise teams that want explicit event-driven architecture. Provider works for legacy migrations only. We skip GetX in production.
default · riverpod
Type-safe, testable, composable.
Successor to Provider by the same author. Compile-time dependency resolution. Family providers for parameterized state. AsyncValue for async data with loading/error states.
enterprise · bloc
Explicit events + states.
Event-driven architecture. Separation of business logic from UI. Heavier boilerplate, stronger discipline. Right pick for large teams valuing explicitness over terseness.
legacy · provider
Predecessor to Riverpod.
Acceptable for small apps or ongoing maintenance of Provider codebases. New builds should prefer Riverpod; the conceptual leap is small and the type safety is better.
§ 05 · platform channels
Dart calls Swift and Kotlin. Two-way.
When Flutter needs native APIs like CoreBluetooth, HealthKit, or Android Keystore, it uses Platform Channels. MethodChannel handles one-off calls. EventChannel streams native events back to Dart. Most common integrations have solid pub.dev packages ready to use. For custom needs, we write a Flutter plugin with Swift and Kotlin code, exposed to Dart through a channel.
tier 01
Use a maintained pub.dev plugin (camera, location, biometrics, push).
tier 02
Write a custom plugin with Swift + Kotlin when the need is unique.
tier 03
FFI for direct C/C++ interop when performance or a native library is required.
§ 06 · performance SLA
Impeller and 60 FPS at rest.
Performance targets are verified on real devices: mid-tier Android (Pixel 6a-class) and iPhone 12. Not on an engineer's M3 MacBook. The targets below come from the Flutter performance docs.
| metric | target | notes |
|---|---|---|
| cold start | < 2.0s | mid-tier Android, AOT build |
| frame rate | 60 fps | Impeller renderer, sustained |
| release APK size | < 20 MB | ABI split enabled |
| crash-free | > 99.6% | Firebase Crashlytics, 30-day |
Two archetypes. One multi-platform, one mobile-first.
These archetypes are from real fintech and consumer DTC engagements. One ships iOS, Android, and web from one codebase. The other is mobile-first with deep native channel integration. Each pattern shows the kind of Flutter work we typically deliver.
archetype 01 · fintech brand
iOS + Android + web from one codebase.
Consumer fintech on iOS, Android, and a progressive web app for account access from any browser. Riverpod, freezed, Firebase Auth, Plaid integration via platform channels. 18 weeks to production on all three targets.
targets
3
one codebase
code shared
94%
across targets
rating
4.8
App Store
archetype 02 · logistics operator
Driver app with offline + barcode.
Driver companion app for a logistics company. Offline route lists, barcode scanning via custom Flutter plugin, signature capture, photo upload queue. BLoC for state. 14 weeks.
drivers
1,200
daily active
cold start
1.6s
Android p75
offline hrs
8
before sync
§ 08 · engagement + fit
Four shapes. Audit names the right one.
We offer four engagement shapes to match your team's needs and timeline. The readiness audit names which fits your project best.
shape 01
Readiness audit.
2 weeks. Platform fit, state reco, channel surface. Refundable.
shape 02
MVP.
10-16 weeks. iOS + Android + store submit.
shape 03
Production build.
14-22 weeks. Platform channels, offline, IAP, CI/CD.
shape 04
Multi-platform.
16-26 weeks. Mobile + web + desktop from one codebase.
right fit
- ●You need to ship beyond mobile: web, desktop, embedded.
- ●Pixel-identical UI across platforms is your requirement.
- ●Your team knows Dart or prefers object-oriented typing.
wrong fit
- ×Public content web site. SEO-critical. Flutter Web is the wrong choice.
- ×Your team builds React. React Native fits better.
- ×OTA JS-update velocity is critical. RN and EAS are first-class there.
Eight answers.
Questions Flutter teams ask before booking an audit. When Flutter beats React Native. State management choices. Native channels. Performance targets. Code ownership and exit strategy.
Flutter vs React Native - which should we pick?
Flutter wins when you ship beyond mobile (web, desktop, embedded) from one codebase. You want pixel-identical UI across iOS and Android. Flutter draws every pixel itself with no bridge to native widgets. Your team knows or prefers Dart and strong typing.
React Native wins when your team is already deep in React and TypeScript. Your app is mobile-only and OTA update velocity matters most. The JavaScript library ecosystem is more important to you than Flutter widgets.
Neither is wrong. Both are excellent frameworks for different team shapes and priorities.
How much does a Flutter app cost in 2026?
Senior Flutter engineers in the US and UK run $135 to $190 per hour. Indian senior engineers run $80 to $130 per hour.
A Flutter MVP (Material 3, Cupertino, 15-25 screens, auth, push, store submission) takes 10 to 16 weeks. A production build with platform channels, offline sync, IAP, and CI/CD takes 14 to 22 weeks. A multi-platform build spanning mobile, web, and desktop takes 16 to 26 weeks.
A 2-week audit is refundable. Get a scoped quote in 48 hours.
Is Flutter good for web apps?
Yes, for internal tools, dashboards, and PWAs paired with mobile. Flutter Web via CanvasKit gives pixel-identical UI to mobile. Perfect when the experience must match across all platforms.
No, for public content sites that are SEO-critical or sensitive to load speed. The bundle is large and SEO support is limited. Our rule: Flutter Web fits internal and authenticated experiences. It's wrong for public marketing or content surfaces.
Riverpod, BLoC, or Provider - which state management?
Riverpod for most new builds. It's the successor to Provider by the same author, with stronger type safety and compile-time dependency resolution. BLoC works for teams that prefer explicit event-driven architecture, especially in large enterprise apps. Provider is acceptable for smaller apps or older Flutter codebases already using it. We skip GetX in production.
The right default for new Flutter projects in 2026 is Riverpod plus freezed for immutable data.
How do you handle native platform-specific code?
Via platform channels. Flutter's MethodChannel and EventChannel let Dart call Swift or Kotlin. For common needs like camera, location, push, and biometrics, we use solid pub.dev packages that wrap the native APIs.
For custom needs, we write a Flutter plugin with Swift for iOS and Kotlin for Android, exposed to Dart through a channel. The plugin lives in a separate package for reuse. Most Flutter apps need 2 to 5 custom native integrations, all wrapped in plugins.
Material 3 or Cupertino - do we pick one?
Usually not. Material 3 is the primary design system for Android with dynamic color and modern affordances. Cupertino widgets appear on iOS for native-feeling nav bars, action sheets, and sliders.
Most of the app (buttons, inputs, layout) uses a shared design system that works on both platforms. We build on top of Material 3 with your brand tokens, then override with Cupertino only where iOS users expect platform-specific interaction patterns.
What's CI/CD look like for Flutter?
Three solid options. Codemagic is Flutter-native with first-class iOS and Android builds, App Store and Play Store submission, and Flutter-specific testing. Fastlane with GitHub Actions or GitLab CI works for teams already on those platforms. Bitrise is more configurable for teams needing custom mobile pipelines.
We pick based on your existing workflow. All three work well. Signed builds happen in CI. No manual Xcode exports in 2026.
Who owns the code and credentials on exit?
You do. Private GitHub repository under your organization. Apple Developer Program and Google Play Console under your legal entity. Signing certificates in your keychain and keystore. We keep encrypted backups for CI, but you own the originals.
Push notifications, analytics, and crash reporting all run under your billing. DH engineers are named collaborators, removable anytime. On exit: repository transferred, credentials rotated, documentation handed off, plus 30-day support tail.
Start with a readiness audit.
Two weeks to assess platform fit, state management strategy, native channel needs, and store readiness. Fully refundable. Get a scoped quote in 48 hours.
related services
More from Oliver.
Senior Account Director · UK · London · 3 posts on the site
Published · Last updated .
