Touchlab Blog

Fully native mobile apps was for years the default mobile app development option. As cross-platform solutions and device capability have improved, “good enough” has become the default choice for anything that isn’t a big, public app. Kotlin Multiplatform and Compose, which can seamlessly blend shared and native UI, can make “native” the default choice again.

KMMBridge is a tool that helps you publish iOS XCFramework binaries from Kotlin Mutliplatform. The tool has seen multiple iterations over the past few years. This version simplifies the configuration and usage of KMMBridge, with a primary focus on Swift Package Manager (SPM).

When native mobile teams explore KMP, getting started is pretty easy. The difficulty emerges when they try to scale. To get the most out of KMP for your team, and for KMP as a platform to succeed, we need to make scaling easy as well.

Lottie and Bodymovin provide amazing animations that you can now use in your Compose Multiplatform projects.

Calling Kotlin Multiplatform from Swift can be a painful experience. Kotlin engineers new to KMP rarely understand the issues. The "Bad Swift Simulation" helps Kotlin engineers "feel the pain" by replicating the experience directly in Kotlin. With that experience, understanding how to fix the situation, and why you need to, is much simpler.

Virtually all native mobile teams evaluating KMP start with a library publishing model. KMP module libraries are written, versioned, and "consumed" by the apps. The classic approach is to build and publish binary dependencies. In 2024, with KMP at stable and gaining significant traction, we no longer recommend this approach. It makes an inherently imbalanced iOS developer experience worse. Share Kotlin source instead.

KMP for native mobile is mature technology. Best practice guidance for how teams should apply it is not. KMP has amazing potential, but presents unique workflow and management problems. Understanding these problems, and having a plan, is critical.

Huge improvement to Kotlin Multiplatform debugging in Xcode.

For teams scaling KMP, versioned libraries are inefficient. Merging app code and KMP code into a single repo may be impractical, and introduces its own issues. GitPortal allows bidirectional, eventual code sharing.

Do you actually need to use SPM or Cocoapods to include KMP? You don't, and it might not be the right answer