Kotlin Multiplatform (KMP) moved from experimental to credible over 2025, with JetBrains pushing Compose Multiplatform for iOS and enterprise teams adopting at rising rates. Swift responded in 2026 with an official Android SDK preview, flipping the script on which language is the cross-platform option. This post is the honest 2026 comparison of KMP and native Swift for an indie iOS developer choosing a stack, including the real-world cost differences, where each one wins, and the specific workflows where the decision actually matters.
Short version: for indie iOS developers in 2026, native Swift remains the right answer in 9 out of 10 scenarios. KMP makes sense when you are building a cross-platform product where business logic sharing meaningfully reduces cost, you are comfortable in Kotlin, and you accept that Apple Intelligence and the newest iOS APIs lag behind native Swift by months. Swift 6.2 on Android closes the gap from the opposite direction for iOS-first teams wanting to enter Android.
What each option actually is in 2026
- Native Swift + SwiftUI. Apple's native stack. SwiftUI for UI, Swift concurrency model, full Apple Intelligence access, all new APIs on day one. You build the app twice if you want Android (though Swift 6.2 Android SDK preview changes this).
- Kotlin Multiplatform (KMP). JetBrains' stack for sharing Kotlin logic across iOS, Android, web, desktop, and server. You can use native SwiftUI for iOS UI and KMP for shared business logic. 30-50 percent code sharing is typical.
- Compose Multiplatform. KMP plus JetBrains' Compose for iOS UI, which means you write your entire app in Kotlin and Compose, and it runs on iOS. You can hit 70-90 percent code sharing but give up native UI feel.
This post focuses on the KMP-plus-native-SwiftUI variant because that is what indie iOS developers actually consider. The pure Compose Multiplatform path is rare for iOS-first indies and usually loses to Flutter anyway.
The 2026 scorecard
| Dimension | Native Swift + SwiftUI | KMP + native SwiftUI UI |
|---|---|---|
| Day-1 Apple API access | Yes, always | Lags 2-6 months for non-core APIs |
| Apple Intelligence / Foundation Models | Full, native | iOS side only via Swift interop |
| WidgetKit, App Intents, ActivityKit | Full native | Full on iOS, not shared |
| Code sharing across iOS + Android | Platform-specific bridges only | 30-50% business logic typically |
| Build tool complexity | Xcode + SPM | Xcode + Gradle + KMP plugin |
| Learning curve for iOS-native dev | Already paid | Moderate (new Kotlin, new Gradle) |
| Binary size overhead | None (baseline) | 3-6 MB Kotlin runtime |
| iOS performance | Maximum (native) | Near-native for logic, UI identical if SwiftUI |
| Compile time | Fast (SPM native) | Slower (Gradle + native binary compilation) |
| AI-coding (Xcode 26.3 agentic) | First-class | Mixed (KMP-specific tools less mature) |
| Indie boilerplate availability | Mature (The Swift Kit, etc.) | Limited for KMP-specific indie kits |
The plot twist: Swift on Android in 2026
Swift 6.2 shipped an official Android SDK preview in early 2026, supported by the Swift Android Workgroup. This changes the decision calculus significantly because the historical argument for KMP was "you already have a Kotlin backend, share it with mobile." The new counter-argument is "you already have Swift on iOS, extend it to Android."
What the Swift Android SDK actually provides as of April 2026:
- Swift standard library works on Android. You can run Swift code, including Foundation, on Android with the workgroup's official toolchain.
- No native UI framework yet. SwiftUI does not render on Android. You need Jetpack Compose for UI.
- Good for business logic sharing. The same Swift models, repositories, and algorithms that power your iOS app compile to Android targets.
- Binary size overhead roughly 4-8 MB. Similar order of magnitude to KMP.
- Build integration is experimental. Gradle plugin works but is less polished than KMP's tooling. Expect rough edges through late 2026.
For an iOS-first indie developer considering Android, Swift on Android now competes directly with KMP for "share the logic" use cases.
When KMP wins
KMP is the correct choice in these specific scenarios:
- You have an Android app first. If your Android codebase is already Kotlin, KMP is the shortest path to iOS without rewriting everything in Swift.
- Your backend is Kotlin. Sharing data models, validation, and business logic between backend and mobile matters enough to justify the tooling complexity.
- Large team with dedicated Android devs. 3+ engineers, half Android-native, building a cross-platform product.
- Business logic is genuinely cross-platform. Parsing, sync, offline queues, complex calculations. These are worth sharing. Not UI, not platform-integration code.
- You value deterministic cross-platform behavior. Same Kotlin code runs everywhere. Great for finance, crypto, or regulated industries.
When native Swift wins (the majority case for indies)
Native Swift + SwiftUI is the right default for indie iOS developers. Specifically when:
- You are iOS-first or iOS-only. Most indie apps ship iOS first and consider Android later (or never). No need to pay KMP overhead for code you will not share.
- You use Apple Intelligence heavily. Foundation Models, ImagePlayground, Image Wand, Genmoji, Writing Tools. These are native Swift APIs. KMP cannot help here.
- Your app uses a lot of platform-specific iOS APIs. HealthKit, WidgetKit, ActivityKit, App Intents, StoreKit 2, Apple Maps. All native. KMP bridges these but the overhead rarely justifies sharing.
- You use Xcode 26.3 agentic coding. Native Swift projects get first-class agent support. KMP projects get partial support with rough edges at the Kotlin boundary.
- You are a solo developer or 1-2 person team. The tooling overhead of KMP (Gradle, Kotlin, Android Studio for some tasks) is not worth it at this team size. Stick with one ecosystem.
- You use an indie boilerplate like The Swift Kit. Native iOS boilerplates are mature and ship everything you need. KMP boilerplates are rarer and less polished.
Cost of ownership comparison
Real-world cost math for a solo indie building a mid-complexity app from scratch, targeting iOS first then Android a year later.
| Phase | Native Swift, iOS first then Android rewrite | KMP from day one (iOS SwiftUI + Android Compose) |
|---|---|---|
| iOS-only MVP (0-3 months) | 400-500 hours | 600-800 hours (KMP setup + dual build) |
| iOS polish to v1.0 (3-6 months) | 200-300 hours | 300-400 hours (KMP drag) |
| Add Android (months 7-12) | 300-400 hours (rewrite in Swift on Android + Kotlin UI) | 150-250 hours (UI-only, logic reused) |
| First year total | 900-1200 hours | 1050-1450 hours |
| Ongoing (year 2+) | Slightly higher (two stacks) | Slightly lower (shared logic) |
The break-even for KMP is roughly month 18 if you ship both platforms actively. For indies who might never add Android (the majority), native Swift saves 100-200 hours of overhead for nothing.
Hiring and talent pool
Indie devs sometimes outsource or collaborate. Talent availability matters.
- Swift + SwiftUI freelancers in 2026: Plentiful. Upwork, Toptal, Contra all have hundreds of qualified contractors at $40-120/hr.
- KMP + SwiftUI freelancers: Rare. Most KMP devs are employed by larger companies. Expect $60-150/hr and longer search times.
- Pure Compose Multiplatform freelancers: Very rare. Mostly JetBrains ecosystem enthusiasts. Niche talent.
Apple Intelligence as the tiebreaker
For indie iOS apps in 2026, Apple Intelligence is probably the most-important new capability to ship. Foundation Models, Writing Tools, ImagePlayground, Genmoji, Image Wand, and smart app integrations are all native-Swift-first. KMP cannot call Foundation Models directly; you expose it through Swift interop which adds boilerplate per integration.
If your app has any natural place for AI features (summaries, categorization, smart input), native Swift is the clear choice in 2026. The pace of Apple Intelligence improvement over the next 12 months will likely widen this gap further.
Performance: real benchmarks
| Test | Native Swift | KMP (iOS via Swift-KMP bridge) |
|---|---|---|
| App cold start | baseline (~400 ms) | +50-100 ms (Kotlin runtime load) |
| JSON parsing (10K items) | baseline (Codable) | +10-20% (kotlinx.serialization bridge) |
| Database ops (SQLite, 1K rows) | baseline (SwiftData or GRDB) | Comparable (SQLDelight has similar perf) |
| UI scrolling (1K-item list) | baseline | Identical (SwiftUI on both paths) |
| Binary size | ~18-25 MB typical indie app | +3-6 MB Kotlin runtime |
Performance is close enough that most users cannot tell the difference. KMP is noticeably slower only on cold start and in bridging-heavy scenarios. For the vast majority of apps, performance is not the deciding factor.
Decision tree
- Solo indie, iOS-only or iOS-first: Native Swift + SwiftUI. No question.
- Solo indie, iOS + Android from day one, simple shared logic: Native Swift + SwiftUI for iOS, separate Android Kotlin app. Share via shared backend API instead of shared mobile code. Simplest overall.
- Solo indie, iOS + Android, complex shared logic (offline sync, financial calc):Native Swift for iOS, consider Swift-on-Android SDK preview for Android. Or KMP if you prefer Kotlin.
- Two-person team, existing Android app, adding iOS: KMP is the fastest path.
- 3+ engineers, cross-platform product priority, existing Kotlin stack: KMP wins, possibly Compose Multiplatform for UI too.
What The Swift Kit ships
The Swift Kit is a native SwiftUI boilerplate targeting the scenario where native Swift wins (most indie apps). It ships with the full 2026 Apple stack wired (Foundation Models, App Intents, StoreKit 2, RevenueCat, Superwall, SwiftData) and assumes you stay native on iOS. If you later add Android, the clean architecture makes a separate Android app or a KMP migration both achievable.
$99 one-time, unlimited commercial projects. See every integration on the features page or jump to pricing.
Final recommendation
For indie iOS developers in 2026, stay native unless you have a specific reason to adopt KMP. That specific reason is usually an existing Kotlin codebase or a team decision around cross-platform business logic. Without one of those, native Swift plus SwiftUI is faster to ship, easier to hire for, deeper in Apple Intelligence access, and better supported by Xcode 26.3 agentic coding. The Swift on Android SDK is the plot twist to watch in 2026; if it matures through 2027, the case for KMP weakens further.