What Nobody Told Us About Shipping Kotlin to iOS | Suhyeon (Leah) Kim

[00:00:00]Guten Tag.

[00:00:02]Sorry, my friends told me not to do it, but it was it will brace the crowd and Thank you so much. Thank you.

[00:00:12]Hello everyone. My name is C Young Kim and the title of today's talk is what nobody told us about shipping Kotlin to iOS. And by the end, hopefully you'll know.

[00:00:24]First a little about me. I've been doing Android for about 7 years and Kotlin multi-platform for the last two. I met Woowa Brothers. We make Baedal Minjok, which is a Korea's largest food delivery app, part of Delivery Hero.

[00:00:39]Recently, I moved into a technical advocate role, which means I now spend most of my time running our developer training program, organizing hackathons, and putting together internal tech conferences. Which also means if I want to code at work, I have to give up work-life balance. But my manager is here in the audience, so let's skip the long story. I'm I'm also a community organizer for GDG Korea Android and I flew 19 hours to from Seoul to Munich. So, if I start speaking Korean halfway through, please just nod. I'll get back to you eventually.

[00:01:20]Before we start, let me tell you who this talk is for. I'm an Android developer, so when I first opened an iOS project on KMP, I had no idea which parts of the docs actually mattered and which ones I could ignore.

[00:01:34]We're not here to walk through the docs.

[00:01:36]They're good, but what they don't show is what actually breaks after you ship.

[00:01:41]So, that's what this is. What we built in 2 months, what we fought over a year of maintenance, and the things we wish we had known before we got started. So, we've been shipping KMP to iOS for years. Some of this might already be familiar to you, but I think you'll still find the binary level debugging part interesting.

[00:02:01]And if you have better ideas, and I know you probably will, please come find me after. I generally love to hear them.

[00:02:09]So, here's where we all started.

[00:02:12]Deliveroo Hero Brand cares about the internal tech course to train the and hire new developers, and we needed an app to manage those trainees.

[00:02:21]Both Android and iOS.

[00:02:23]And the team There were three Android developers. We had to ship in two months, no iOS developer, and our backend developer also writes Kotlin.

[00:02:33]At that point, though, Universe was basically holding up a sign that said, "Just use KMP." So, yeah, we didn't really choose Compose Multiplatform, it chose us.

[00:02:44]And fast forward to today, the app has been in production for about a year. Uh 100% Compose UI, cheers Compose Multiplatform, and across the whole code base, 98.2% Kotlin. The other 1.8% is Swift, half of it written by me in tears, and the other half written by cloud code.

[00:03:05]Also probably in tears.

[00:03:07]And Compose Multiplatform 1.80 shipped in just about exactly a year ago, and that release promoted iOS to stable.

[00:03:16]And the timing worked out for us. On the App Store side, we have never been rejected for using CMP. Kotlin Native is ahead-of-time compiled into native binary, so as far as App Store review is concerned, it goes through the same path as Swift or Objective-C app.

[00:03:31]The one thing to keep in mind is privacy manifest for your third-party SDKs, but that's an Apple requirement for any iOS app, not something CMP introduces.

[00:03:40]Uh now, the app works well on production, but the interesting part isn't what worked, it's what broke. And everything broke at the same place, the boundary between Swift and Kotlin.

[00:03:52]And here's what we are covering today.

[00:03:54]Three case studies. The first is native state observation. The pattern we use to bridge native events into shared Compose UI. The second is integrating non-KMP SDKs. Building around Firebase took us something unexpected about how Kotlin native singletons work on iOS.

[00:04:12]The third is dependency management.

[00:04:14]Going from CocoaPods today to the new Swift PM import in Kotlin 2.40.

[00:04:19]Along the way, I'll share an interop people's cheat sheet and what Japanese engineers told me when I brought our architecture to them at last year's KotlinConf.

[00:04:30]Now, let's start with the case study one, native state observation. This is the fundamental pattern to bridge platform specific changes to shared Kotlin logic.

