What we build with it
There are iOS surfaces a Flutter engine simply does not run in, and SwiftUI is how we build them. Home-screen and lock-screen widgets, Live Activities, App Clips, share and notification extensions, watch apps — each is a separate target with its own process and its own UI, and each has to be written natively.
Declarative and state-driven, SwiftUI is conceptually close to Flutter, which matters in practice: an engineer moving between the two is thinking in the same shapes rather than relearning UIKit's imperative view controllers.
Where it fits
Around a Flutter app rather than instead of it, written in Swift and sharing data with the main app through an app group. The App Clip work we have written about is exactly this shape — a small native experience that launches without an install and hands off to the full app.
When we recommend it
For those extension targets, where there is no alternative, and for fully native iOS apps where the product is Apple-only.
Not for the main UI of a cross-platform product. Building the primary interface twice — SwiftUI on iOS and something else on Android — is the cost Flutter exists to remove, and doing both means every screen is designed, built, and fixed twice.
Worth knowing: SwiftUI still has gaps that send you back to UIKit for specific controls, and its behaviour changes meaningfully between iOS versions. It is mature enough to build on, not mature enough to assume.
