Cross-Platform Choice for iOS Developers: The 2026 Decision

If you're facing the cross-platform choice as an iOS developer in 2026, you're not actually looking for a single framework — you're looking for a decision framework. Flutter 3.47, React Native 0.87, Compose Multiplatform 1.12.0, Skip, and Capacitor are all active and maintained as of September 2026; there's no single "best" answer — it depends on your team size, budget, and how much SwiftUI knowledge you want to carry over. Instead of walking through the five options one by one, this article reduces the decision to five questions and shows which answer leads where.

💡 Pro Tip: Make the framework choice by asking "who will maintain this codebase three years from now" rather than "which one is faster" — most wrong choices come not from the first week's speed but from the third year's maintenance burden.

Table of Contents

• The Decision Actually Comes Down to 5 Questions
• The Option Map: Five Paths, Five Different Philosophies
• Flutter 3.47
• React Native 0.87 + Expo
• Compose Multiplatform (Kotlin Multiplatform)
• Skip: From Swift to Android
• Capacitor: Bring Your Web Skills to a Native Shell
• Reference: Where Does .NET MAUI Stand?
• The Portability of Your SwiftUI Knowledge
• Team of 1 or Team of 5? Deciding by Scale
• Hiring and Handoff Cost (Turkish Market)
• 3-Year Maintenance Cost and the Version-Upgrade Tax
• The Exit Cost of a Wrong Choice
• Decision Table and Quick-Decision Box
• FAQ
• Which cross-platform framework should an iOS developer choose?
• Which framework is fastest to learn for someone who knows SwiftUI?
• Can one developer sustain two platforms alone?
• How does team size change the framework choice?
• Which framework produces the fewest mandatory migrations?
• Where is the hiring pool wider between frameworks?
• Conclusion
• Sources

The Decision Actually Comes Down to 5 Questions

The cross-platform debate usually starts with "which framework performs better," but that question leads you the wrong way. As of September 2026, Flutter, React Native, Compose Multiplatform, Skip, and Capacitor can all deliver production-quality render performance; the gap is no longer raw speed, it's what kind of relationship your team will have with this codebase. To sharpen your decision, ask yourself these five questions:

• How many people are on my team, and who will write the code? If you're a solo iOS developer, the priority is different than for a mixed 5-person team.
• How much of my SwiftUI knowledge do I want to carry over? Just the syntax, or the framework itself?
• How many years will this project live? The right choice for a 6-month MVP isn't the same as for a 3-year product.
• Where is my hiring pool deepest? In the Turkish market, which technology makes it easier to find developers?
• What's my exit cost if I choose wrong? How painful would it be to leave this framework?

The sections below unpack each question and bring them together in a single decision table at the end.

The Option Map: Five Paths, Five Different Philosophies

Before moving to the decision table, let's clarify where the five options stand as of September 2026. Each was designed on a different assumption — without knowing that difference, no decision table makes sense.

Flutter 3.47

Flutter 3.47 was released on August 12, 2026, according to flutter.dev's official announcement. This release is titled "Modular by design" — the material_ui and cupertino_ui packages have now reached standalone 1.0 on pub.dev, meaning design systems can be updated on their own weekly cadence, independent of the core SDK. The Impeller rendering engine became the default on desktop, and Flutter Widget Previews moved to the stable channel. Flutter's philosophy is clear: use its own widget tree and its own rendering engine to deliver a single visual language independent of the platform.

React Native 0.87 + Expo

React Native 0.87 was released on August 11, 2026, according to the official announcement on reactnative.dev's blog. The biggest change in this release is that the Strict TypeScript API is now the default — it was an opt-in preview in 0.80, and became the mandatory default in 0.87 (opt-out stays available only until 0.88). The minimum toolchain was also raised: Node.js 22, AGP 9, Kotlin 2.0+.

On iOS, the notable development is experimental Swift Package Manager support — a step toward reducing the CocoaPods dependency, particularly meaningful for an iOS developer. The Metro bundler was updated from 0.84 to 0.87, and source map generation got faster. React Native's philosophy is the opposite of Flutter's: instead of its own widget tree, it drives the platform's native components through a JavaScript/TypeScript bridge.

Compose Multiplatform (Kotlin Multiplatform)

Compose Multiplatform 1.12.0 was released in August 2026, according to JetBrains' official GitHub release record. The standout feature is the MCP server support added for Compose Hot Reload — an AI-agent integration that lets an agent interact with a running Compose app in real time. There's also a breaking change: the deprecation level of the NativeCanvas and NativePaint typealiases was raised to ERROR, meaning projects that still use this old API now fail at compile time. Compose Multiplatform's philosophy is to extend Jetpack Compose's state-hoisting model beyond Android, to iOS and desktop.