[00:04:41]Let's start easy. I want you to picture something, just for a second.

[00:04:46]A push notification arrives on user's iPhone. They tap it. Your app opens and now your shared Compose UI needs to do something. Show a dialogue, refresh refresh some state. Pretty common case.

[00:05:00]So, how would you do it do that in CMP where the Compose UI is 100% shared?

[00:05:07]If you're thinking I just write an expect function in common main, the notification doesn't originate in common main. It originates in iOS in a delegate callback on a thread Kotlin doesn't control with a payload that is an NS dictionary, not a map. And that brings us to three typical cases where expect actual fall.

[00:05:29]First, native UI events. Things like push notifications. The notification arrives in your iOS app's notification center. Native code receives it, but the logic that handles it is in your shared module.

[00:05:42]Second, async platform logic. Things that return through callbacks on whatever thread the platform feels like.

[00:05:49]Your common main code just can't await those.

[00:05:52]And third, native system APIs that have no KMP equivalent at all.

[00:05:59]To make it concrete, these are the real iOS APIs you'd likely hit on any production app. Notification Center, Location Manager, Firebase Remote Config, App Delegate Lifecycle, Bluetooth, Audio, etc. All of these events happen on the iOS side, but the logic that needs to respond to it lives in Kotlin.

[00:06:17]Today's first case study uses one of those, Remote Config, to drive a force update flow. So, let's look at that.

[00:06:26]Um this was the actual requirement one from production. When the server sets a minimum version via Firebase Remote Config, users on older versions should see a dialogue and be unable to use the app.

[00:06:39]The key challenge is that the Remote Config event originates in Swift code, but Compose UI that shows the dialogue lived in the shared Kotlin code.

[00:06:50]Here is the module structure of our app.

[00:06:53]The iOS app contains ContentView.swift.

[00:06:56]Uh Compose app has Android main, common main, and iOS main. And below that, the shared module with domain logic, which shares with server code.

[00:07:07]The important thing to notice it that is that our UI is 100% Compose. The entire UI lives in common main. There's no Swift UI mixed in. So, any native event that needs to affect the UI must flow through the Kotlin layer.

[00:07:23]And this is the core question. Can events from the iOS module, specifically from ContentView.swift, be received in the Kotlin module?

[00:07:32]The answer is yes, but you need a bridge pattern.

[00:07:36]We are developers, so let's uh skip the long story and dive into the code.

[00:07:41]This is what the default setup looks like in default KMP structure.

[00:07:47]A simple main view controller function that returns a compose UI view controller.

[00:07:51]Swift calls it, gets a UI view controller, and that was it. And we need to change this.

[00:07:58]Here's our solution. We created a shared view controllers object that holds a mutable state flow of state view state.

[00:08:06]The main view controller function creates a compose UI view controller that collects from the state flow. When the state state flow updates, compose recomposes automatically.

[00:08:17]Take a look at update required app version code, and this is what Swift will call. It updates the state flow, which triggers recomposition, and which shows the force update dialog. State flow serves as a single source of truth for the UI state.

[00:08:33]Main view controller is the entry point.

[00:08:35]It's the function Swift calls to get UI view controller it can drop into the iOS app.

[00:08:40]This is how Kotlin hands a screen across the boundary.

[00:08:44]Now, to keep that screen alive alive and reactive, we use collect as state with life cycle, which subscribes to a state flow and turns its emissions into a compose state.

[00:08:55]So, whenever the flow emits, the UI recomposes with the latest value, and that's the whole trick. Anything on the native side of force update dialog, a feature flag, a remote config change just needs to push a new value into that flow, and the compose UI recomposes itself.

[00:09:13]And for the Swift side, ContentView.swift imports compose app and creates a compose view. It calls main view controller to get the compose powered UI view controller. And it has an update required app version code function that calls back into the Kotlin.

