What we build with it
Swift is where our Flutter apps meet iOS properly. The cross-platform layer owns most of a product, but not the parts that live in the operating system: background execution, notification service extensions, keychain and biometrics, NFC, vendor SDKs shipped as native frameworks, and anything that has to appear outside the app itself.
That work is written in Swift behind a platform channel, so the Dart side sees a clean API and none of the iOS lifecycle detail. It is the exact counterpart of what Kotlin does on Android, and a platform integration usually means writing both.
Where it fits
Inside our Flutter projects rather than beside them, so it does not show up as its own portfolio entry. It appears wherever cross-platform code cannot reach — for example the App Clip half of the deferred deep linking work we have written about, which has no portable implementation.
Home-screen widgets, share extensions and SwiftUI surfaces are the other common case: they are separate targets that a Flutter engine does not run in.
When we recommend it
For the iOS half of a platform integration, and for a fully native iOS app when the product is genuinely platform-specific — deep OS integration, an Apple-only audience, or a team already invested there.
Not as the default for a product that also needs Android. Two native codebases means two teams, two release cycles and two sets of bugs; unless something forces it, Flutter with a Swift layer underneath gets you the same capability for considerably less.
