Flutter or Swift? Questions That Decide Your First App
By Mudabbir Hasan, Co-founder · Published · Last updated
Choose Swift if the app is iOS-only, depends on Apple-specific features such as ARKit, HealthKit or watchOS, or must last many years. Choose Flutter if you need iOS and Android in the first release from one team. Settle it by answering five questions in order, then prove the riskiest feature in your chosen stack within two weeks, before you commit the whole budget.
Why do most Flutter vs Swift guides leave you where you started?
Most comparisons list pros and cons for each side and end with "it depends". They are also mostly written by agencies that sell Swift or Flutter work, which is worth knowing when you read their numbers. The useful parts are the conditions each one attaches to its advice. This guide collects those conditions into an order you can follow, so the answer for your product falls out of your own situation.
Do you need Android in the first release?
Start here, because it changes the most. If the first version must run on both iOS and Android with one team, a cross-platform framework such as Flutter is the usual starting point. If the first version is iOS-only, StudioKrew says there is no cost saving from going cross-platform, and Volpis notes you take on Dart skills and setup for nothing. Even for two platforms, StudioKrew puts the realistic saving at 25 to 35 percent. That is their own estimate, from a company that sells Swift services, so treat it as a rough guide and not a quote.
Five questions, in this order
- 1
Android in the first release?
Yes: Flutter is the usual start. iOS-only: no saving.
- 2
Core depends on Apple-only features?
ARKit, HealthKit, Live Activities, watchOS, Keychain: Swift.
- 3
Can native code fill the gaps?
Platform channels can, with limits.
- 4
How long must the app live?
Long life, or native-heavy features within 12 to 18 months: reconsider Flutter.
- 5
Do size or startup speed matter?
Usually less than expected. Measure a prototype.
Does the core of the product depend on Apple-only features?
Both guides list the same triggers for going native: deep hardware use such as Bluetooth, ARKit and Core Location, HealthKit, Live Activities, Apple Watch and visionOS companions, and security-critical features that lean on Keychain, Secure Enclave or biometrics. Volpis says to choose Swift when performance, hardware, security or a long lifespan matter. StudioKrew adds that new Apple APIs reach Swift on day one, while Flutter has to wait for a plugin. It claims that wait typically takes three to twelve months and gives Live Activities as an example. That claim rests on the authors' own experience, so check the current state of any API you depend on before you choose.
Where each one fits
Swift
- An iOS-only product
- Apple-only features such as ARKit, HealthKit, watchOS
- Security-critical features
- A long-lived app
Flutter
- iOS and Android in the first release
- One team for both platforms
- Data-driven, standard app screens
- A custom, brand-led interface
Can native code fill the gaps if Flutter lacks something?
Often, yes. Flutter's documentation describes platform channels, which let a Flutter app send messages to native Swift code on iOS and Kotlin or Java on Android and get a result back. Three limits from the same page matter when you plan for them:
- Channel calls must be made on the platform's main thread, so heavy native work needs its own handling.
- The basic channel API is not type safe: both sides must agree on argument names and types, which the Pigeon package can generate for you.
- Each native gap you fill is code you maintain twice, once per platform.
So the choice is not one-way, but each gap you fill with native code erodes the saving that made Flutter attractive. A handful of small gaps is normal. A product whose main feature is a gap is a Swift product.
How long does the app need to live, and will you need native-heavy features later?
Volpis warns that a budget cross-platform build can end in a partial or full rewrite, and says to reconsider Flutter if you suspect native-heavy features within 12 to 18 months. It also says that over a multi-year life the native versus cross-platform maths can flip, and that the often-quoted two-times saving assumes your app maps cleanly onto Flutter's strengths. A short-lived validation MVP and a flagship app you will maintain for years are different decisions.
Does app size or startup speed matter to your users?
Usually less than people expect. StudioKrew reports observed shell sizes of about 8 to 18 MB for Swift and about 18 to 33 MB for Flutter, from its own production builds, and says the gap is minor next to a typical asset load and should not drive the decision. Treat these as observations, not benchmarks. If your product is graphics-heavy or sensitive to launch time, measure a prototype on a real device and ignore the published averages.
What should you test before you commit the budget?
The failure these guides describe is finding out late that a core feature needs native work. A cheap defence is to build the single riskiest feature first, in the stack you are leaning towards, on a real device, within two weeks. The riskiest feature is the one with the most platform-specific behaviour: Bluetooth pairing, background location, a custom animation, an on-device model.
- Write down the three features users will judge the app on.
- Pick the one that depends most on the operating system.
- Build only that feature, in the stack you favour, and run it on a real iPhone and, if relevant, a real Android phone.
- If it needs more than a small native module, switch your decision to Swift before the rest of the budget is spent.
The two-week test
- 1
Write down the three features users will judge
- 2
Pick the one that depends most on the operating system
- 3
Build only that, in your favoured stack, on a real device
- 4
Needs more than a small native module? Switch to Swift.
Which stack have we shipped?
We have shipped both. RaceToFreedom and Rumor are native Swift iOS apps. AI Maker Pro runs on iOS and Android from a single Flutter codebase, and the Tooting Fish & Kebab ordering app is built in Flutter. The case pages record what we built, not the reasoning behind each stack, so they are a record of the work and not an argument for either side.
See the Flutter build: AI Maker Pro
If you are still undecided after the five questions, a short technical discovery is the cheapest place to settle it, because the riskiest-feature test above is exactly the kind of question it exists to answer.
Sources
- Swift vs Flutter: which is better for your iOS app in 2026?, Volpis (accessed 2026-10-10)
- Swift vs React Native vs Flutter for iOS in 2026, StudioKrew (accessed 2026-10-10)
- Writing custom platform-specific code (platform channels), Flutter documentation (accessed 2026-10-10)
Related guides
Talk to an engineer about your project
Start with a free project call. We learn what you are building and recommend the right next step, with no pitch.
Book a call