[00:09:29]Notice it's calling shared view controllers, the Kotlin singleton exposed to Swift. You might I wonder why do we hold state in a Kotlin object instead of per screen view model?

[00:09:40]Because force update it's wide state not a per screen state. For per screen view models, the cleaner pattern is to hold the Kotlin view model inside Swift UI's coordinator. That gives you a proper life cycle and instance isolation. We didn't need that here, but it's worth knowing.

[00:09:59]And this is where Firebase remote config gets patched. In the callback, we extract the required app version code, convert it into int 64, not int value.

[00:10:08]I'll explain why later in the pitfall section, and then call update required app version code.

[00:10:14]That updates the state flow, compose recomposes, force force update dialog appears.

[00:10:21]Let me connect the flow visually because we started easily.

[00:10:25]Step one, remote config triggers in the iOS layer.

[00:10:29]Step two, the data flows into the compose apps iOS main where the state flow gets updated.

[00:10:35]Step three, compose UI recomposes based on the new state. Native SDK does its thing, calls a Kotlin function, state flow updates, compose recomposes. The key The key point across all of this work is that we didn't touch app.kt in common main.

[00:10:51]We kept the dependency direction intact while simply trickling the exposure of compose UI.

[00:10:58]In fact, with this dependency structure, it might have been simpler to implement if we weren't using declarative UI approach.

[00:11:05]We know that this could have been done more easier and if we had just implemented a dialog with Swift UI, but we wanted to take the advantage of 100% compose UI.

[00:11:16]So, that was case study one. Hopefully, a decent warm up. And because the second case starts as a straightforward non-KMP SDK integration story, but it turns into the deepest rabbit hole we went down on this project.

[00:11:31]This is a simple module structure for logging in our app.

[00:11:35]The logger module defines a log object in common main with platform specific implementations in Android main and iOS main. The compose app modules base view model just references this log directory.

[00:11:48]Now, yes, we could have wrapped it in a proper DI library like Koin, but we wanted to start with the lightest possible structure and just see if it worked.

[00:11:58]On the JVM, this works exactly as you'd expected. One log instance shared across modules, accessed wherever you need it.

[00:12:07]But the moment we shift this into iOS, something strange started to happen.

[00:12:13]Here is the actual code. In common main, we define an expect object log with functions for error, debug, and info logging.

[00:12:22]In Android main, we use Android's native log, and in iOS main, we use NS log.

[00:12:27]This works fine for basic logging, but we needed to integrate the internal crash reporting tool for a better view.

[00:12:35]And this is the timing for the second case study. We needed to implement Firebase Crashlytics. On Android side, this is easy. Just add the Gradle dependency, import it directly in Android main. Done.

[00:12:46]But on iOS, the Firebase SDK is Swift and Objective-C. You can't import it into iOS main directly. Kotlin native simply cannot access it.

[00:12:56]So, we needed a bridge, and that's exactly why we hit the wall on the next slide. This isn't just about the Firebase problem. You'll hit this with any iOS SDK that doesn't have a KMP support. Analytics, payment payment services, push notification libraries.

[00:13:14]The first approach we had was the inversion of control. In the logger module's iOS main, we define a Crashlytics delegate interface. The iOS app provides the actual implementation using the real Firebase Crashlytics iOS SDK.

[00:13:29]The log on module doesn't know about Firebase. It only knows about the interface.

[00:13:34]It's a clean dependency inversion.

[00:13:39]And let's just skip the last slide again and dive into the code.

[00:13:43]Step one, we define a simple interface Firebase Crashlytics delegate in our logger module's iOS main.

[00:13:51]And the iOS log object holds a nullable reference to this delegate with an init Crashlytics delegate function to receive it.

[00:14:00]I know a nullable delegate sitting on a singleton makes some of you nervous, but we'll come back to whether this was a good idea.

[00:14:09]And for the step two, in the iOS app, we create a default Firebase Crashlytics delegate that implements the Kotlin interface and calls the real Firebase Crashlytics SDK. And this is the bridge.

