Touchlab Blog

Compose Multiplatform has a critical unique feature. On iOS, you can mix Compose UI with native iOS UI. This is all enabled by the direct interop of Kotlin Multiplatform. That capability is amazing for mobile development. However, the actual process of wiring these two requires a fair bit of boilerplate. We've launch Compose Swift Bridge to automate that.

If you are building a mobile product, you are probably considering React Native, Flutter, or some flavor of HTML. Maybe you’re even considering fully native apps. If so, you should learn about Compose Multiplatform. Compose provides full cross-platform efficiency, and can be as native as you need, minus the risk.

Let's chat about a few pain points we had when we started doing animations with compose, how we tried to solve them, and how you can solve the problems now!

We've updated the Droidcon NYC 2024 app with a new design and features. The app now uses Material 3 theming, and includes push notifications for in-conference messaging.

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.