· 5 min read Posted by Touchlab Engineering
Webinar Recap: iOS Development with Kotlin Multiplatform - Tips, Tricks, and Team Triumphs!
Successful implementation of KMP for native mobile requires a great iOS developer experience. Understanding how to publish Kotlin APIs that are Swift-friendly is a must, as well as setting up builds and tools that are optimized for Swift-side development. This Webinar covers the latest and greatest options for your native mobile dev team.
As a bonus, we’ve answered some of the questions asked during Q&A below
Speakers
Tadeas Kriz - Senior Kotlin Developer at Touchlab
Pamela Hill - Developer Advocate for Kotlin Multiplatform at JetBrains
Key Moments
- 1:41 Webinar Overview
- 5:03 Current State of Kotlin/Swift Interop
- 7:14 What is SKIE?
- 24:56 KMP-Native Coroutines or SKIE: Which is right for my project?
- 29:37 Helpful Resources
- 31:28 ATOM
- 33:00 Q&A
Q & A
Q: “Is KMMBridge staying free or will it be paid in the future?”
KMMBridge is free. Anything we currently publish as open source won’t be re-licensed.
We are a services business focused on helping teams employ KMP. KMMBridge is a core build tool, that can be adapted to specific environments through plugins. It ships with some common implementations, primarily for GitHub. If your team and CI are all on GitHub, and your builds are relatively simple, you should be able to use KMMBridge with the included implementations. However, production CI builds tend to get more complex and specific over time. For more complex builds, and for other CI and storage systems, you’ll likely need customization work. We offer that as a service, please reach out.
We may explore paid products at some time in the future, but we wouldn’t change licensing for anything we currently publish. We are very much committed to the open source work we do, and will continue that commitment in the future.
Q: “Can we use SKIE with Native Coroutines and can we get the benefits of both?”
You can use them together, although you shouldn’t try to use them both on the same function/class at the same time. So, say you wanted to export a Flow with KMP-NativeCoroutines, you should make sure SKIE is not also going to try to export the same Flow .
SKIE supports Flow and suspend functions, with cancellation, and from any thread. While you can use KMP-NativeCoroutines and SKIE together, SKIE should cover most use cases. If you feel like something is lacking, please reach out.
Q: “Is consuming KMP code as performant as native swift? / Are there any performance drawbacks to using the KMP shared code on the swift side?”
The summary:
- Kotlin/Native and Swift performance is reasonably comparable
- KMP is flexible. You can replace shared Kotlin code with Swift code if needed. This is one of KMP’s super powers, and the reason using KMP is low risk.
Accurately measuring performance is difficult, in part, because trivial comparisons aren’t realistic, and non-trivial comparisons are inherently biased. A simple answer is essentially not possible.
We have seen multiple attempts to measure Kotlin/Native performance, from well-respected teams. This data isn’t yet public, but we are working with them to encourage publishing these tests. No spoilers yet, but watch this space. The summary is that in real-world app tests, Kotlin/Native performance is reasonably comparable to Swift or OjbC, and certainly sufficient for the standard app logic needs presented in these tests.
For decision-makers evaluating KMP, risk should be top of mind. So while Kotlin/Native and Swift performance is generally comparable, it’s easy to imagine a case where you’d rather write some code in Swift directly. With KMP, you can simply implement that part in Swift. You wouldn’t need to rewrite all of your code or abandon KMP altogether. That is why adopting KMP is low-risk. You aren’t locked in.
Q: “What would be the best approach to introducing KMP to an existing project. Start with a shared KMP repo thats imported as a dependency into current android and iOS & later combine all 3 into monorepo?”
This depends on your team and application structure. Generally speaking, native mobile teams put KMP through a “trial” phase, and the apps are in different repos. Most teams start with publishing shared dependencies and just including them in the apps. This is why we built KMMBridge. If you want to try some KMP in your native apps right away, check out KMP Team Workflows with KMMBridge. We have a nice template project and various tutorials for getting started.
To expand KMP to share more code, you’ll eventually want to have everybody build Kotlin locally and commit to the same repo. That would generally mean moving code into a monorepo. However, that will present some development workflow challenges.
Check out Kotlin Multiplatform Mobile for Teams from KotlinConf for more info on how teams evaluate and adopt Kotlin. Also, this is an active and ongoing area of research for Touchlab. Keep an eye on our content feeds for updates.
Q: “What is the best way to debug kotlin code in iOS today? What is going to be the best way in the future and what is the roadmap? Fleet?”
“Best” is relative. If you like using Android Studio, you can run and debug your app from Android Studio and use the KMP plugin to debug. However, as it’s name would imply (”Android Studio”), developing iOS apps is not a core use case.
We publish the Xcode Kotlin Plugin. This plugin applies color formatting to Kotlin source in Xcode, and allows you to set breakpoints and debug Kotlin code. This is currently the solution most devs would use when actively iterating on their iOS app.
Fleet will be the best tool as it stabilizes. It allows you to debug Kotlin and Swift seamlessly alongside each other, as well as navigate between the two, which is something that none of the other tools can do. Also, Fleet will certainly provide a better dev experience than Xcode (no offense to Xcode fans). JetBrains is the industry leader in developer tooling. Expect excellent refactoring, code inspection, etc. We’re very excited to see KMP get a first-class tool!