[00:14:21]Kotlin interface on the one side, native SDK on the other.

[00:14:27]Note that even though we declared NSError on Kotlin side, Swift shows it as any error. And that's Apple's automatic NSError to error bridging. The compiler handles the conversion both ways and we'll come back to this on the cheat sheet at the end.

[00:14:43]And finally, in app delegate, when the app launches, we configure Firebase and inject the delegate into the Kotlin singleton.

[00:14:53]Two quick things to point out in this Swift code before they trip you up later.

[00:14:59]First, log.shared in Kotlin, uh log is just an object, but when the Kotlin compiler exports that object to Objective-C, it generates a shared property to access the singleton instance. So, whenever you see that shared in our Swift code, that's how you reach our Kotlin object.

[00:15:18]Second, that do prefix on do we need Crashlytics delegate? The original Kotlin function we created was just any Crashlytics delegate.

[00:15:27]In Objective-C, methods that start with init are treated as initializers, constructor constructors, basically.

[00:15:36]That's a convention ARC depends on for memory management. So, when a Kotlin function name starts with init, there's a risk Objective-C reads it as an initializer when it's not.

[00:15:48]To avoid that ambiguity, the Kotlin native compiler renames it with a do prefix when generating the Objective-C header, and there's a small set of automatic mappings, also.

[00:16:00]So, we just implemented the clean textbook dependency injection, also possible with the ITI libraries like Koin, and it worked perfectly before it didn't.

[00:16:12]But, in production, the logger we just implemented silently did nothing.

[00:16:17]And debugging this took longer than my flight to Munich. We added logging. The delegate was definitely being injected.

[00:16:24]We could see the log in the app delegate, but when the view model tried to use it, the delegate was als- always null, every single time.

[00:16:32]I spent a full day thinking it was a timing issue.

[00:16:36]Let me walk you through our misdiagnosis.

[00:16:39]First, we thought it was a threading issue, added dispatch queue.main.async.

[00:16:44]It was still null.

[00:16:46]Then, the initialization order. Maybe the view model loads with or a delegate finishes, added delays, check the life cycle, injection happens first, and it was still null.

[00:16:59]Then, I thought ARC was releasing the delegate, made it a strong property, still null.

[00:17:05]At this point, I started questioning my career choices, and what made it worse was Xcode stack traces for Kotlin code are nearly useless for this kind of problem. When Kotlin native code is involved, Xcode shows you shows you KFun prefix mangled symbols.

[00:17:25]You can't tell which module or which function it came from at a glance. So, we were doing binary search debugging with the NS log statements anywhere.

[00:17:35]And what we get and what we figured was that we were debugging the whole wrong dimension. The answer was something we never even considered.

[00:17:45]I ran NM on terminal, uh Unix's symbol dump tool on logger framework, and that's our log class.

[00:17:53]And then the same query on composeapp.framework.

[00:17:57]It would be a same class name, but different address, 20 megabytes away.

[00:18:04]These are the symbol addresses, static layout inside the binary. Two different addresses means two different class definition got compiled in.

[00:18:12]But, strictly speaking, this is not the direct proof that two singleton instance exist at runtime.

[00:18:19]What is the direct proof, at least at the symbol level, is this.

[00:18:26]Yeah, this. We ran NM one more time looking for Objective-C bridge symbols in ComposeApp, but no result printed out.

[00:18:34]And that means that ComposeApp's log existed in the binary, but Swift has no way to walk into it. Swift could only see logger's log, and meanwhile, Kotlin code inside ComposeApp was happily using its own internal log with different instance.

[00:18:50]We also ran the runtime application to print hash code of the two instance, and it, as expected, two different hash codes printed out.

[00:19:00]And this is the part where we need to dive into what's under the hood.

[00:19:04]Kotlin's object is a singleton per compiled binary, not per iOS process.

