KMP & RN

Apple’s Ongoing Investment in Native Swift Tools

Rapid Evolution of Swift

Apple has made it clear that Swift and SwiftUI are the future of iOS development. With every new OS release, Apple continues to refine Swift, integrate it more deeply into the platform, and build new frameworks around it (e.g., Swift Structured Concurrency, SwiftData, etc.). By using KMP or React Native, you often miss out on the most up-to-date, tailor-made Apple tools.

Platform-Specific Innovation

Apple’s specialized frameworks (ARKit, Core ML, SwiftUI previews, SwiftData, etc.) are designed to work seamlessly on Apple hardware and software. Third-party abstractions (e.g., KMP or React Native) typically lag in adopting new Apple features, or may never support them fully, leading to a second-class experience.

Dependency on Third-Party Roadmaps

JetBrains/Google Influence

Kotlin Multiplatform is largely driven by JetBrains, with considerable input and usage from Google. Their roadmap is shaped by Android and Kotlin ecosystem priorities. Apple’s strategic direction (Vision Pro, new Swift frameworks, updates to SwiftUI) may not align closely with JetBrains’ or Google’s plans.

Uncertain Long-Term Support

While Kotlin Multiplatform is an official technology from JetBrains, Google’s actual support for KMP can fluctuate. Google has historically shown a willingness to pivot or discontinue projects when they’re no longer considered core to their strategy (e.g., Google dropping heavy investment in Flutter for certain platforms might signal future changes elsewhere). If you rely on KMP for iOS development, you’re placing a bet on Google/JetBrains continuing to prioritize iOS support—and prioritizing it at the same pace Apple evolves Swift.

Facebook’s Priorities

React Native is heavily influenced by Facebook’s business objectives. If Apple introduces new hardware or software features (like visionOS), React Native support can be slow, partial, or possibly non-existent if it doesn’t align with Facebook’s goals.

Missing Out on First-Class iOS Ecosystem Benefits

Swift Concurrency vs. Kotlin Flow/Channels

Apple’s native concurrency model (Swift Structured Concurrency) is tightly integrated with the platform’s runtime. Building concurrency into Swift, SwiftUI, and system frameworks ensures a deep level of optimization that may be impossible to replicate externally.

SwiftData vs. RoomDB

Apple’s new data persistence frameworks (like SwiftData) might end up deeply embedded into Xcode’s tooling, SwiftUI’s lifecycle, and Apple’s frameworks. By using KMP with something like RoomDB, you’re effectively grafting an Android-oriented stack on top of iOS—missing out on any “magic” Apple bakes into its native tools.

Better Documentation & Community Support

Apple invests heavily in developer documentation, WWDC sessions, and first-party sample code. SwiftUI, SwiftData, etc., have an entire iOS developer ecosystem around them, including Apple’s official docs and a vast community on Swift-based solutions. Cross-platform frameworks often have smaller communities specific to iOS integration, so it can be harder to find direct, up-to-date resources.

~~~

We interact with Apple Engineering and appreciate all the tools they are building for us ... and if we have a problem:

https://developer.apple.com/bug-reporting/

Alignment with Apple’s Vision

visionOS & Future Platforms

Apple is increasingly integrating iOS technologies with new device categories (Apple Watch, Apple TV, now Vision Pro). SwiftUI is the common cross-device UI layer. If you’re tied to a third-party solution, you might wait longer for reliable support of new Apple platforms—or never see it at all. If Facebook decides React Native for visionOS is not profitable, or if JetBrains and Google do not prioritize KMP for visionOS, you could be stuck waiting.

Tight Coupling of Software & Hardware

Apple creates both the hardware and the software. That ecosystem synergy often leads to specialized frameworks and APIs that only make sense if you are developing natively. Using KMP or React Native means layering on top of Apple’s ecosystem rather than integrating with it. When Apple updates the underlying OS, changes at the Swift/Obj‑C runtime level can quickly break cross-platform solutions or delay their updates.

Strategic & Business Considerations

Longevity and Stability

Apple has been developing and supporting iOS for over a decade, and there’s little reason to suspect it will stop. Their Swift-based frameworks (SwiftUI, Swift Concurrency, SwiftData) are core pillars of their long-term ecosystem strategy. Google, JetBrains, and Facebook all have their own strategic priorities, which may or may not align with supporting iOS at the level of Apple’s internal teams.

Risk of Vendor Lock-In (to Another Vendor)

While one aim of cross-platform tools is to avoid “lock-in” to a single platform, you might end up locked in to the roadmap and technology choices of a third party (Google/JetBrains, Facebook). Apple’s lock-in, conversely, is more or less guaranteed: iOS isn’t going anywhere, and its frameworks will continue to be supported and improved by Apple for the foreseeable future.