Skip: From Swift to Android

Skip comes from a different direction than the other four: it carries Swift code to Android, not the other way around. Per the skiptools/skip GitHub release list, the latest tag is 1.9.11, released September 19, 2026 — actively updated weekly, but still on the 1.x line, meaning post-1.0 maturation. It isn't yet comparable in maturity to Flutter, React Native, or Compose Multiplatform's production scale. It's more honest to see Skip not as a "general cross-platform option" but as "a niche path for teams extending a SwiftUI-written iOS app to Android."

Capacitor: Bring Your Web Skills to a Native Shell

Capacitor's stable line, per npm, is 8.5.2. The major 9 line is still alpha — 9.0.0-alpha.7 shipped September 18, 2026, per the ionic-team/capacitor GitHub record. So, as of September 2026, the current recommendation for production is the 8.5.x line. Capacitor works on an assumption entirely different from Flutter/RN/Compose Multiplatform: it writes the mobile UI with web technologies (HTML/CSS/JS) instead of native, wrapped in a thin native shell. For an iOS developer, it's the least "native-feeling" option, but the cheapest entry for companies that already have a web team.

Reference: Where Does .NET MAUI Stand?

One more name we didn't include in the decision table but that comes up often in comparisons: .NET MAUI. Per the dotnet/maui GitHub release list, the current tag is 10.0.110 — a GA maintenance release, not a release candidate; MAUI 10 went stable months ago and now gets regular patches. This article leaves MAUI out of the main five because the C#/.NET ecosystem already carries a different hiring and toolchain assumption — but for teams with a .NET background, it's a stable option worth not overlooking.

The Portability of Your SwiftUI Knowledge

This is one of the questions most iOS developers skip, yet it affects the decision most: how much of my SwiftUI knowledge survives the move to cross-platform? swift.org's "What's new in Swift: August 2026 Edition" post (September 4, 2026) shows the Swift language and toolchain expanding beyond Apple platforms: Swift on Windows is maturing through its first year, Embedded Swift now reaches microcontrollers (like the Raspberry Pi Pico), and community projects like ElementaryUI are pushing Swift toward WebAssembly and the browser. But that expansion carries the Swift language, not the SwiftUI framework itself.

The realistic answer: the SwiftUI framework is still locked to Apple platforms. You can't use it directly in a React Native, Flutter, or Compose Multiplatform project. What carries over is your syntax habits and declarative way of thinking — concepts like @State, one-way data flow, and a declarative view tree find near one-to-one counterparts in Jetpack Compose and Compose Multiplatform, which is why a SwiftUI developer usually gets comfortable reading Compose within weeks. That bridge is weaker in React Native and Flutter: React Native relies on JSX + hooks, Flutter on its own widget tree and the StatefulWidget/StatelessWidget split — both learnable, but SwiftUI reflexes won't directly apply.

1# To verify which versions the project you have actually runs on,
2# always check the source before picking a framework, not a blog post
3flutter --version
4npx react-native --version
5cat package.json | grep '"react-native"'

Team of 1 or Team of 5? Deciding by Scale

Team size affects the framework choice far more than technical features do — because each framework's "maintenance tax" lands with a different weight depending on team size.

If you're working solo, your priority should be low churn: you have limited time to relearn a new major version's APIs. Flutter's material_ui/cupertino_ui packages becoming SDK-independent is an advantage here — the original design libraries inside the core SDK are scheduled for formal deprecation in the Fall stable release in November 2026, so you're not immediately forced onto a mandatory migration timeline, but note the date.

On a mixed 5-person team (iOS + Android + web backgrounds), the situation reverses: large, deliberate ecosystem-wide breaking changes like React Native 0.87's mandatory Strict TypeScript API can be absorbed in parallel — while some take on the migration, others keep shipping features. On a small team, the same change can halt feature work for weeks.

Hiring and Handoff Cost (Turkish Market)

A clear caveat: this research found no verified, up-to-date source on framework-specific hiring rates or salary data for the Turkish market — so no numbers here, just the structural facts that will shape your decision.

• The JavaScript/TypeScript pool is wide, but React Native experience isn't evenly distributed. Finding a web developer in Turkey is easy, but finding a developer who can "debug React Native + native modules" requires a separate skill set; ask about this as a distinct criterion when hiring.
• Flutter/Dart is a single-purpose specialty. You won't use Dart anywhere else, so the person you hire is likely someone who specifically invested in Flutter — both a plus (focused expertise) and a minus (a narrow pool).
• Compose Multiplatform is the natural extension of an Android/Kotlin team. If you already have an Android team writing Kotlin, moving to Compose Multiplatform is the lowest-friction path in terms of handoff cost — the existing team isn't learning a new language, just adding a new target platform.
• Skip and Capacitor remain niche. Both have small but active communities; this means you need to ask "how many people know this technology" more carefully when hiring.