[00:19:10]When two KMP module as separate xcframework files, each get its own static global for every single tone. And this is by design. It's how native binary linking works, but if you come from the JVM world where a single tone is a single tone across the whole JVM, this is a complete surprise. Hence, the title of this talk.

[00:19:32]I show you the I showed you the symbol table not because every Kotlin developer needs to know NN, but when something fails silently across modules and your usual tool says nothing wrong, just remember that this layer exists.

[00:19:47]For the immediate fix is brute force.

[00:19:50]Move everything into one module, one xcframework, one single tone, and the problem would be gone. But we have to get up give up modularity, of course.

[00:20:00]And build time started creeping up. For a small app, this is fine, but for everything larger, you need a real solution.

[00:20:10]For the real proper fix to keep your module separate, you export them through your composed apps framework configuration. Export tells the Kotlin compiler pull this module symbols into the same framework binary. Uh this pattern is commonly called an umbrella module, where you have a single module that re-exports the others into one framework.

[00:20:31]And setting the transitive export options to true makes sure their dependencies come along, too.

[00:20:38]And the aesthetic true options, uh static linking is what Apple recommends on iOS. The reason is that every dynamically linked framework adds a little bit up to your app's launch time, since the dynamic linker has more work to do at startup.

[00:20:55]More frameworks, more work at launch.

[00:20:58]Static linking keeps everything in one binary, loaded once. The trade-off is that static linking can increase your binary size, and you have to be careful about symbol duplication if multiple prime frameworks pull in the same code.

[00:21:12]But for most setups, static is the right default.

[00:21:16]But this isn't even the end of the story. JetBrains is also working on something more structural and that brings us to a very, very relevant update.

[00:21:27]JetBrains is actively working on a new default project structure for KMP.

[00:21:32]Martin Brau, developer advocate at JetBrains, recently posted about replacing the all-in-one composable module with per platform app modules and separate shared modules.

[00:21:43]The post was just released last week and I needed to update my talk slide. So, now the new default KMP projects module have clearer responsibilities, better aligned with the conventions used by other build system.

[00:21:58]And I'm very excited to create a new KMP project now.

[00:22:04]Now, I've shown you what we did, but I owe you the alternatives because what we did isn't the only path.

[00:22:11]And if you're starting a KMP project today and you don't want to write delegate bridges yourself, you have three real options.

[00:22:19]First, go to the source.

[00:22:22]Firebase has a public feedback portal and there's already an open request for KMP support. It has been made in 12 2 years ago, I guess.

[00:22:33]Uh the more vote that thread gets, the more likely Google takes this seriously.

[00:22:38]So, if you've ever wanted Firebase to ship a Kotlin multiplatform SDK officially, go vote. Even if uh like me, voting for JUnit 5 support for Android for 7 years now, you've learned not to expect quick results. And second, there's an official Firebase Kotlin SDK from the GitLive team. It's actively maintained and it covers many Firebase APIs. Off, Firestore, Crashlytics, Remote Config. And we've actually looked at this for our project.

[00:23:10]It works great for the product it covers, but we needed Remote Config, and only about 20% of the Remote Config API was implemented. That's why we couldn't ship it.

[00:23:22]There's also a library named KMP Notifier for push notifications. We used it for it in the initial stage of our project, but ended up implementing delegate bridges.

[00:23:33]Third, sometimes the easiest answer is to don't fight the platform. Sentry has first-class KMP support, and so does Bugsnag. And if your only reason for using Firebase Crashlytics is crash reporting, switching to a tool that ships KMP support natively can save you weeks.

[00:23:52]So, three paths, and we took the hardest one because we had constraints. You may not, so pick that one that fits your team.

[00:24:03]And uh case study three, dependency management. This is the architectural fix that let us keep our modules separated while solving binary and isolations for good.

[00:24:15]Quick recap before we get to the new stuff. Earlier we saw on the case study two, we saw how Android handles this.

[00:24:23]Firebase Crashlytics ships with uh Kotlin SDK. You just add the Gradle dependency, import it, and call Firebase Crashlytics.