Competition & Platform Politics

Apple is known to protect its ecosystem vigorously, and third-party cross-platform frameworks sometimes bump into App Store policy issues or technical constraints. If relationships sour (e.g., Apple vs. Facebook), you could see new friction points when shipping cross-platform apps.

When (and Why) Cross-Platform Makes Sense

It’s important to note that cross-platform frameworks (KMP, React Native, Flutter, etc.) aren’t inherently bad. They solve important use cases:

Rapid Prototyping for MVPs: If you need to launch a proof-of-concept on multiple platforms quickly, a cross-platform solution can be pragmatic.
Teams with Single Language Expertise: Companies lacking dedicated iOS developers (or wanting smaller teams) might accept trade-offs for shared code and a unified language.
Non-Performance-Critical Apps: Where ultimate performance or deep platform integration isn’t required, cross-platform solutions might be “good enough.”

However, the argument here is that for serious, long-term iOS development, especially if you already know Swift and want to leverage Apple’s cutting-edge tools, relying heavily on a third-party approach can hinder you from taking advantage of Apple’s ongoing innovation and deep integration.

Conclusion

If you’re fully committed to building the best experience on iOS—and especially if you already have iOS knowledge—staying native with SwiftUI, Swift Concurrency, SwiftData, etc., can future-proof your application. You’ll be aligned with Apple’s roadmap, gain immediate access to new OS features, and avoid the risk that Google, JetBrains, or Facebook might reprioritize or drop support.

Cross-platform frameworks certainly have their place, but if you believe Apple is at the start of a big push with Swift-based technologies—and you value long-term, first-class iOS support—you might not want to bet your entire iOS development stack on Google, JetBrains, or Facebook. Instead, developing Android apps with Kotlin and iOS apps with Swift/SwiftUI can provide robust, future-proof applications on both platforms without the uncertainty of third-party dependencies.

Final Notes on Kotlin Multiplatform (KMP)

For Android Developers

Easier On-Ramp: KMP feels like a natural extension of existing Kotlin/Android know-how. You simply learn how to export Kotlin libraries to iOS and adopt minimal Swift “bridges.”

Less Overall Upskilling: You remain within a Kotlin-centric ecosystem; the additional work is primarily about iOS integration rather than learning a new language or large portions of iOS frameworks.

For iOS Developers

High Barrier to Entry: KMP requires diving deep into Kotlin, Gradle build scripts, coroutines, Kotlin Flow, etc. Even if you’re not building the Android UI, you still need enough Android/Kotlin ecosystem awareness to maintain or troubleshoot shared code.
Missed Apple Tooling: You’ll often bypass Apple’s latest frameworks (SwiftUI, Swift Concurrency, SwiftData) in favor of Kotlin-based equivalents—limiting access to first-party iOS innovations.

Why Not Just Go Fully Native?

If an iOS developer goes through the effort of learning Android development fundamentals—enough to feel comfortable handling KMP’s Kotlin-based shared code—one could argue they might as well just build the Android app natively in Kotlin, leveraging best practices (Jetpack Compose, Room, etc.), while continuing to build the iOS app fully in Swift.

In other words, if you’re spending so much time learning Android anyway, you’re effectively equipped to do native Android development. So why add the overhead and complexity of maintaining KMP?

This is the crux:

KMP’s Value: Reduces duplication of business logic across platforms.
Trade-Off: You inherit additional build complexity, must learn Kotlin + Android tooling, and miss out on Apple’s latest native frameworks.

If the benefit of shared code (KMP) is overshadowed by the cost of learning new ecosystems and the risk of missing first-party iOS features, it may be simpler—and possibly faster—to develop truly native on each platform.

Bottom Line: KMP can be appealing for Android-heavy teams wanting to dip into iOS with minimal Swift knowledge. But if you’re a dedicated iOS developer who also takes the time to learn Android, you might choose to build native on both platforms—avoiding KMP’s overhead while still leveraging the best each platform has to offer.

With GenAI we can build both the native iOS and Android app before most can figure out KMP Gradle ... LoL

Short Answer: Yes, generative AI (GenAI) can significantly speed up both Swift iOS and Kotlin Android development to the point where, for many projects, the advantage of code sharing via Kotlin Multiplatform (KMP) might feel less critical. If a key reason you’d choose KMP is to avoid writing the same “boilerplate” business logic in two languages, modern AI coding assistants can help generate much of that boilerplate or handle repetitive tasks in native Swift and Kotlin, reducing duplication overhead.

Page updated

Report abuse