We talk with lots of teams piloting KMP for their native mobile development. One common story we hear is of Android devs trying to pitch KMP to their iOS colleagues. Although the technical details of the approach change over time, the basics remain the same. Start with empathy. Simply put, as an Android developer, how would you react if the web team came and said we should all try React Native?
We had the pleasure of working with our friends at JetBrains to develop this guide on recommended approaches to pitching KMP. This is a great resource to start with:
The iOS dev ex has improved considerably over the years. We, Touchlab, have published a number of these tools and have a solid understanding of this part of the stack.
Our flagship iOS dev ex tool. It runs in the Kotlin compiler, to significantly improve the API produced for Swift. The output is much more Swift-friendly, and helps retain a lot of the type safety built into modern Kotlin features.
By default, Kotlin Multiplatform tools are designed for “local build”. Everybody builds the Kotlin source locally. This works great in some cases, but can be terrible in others. KMMBridge is a set of Gradle support tools that packages and publishes Xcode Frameworks that can be directly included. No Kotlin compilation necessary.
KMMBridge Use Cases:
- Piloting KMP. Want to introduce a Kotlin module but the iOS team is skeptical? Publishing a binary allows easy, no-risk integration, to prove out the tech.
- Larger teams and projects. Any larger dev team will start separating their code into modules. Shared Kotlin code is no different. Forcing all team members to build Kotlin from source disrupts this pattern. KMMBridge allows teams to better modularize their shared Kotlin.
- External SDK. For teams that need to publish client SDKs, KMMBridge is the perfect solution.
KMMBridge also has a basic, but fucntional, local SPM dev flow.
An Xcode plugin that allows the Kotlin source to be debugged in Xcode. Also supports source code highlighting.