[00:24:32]On iOS, until very recently, this was the only way alternatively to manual dependency injection.

[00:24:39]You set up a CocoaPods in your Gradle build, declared the Firebase Crashlytics pod, run pod install, and then you could finally import it in your Kotlin code.

[00:24:49]Notice the important import path that CocoaPods prefix tells you exactly what's happening under the hood, the Kotlin compiler is pulling Objective-C headers through the CocoaPods.

[00:25:02]But, there is a tax. Every iOS developer knows the tax.

[00:25:07]Pod files, Ruby gems, pod install taking forever, the occasional pod repo update when your CI breaks for no reason.

[00:25:16]The kind of stuff that ages you.

[00:25:19]And the bigger problem isn't even the friction. It's the only It's the most modern iOS projects have already moved off CocoaPods. They use SwiftPM.

[00:25:29]So, the moment you add KMP to a clean SPM project, you're dragging CocoaPods back in.

[00:25:37]And then, just recently before the conference, Kotlin 2.4.0 hit RC, and that means I have to update my talk slide again.

[00:25:49]And it also brings SwiftPM import. It's experimental, but it's what a lot of us has been waiting for.

[00:25:56]A quick contest for the Android developers. SwiftPM, Swift package manager, plays roughly the same role CocoaPods used to. It's how iOS developers pull native dependency into their apps. The thing is, the most modern iOS projects have moved to SPM, and the default KMP setup leans to SPM, too. So, falling back to CocoaPods means a lot of work around.

[00:26:22]And here's the catch with KMP.

[00:26:25]Say you pick a native bind library, maybe one of the alternatives I mentioned earlier, or maybe something else entirely. You still have to physically link it into your KMP project. And until this release, if the library didn't ship KMP support, your only real options for that was CocoaPods. But now, SPM is built into Xcode, native to Swift ecosystem, and it doesn't make you install Ruby.

[00:26:52]So, how does this actually work? Let's look at the Gradle config first. Inside your Kotlin block, there's a new DSL called SwiftPM dependency. Uh this is where you declare Swift packages you want to consume from Kotlin native code.

[00:27:06]With products, which sub-libraries from the package you want to pull in, we grab Firebase Crashlytics for our delegate fix and our Firebase remote config because from the case study one, that's what we needed for our for sub-day feature.

[00:27:22]An imported clang modules tells Kotlin specifically when which clang modules to generate bindings for. The same two libraries here.

[00:27:31]And that's it. No pod file, no Ruby, just Gradle. And the Kotlin side, the code you actually write looks like this.

[00:27:39]Look at the import statement has changed into SwiftPM import. SwiftPM import and the module name and the class, FIR Crashlytics, that's the actual Firebase object- C class pulled directly into the Kotlin native. We don't have to write a bridge or define a delegate interface.

[00:27:57]Um so, all of these case studies worth nothing?

[00:28:00]Maybe not because one there's one caveat I have to mention before we move on.

[00:28:07]This works, but it's still experimental.

[00:28:10]A few things to keep in mind before you put SwiftPM import on a critical path.

[00:28:15]First is implement experimental status.

[00:28:19]JetBrains is actively collecting feedback in the Kotlin and Slack. KMP Swift package manager's Slack channel.

[00:28:26]APIs and behavior can change between releases. And we're using it on a side module to learn it, but our production crash reporting still goes through the framework export setup we saw earlier.

[00:28:40]Second is static should be true. Dynamic Kotlin native frameworks can hit linker errors on runtime symbol collisions when combined into the Swift PM imported native libraries.

[00:28:51]This is separate from the singleton issue we saw in case study two.

[00:28:55]The one was about having multiple frameworks. This one is about how single framework links against Swift PM's native code.

[00:29:04]The recommendation is the same.

[00:29:06]Go static, but for a different reason.

[00:29:10]And third, the round trip doesn't work yet. Regular KMP modules, you can already export them as Swift packages, and that's been around for a while. The new Swift PM import is also great. You can just combine the two.