The practical question in terms of handoff cost is: if you leave this project, how fast will your replacement understand the codebase? An iOS/Android developer familiar with a native-feeling architecture (Compose Multiplatform, partly Skip) generally adapts faster; adapting to a web-first architecture (React Native, Capacitor) largely depends on the developer's JS/TS background.

3-Year Maintenance Cost and the Version-Upgrade Tax

What I mean by "version-upgrade tax" is this: every framework forces you into a mandatory migration at certain intervals, and the size of that migration varies a lot by framework. Let's compare three examples with concrete sources:

• React Native 0.87 made the Strict TypeScript API the default — existing projects need to fix their type errors, and the opt-out only stays available until 0.88, meaning this is a temporary reprieve, not a permanent escape route.
• Compose Multiplatform 1.12.0 raised the deprecation level of the NativeCanvas/NativePaint typealiases to ERROR — projects using these APIs no longer compile; the upgrade isn't optional anymore, it's mandatory.
• Capacitor made the mandatory UIScene transition for iOS 27/Xcode 27 manageable with a single command, npx cap migrate; existing apps already on the App Store aren't affected by this transition, but new builds must make it.

All three examples show that no framework promises "keep running forever without an upgrade." The difference is how often the upgrade comes, and how painful it is.

1// In Compose Multiplatform 1.12.0, the deprecation level of
2// NativeCanvas/NativePaint typealiases was raised to ERROR.
3// This line no longer compiles in older projects:
4// val canvas: NativeCanvas = ...
5// Migrating to the platform-specific Skia-based API is now mandatory.

The Exit Cost of a Wrong Choice

What happens if you realize 18 months in that you picked the wrong framework? It's one of the least-asked but most expensive questions at decision time.

• Leaving Flutter: you have to rewrite the Dart codebase from scratch — shareable business logic (state management, the data layer) is conceptually portable, but the code itself doesn't carry over line by line.
• Leaving React Native: some of the TypeScript business logic (API layer, validation, state management) may be reusable on the web or backend side, but the UI layer gets fully rewritten as it moves to native.
• Leaving Compose Multiplatform: if you already have the Kotlin/Android side, moving the iOS side to SwiftUI looks less like "starting from scratch" and more like "removing the shared layer and expanding the platform-specific one" — a relatively more controlled exit.
• Leaving Capacitor: moving the web layer to native requires the biggest rewrite, because the UI was never native to begin with.
• Leaving Skip: if you're already writing Swift/SwiftUI, the iOS side stays fixed, and you only lose the Android target — the exit cost here is the lowest of all, because your main codebase was already native Swift.

General rule: the higher the share of shared code, the higher the exit cost. The hidden bill for the "write everything in one codebase" promise comes due when you want to leave that one codebase.

Decision Table and Quick-Decision Box

Let's bring the five questions above together in one table. Version and date information was verified against primary sources as of September 2026.

The version table doesn't answer "what should I use" — only "where do they currently stand." To make the decision concrete, you can give each of the five questions a weighted score from 0-10 and run a simple comparison. The example below sets the weights to team size 30%, delivery speed 25%, SwiftUI fit 20%, budget 25%, and compares two options — you should rerun this calculation with your own team's scores:

1// Simple weighted decision score — rerun with your own scores
2const weights = { team: 0.3, timeline: 0.25, swiftuiFit: 0.2, budget: 0.25 };
3 
4const flutter = { team: 8, timeline: 7, swiftuiFit: 5, budget: 8 };
5const reactNative = { team: 7, timeline: 8, swiftuiFit: 4, budget: 7 };
6 
7function score(option) {
8  return (
9    option.team * weights.team +
10    option.timeline * weights.timeline +
11    option.swiftuiFit * weights.swiftuiFit +
12    option.budget * weights.budget
13  );
14}
15 
16console.log("Flutter:", score(flutter)); // 7.15
17console.log("React Native:", score(reactNative)); // 6.65

Here, the Flutter score is 0.3*8 + 0.25*7 + 0.2*5 + 0.25*8 = 7.15, and React Native comes out to 0.3*7 + 0.25*8 + 0.2*4 + 0.25*7 = 6.65 — specific to this example profile, and likely different for your team. What matters isn't the result, it's the method: weight each criterion, then compare.

Quick-decision box:

