Shared mobile UI
iOS and Android from one widget tree, with layouts that survive the screens you named in the brief.
Cross-platform UI
Flutter and Dart when one interface should look the same on every device, because you drew it.
Flutter renders its own UI. That is the reason to choose it: a brand-controlled interface that does not change personality between iOS and Android, and that can extend to desktop when the product should. Dart is the language of the widgets, the state, and most of the client logic.
Platform channels cover the rest — a camera API, a payment sheet, a file the engine should not pretend to own. We keep those channels small and named, so a platform upgrade is a localized fix.
Flutter & Dart
iOS and Android from one widget tree, with layouts that survive the screens you named in the brief.
macOS, Windows, or Linux builds when the same interface should leave the phone.
Motion, type, and density defined by the product, not by this year’s system theme.
A narrow bridge into Swift or Kotlin for the device APIs Flutter should not reimplement.
Clients for the service you already run, including the offline and error states the UI has to show.
Release builds, icons, and the store metadata that has to match the binary.
Delivery
Fit
Neighbors
These are the switches we recommend in scoping, not a disclaimer.
The rest of the company is TypeScript and you want to stay there.
Each platform should use its own UI kit and conventions.
The desktop app should use the system web view and a Rust core, not Flutter’s renderer.
Continue
Flutter & Dart is a starting point. Bring the constraint that matters more.
Tell us what you are building, what already exists, and which surface matters first. We will reply with a point of view.