[00:29:24]A KMP module that uses Swift PM import can't accept itself be exported as a Swift package.

[00:29:31]The direction is exciting, but it's not where I'd build production apps today.

[00:29:38]Okay, let's pull case study three together. And while you are looking at the diagrams, I might have a sip of water.

[00:29:55]Okay.

[00:29:56]One framework called compose app static, and all our Gradle modules, logger, core, data, etc. exported through it.

[00:30:05]From Swift's perspective, there's only one thing to import. The split singleton problem from case study two simply can't happen because there's only one binary for the singleton to live in.

[00:30:17]However, we could still have the benefits of module separation.

[00:30:21]Firebase comes into Swift PM import. Our Kotlin Kotlin code calls a Firebase Crashlytics directly. No Swift delegate, no manual bridge, same Firebase library that the iOS app uses for Firebase app configure.

[00:30:35]But pulled into the Kotlin where the logic actually runs.

[00:30:39]The Swift side gets smaller. App delegate does what only app delegate can go do. Firebase initialization, push notification things that the iOS system hands directly to Swift. Everything else moves to the Kotlin.

[00:30:55]And content view becomes a thin layer.

[00:30:57]It imports compose app, displays the compose UI, and forwards native events.

[00:31:03]Push notifications, deep links, life cycle callbacks into Kotlin through shared view controllers. And that's the pattern from case study one, and it's the part that doesn't go away even the Swift PM import becomes stable.

[00:31:18]So, that's it for the three case study, but it's too soon to wrap things up. So, let's shift gears for a bonus part, Swift and Kotlin interrupt pitfalls. And these are kinds of bugs that don't don't come from the architectural decisions, they come from the language boundary itself.

[00:31:36]Remember the state flow bridge from case study one? When you use it, there's something you have to know.

[00:31:42]Which thread the native callback runs on.

[00:31:45]Firebase callback runs on the main thread, but CL location manager, CBCentralManager, URLSession, these all callbacks on background threads.

[00:31:56]And roughly half of iOS native APIs that involve callbacks don't promise main thread.

[00:32:01]Half. So, you really can't assume.

[00:32:04]The only safe rule is every time you bridge a new API from Swift to Kotlin, check the documentation. And yes, we learned this on the hard way.

[00:32:14]And if you update a state flow that compose is observing from a background thread, you'll get a UI consistency warning at best and race condition at worst. You can fix it on the Swift side with dispatch queue.main.async or guarding on the Kotlin side with coroutine scope dispatchers.main.launch.

[00:32:32]Either works. I prefer the Kotlin side though, so the shared code stays Swift no matter who calls it.

[00:32:41]And these are also type mapping traps.

[00:32:43]Kotlin's long maps to the Swift's in 64, not int.

[00:32:48]And here's why that matters. Swift's int is 64-bit on modern devices, but Kotlin's int is always 32-bit. So if you pass a Swift int into where Kotlin expects an int, you'll get a compiler error, which is actually a good case because the compiler catches for you.

[00:33:08]But the nullable case is worse. When Kotlin long nullable becomes NSError nullable in Swift, and you will lose the type.

[00:33:17]NS number will happily give you int value or in 64 value, and if you pick the wrong one, you'll get a wrong value with no error at all. Remember the in 64 from case studies one's remote company code? This is exactly why.

[00:33:33]And throwable does not become NSError, it becomes Kotlin throwable. So when an iOS API expects an NSError, like Crashlytics record error, your Kotlin exception just doesn't fit. You need a manual converter at the boundary, the two NSError you saw earlier.

[00:33:52]And here is the cheat sheet. I wish someone had shown me this table a year ago, and you can screenshot this slide.

[00:34:00]And while you are doing it, note that this is not a complete interop reference. These are just the pitfalls we hit on production, and your project will hit different ones.