• You're solo, deeply invested in SwiftUI, short-term MVP: try Compose Multiplatform — the conceptual bridge is shortest, though there's still a learning curve on the iOS side.
• You have a web/React background, you need a wide hiring pool: React Native + Expo, especially with the type safety brought by the Strict TypeScript API.
• You already have an Android/Kotlin team, and want to add iOS to the same team: Compose Multiplatform is the clear favorite.
• You want to extend a SwiftUI-written iOS app to Android, and iOS will remain the main platform: consider Skip, but keep its 1.x maturity level in mind.
• You already have a web/PWA and mobile is just putting that web experience in a shell: Capacitor 8.5.x, but don't expect "native feel."

FAQ

Which cross-platform framework should an iOS developer choose?

There's no single right answer; the choice depends on team size, budget, and your UI goal. Those who want an experience conceptually close to SwiftUI can evaluate Compose Multiplatform's evolving architecture; those who want access to a wide JS/TS ecosystem should consider React Native 0.87's Strict TypeScript API; those who prioritize a single codebase across web+desktop+mobile should look at Flutter 3.47. For teams with a .NET background, the MAUI 10 GA line is also a stable reference point.

Which framework is fastest to learn for someone who knows SwiftUI?

The conceptually closest bridge is Compose Multiplatform: composable functions and the state-hoisting model are considered close to SwiftUI's @State and declarative view tree. But this doesn't mean "the same framework," just a shorter learning curve — you still need to learn the framework's own APIs (Compose's layout system, the Kotlin language itself).

Can one developer sustain two platforms alone?

Technically yes — a single-codebase framework reduces the need for platform-specific code. But "sustainable" also has to account for breaking-change cadence: migrations like React Native 0.87's deliberate ecosystem-wide breaking changes, or Capacitor's mandatory UIScene transition for iOS 27/Xcode 27, can halt feature work for weeks on a one-person team. A low-churn option (Flutter's design packages becoming SDK-independent, for example) carries less risk for a solo developer.

How does team size change the framework choice?

Larger teams can absorb large breaking-change waves in parallel — while one person takes on the migration, others keep shipping features. On smaller teams, the same migration can stall the whole team for weeks. That's why small teams may prioritize low-churn options more, while larger teams can give more weight to ecosystem size (ease of hiring).

Which framework produces the fewest mandatory migrations?

There's no fixed answer, because every framework's migration schedule depends on its own release cycle. The examples we've seen as of September 2026 (React Native's mandatory Strict TypeScript API, Compose Multiplatform's NativeCanvas/NativePaint deprecation, Capacitor's UIScene transition) all show mandatory migrations arrive regularly for every one of them — don't choose expecting a "migration-free framework"; compare how often migrations come and how well they're documented instead.

Where is the hiring pool wider between frameworks?

This research found no verified data specific to hiring in the Turkish market. The general structural observation: the JavaScript/TypeScript developer pool is wide, but React Native-specific native-module experience is a separate criterion; Dart/Flutter expertise is a narrow but focused pool; Compose Multiplatform may not need a separate hiring process since it's the natural extension of existing Kotlin/Android teams.

Conclusion

The cross-platform decision in 2026 still isn't just "which one is fastest" — it's an equation combining your team size, how much SwiftUI knowledge you want to carry over, the project's lifespan, and your exit cost from a wrong choice. This article brought together five questions, five current options (Flutter 3.47, React Native 0.87, Compose Multiplatform 1.12.0, Skip 1.9.11, Capacitor 8.5.x), and a decision table — but the final call is still specific to your team.

To dig deeper: Flutter vs SwiftUI: A 3-Year, 60K LOC Production Comparison walks through a long-term production experience line by line, and Flutter 3.47: Migrating to the material_ui and cupertino_ui Packages covers the latest release changes. For Compose Multiplatform in production, see Compose Multiplatform: Android + iOS Production Deployment 2026 and Kotlin Multiplatform 1.1 Stable: Production Case Study 2026; for React Native's latest architecture and build process, see React Native New Architecture 2026: Fabric, TurboModules, and Bridgeless Mode and Expo SDK 52 EAS Build: Production Workflow and 2026 Deployment Guide.

Sources

• Flutter 3.47 announcement — material_ui/cupertino_ui reaching standalone 1.0, Impeller, and Widget Previews.
• React Native 0.87 announcement — the Strict TypeScript API becoming the default, and minimum toolchain changes.
• Compose Multiplatform 1.12.0 announcement — Compose Hot Reload MCP support.
• Compose Multiplatform 1.12.0 GitHub release notes — raising the NativeCanvas/NativePaint deprecation level to ERROR.
• Capacitor 8.5 announcement — released July 31, 2026, mandatory UIScene transition for iOS 27/Xcode 27, and the npx cap migrate command.
• Skip GitHub release list — version tag 1.9.11, released September 19, 2026.
• .NET MAUI 10.0.110 GitHub release notes — GA maintenance release, September 2026.
• Swift.org: What's new in Swift, August 2026 Edition — the cross-platform expansion of the Swift language and toolchain.