[00:34:10]If you want the actual full reference, every Kotlin language feature, every type mapping, every annotation, and how each one shows up in Swift, JetBrains maintains a repository called Swift Swift Kot- Kotlin Swift Interopedia.

[00:34:26]It's one nice naming. It's under GitHub under kotlin.hands-on, and that's what I wish I had on the day one.

[00:34:36]Okay, now let's wrap up. I want to connect everything back to why the community matters.

[00:34:43]Back in 2025, Kotlin Conf was held in Copenhagen, and I went there with a clear goal. I was struggling with the DI first, and I wanted to get the direct feedback on our architecture from the people who built it. The key The KMP community and KMP community still lacks established best practices for these kind of problems.

[00:35:05]So, I figured the best thing to do was to go straight to the JetBrains booth.

[00:35:10]And here's what had happened. I walked up to the JetBrains booth and asked about integrating third-party libraries into KMP project.

[00:35:19]The first developer there walked me through the standard in C interop approach, and the second developer chimed in and said, "That approach actually doesn't work for the five races SDK."

[00:35:31]So, I explained what our team had ended up with, the delegate pattern I just walked you through, and we really got into it. The kind of conversation you can only have with the people who built the tool. I picked up so many hints from these 15 minutes, and a lot of what we shipped after that conversation came directly from it.

[00:35:50]The SPM-based C interop approach we ended up adopting, that cannot that came out that exact conversation.

[00:35:58]And then, at the end, the second developer there came to me and said, "You shouldn't be here right now. You should go to the Google booth and demand official KMP support."

[00:36:10]So, the everyone in the booth laughed, and this year I came back with a different strategy. Instead of going to the Google booth, I figured I'd just get on the stage and tell all of you about it. So, consider this uh technically fine following their advices.

[00:36:32]And the conclusion from this experience, the KMP community is still evolving and we need your help. Best practices don't come from the API references, they come from the people building real things and sharing what they learn.

[00:36:45]And this talk exists because I came to Kotlin Conf last year, spoke with a JetBrains engineer at their booth and got feedback that they are directly saved our architecture.

[00:36:56]And if this is your first Kotlin Conf, go talk to people, visit the booth and that's where the real learning happens.

[00:37:03]Try things out both for KMP supporting Firebase, experiment with the Swift PM import and tell JetBrains what breaks.

[00:37:11]When I first started this project, most of what I needed wasn't in the official docs, official docs. It was buried in someone's blog post like 2:00 a.m.

[00:37:21]And if you find any better solutions or hit different problems, I'd love to hear about it. Come find me or reach me on LinkedIn.

[00:37:30]So, that was a lot of stories, so I I had to wrap up. We covered three things today. First is native state observation, when events come from the iOS side and your shared shared compose UI needs to react, you can bridge them through a state flow exposed from the Kotlin singleton.

[00:37:48]The platform specific code stays on the platform side and the shared logic stays shared.

[00:37:53]Second, non-KMP is the case, the hardest lesson of the year.

[00:37:57]The Kotlin object is the singleton per compiled binary, not per process. Two frameworks and two singletons and a delegate that silently disappears. The fix is to export the shared module to both sides, so, uh, the both sides point to one copy.

[00:38:14]Third is dependency management.

[00:38:16]CocoaPods is what we were running production today, but Swift PM import is the direction things are going. Promising, but still experimental as of today.

[00:38:27]One year in and here's where we are.

[00:38:30]100% of our UI is composed and across the whole code base, 98% is Kotlin. Server and client speak the same language and for three Android developers shipping on iOS app on deadline, that's not a small thing.

[00:38:45]KMP on iOS works in production. Not without scars, but it works. And I hope every scar in this talk is one you don't have to get yourself.

[00:38:56]And thank you so much for listening to my talk and thank you.

[00:39:06]Thank you so much.

[00:39:08]Please feel free to come find me afterward or reach me out on LinkedIn if you'd like to chat and don't forget to vote.

[00:39:16]Thank you and danke schön.

[00:39:19]Danke schön.