Scaling Enterprise Mobile Apps with Kotlin Multiplatform: Architecture, Tooling, and Governance

Historically, mobile engineering teams faced two main options: maintain separate native codebases (Swift for iOS, Kotlin for Android) and duplicate their engineering work, or adopt cross-platform frameworks like Flutter or React Native and accept trade-offs in UI behavior, performance, and platform abstraction.

Kotlin Multiplatform (KMP) changes this trade-off. Instead of running a custom rendering engine inside a non-native sandbox, KMP shares business logic, networking, and data layers while keeping the presentation layer native (SwiftUI on iOS and Jetpack Compose on Android).

Rolling out KMP across teams of 50 to 200+ developers requires more than writing shared Kotlin files. It needs a workable distribution model for developer experience (DevEx), automated CI caching to handle compiler overhead, and clear architectural rules. At Lidex Soluções Digitais, we help engineering teams modernize mobile codebases to share code without slowing down developers or compromising platform conventions.

Here is how engineering organizations run Kotlin Multiplatform at scale.

---

Why teams choose shared logic over cross-platform UI

Forcing cross-platform UI frameworks onto native specialists often creates problems. UI-centric multiplatform frameworks hide native UI toolkits, which demands custom wrappers for platform-specific features and navigation patterns.

KMP compiles shared business logic directly for each target environment:

• On Android, Kotlin compiles to standard JVM bytecode.
• On iOS, the Kotlin/Native compiler uses an LLVM backend to compile shared code into native Apple frameworks (.xcframework / Mach-O binaries).

At Google I/O 2024, Google endorsed Kotlin Multiplatform as its recommended approach for sharing business logic across Android, iOS, Web, and desktop. Google has since ported several Android Jetpack libraries to commonMain:

• Data and persistence: androidx.room (released in alpha KMP in mid-2024 and expanded to stable releases supporting JVM, iOS, and Linux ARM) and androidx.datastore (stable KMP).
• Architecture components: Lifecycle, ViewModel, Paging, Annotations, and Collections now target commonMain.

Google also migrated the shared logic of Google Docs from Java-based J2ObjC cross-compilers to KMP, demonstrating that it meets requirements for throughput, memory management, and binary size in production document editing.

---

Solving logic drift at scale: adoption and governance

When companies maintain separate native teams, they frequently encounter logic drift: discrepancies between how iOS and Android handle business rules, data parsing, telemetry, and experiment tracking.

JetBrains Developer Ecosystem data shows that KMP production adoption grew from 7% in 2024 to 18% in 2025. In the 2024 Snapp Mobile KMP Survey, 46.7% of enterprise mobile teams were evaluating or implementing KMP. Much of this adoption aims to eliminate logic discrepancies while retaining native UI code.

The Booking.com approach: experimentation and exit ramps

In a published case study, Booking.com detailed its KMP adoption. The company ran over 1,000 concurrent experiments across platforms, and maintaining separate logic (Java/Kotlin for Android and Objective-C/Swift for iOS) had created inconsistencies in attribution, telemetry, and tracking.

Booking.com unified its experiment evaluation logic into a shared KMP binary module. Engineering leadership added an exit-ramp policy to address team concerns:

1. The shared module had strict SLAs for iOS binary size, crash symbolication, and startup speed.
2. If the module failed those criteria, teams retained the right to rewrite it in native Swift.

The pilot met every benchmark, aligning experiment logic across platforms.

Forbes took a similar path, sharing more than 80% of its business logic between iOS and Android. Forbes maintained native UI (SwiftUI on iOS and Jetpack Compose on Android) and used KMP for data synchronization, article archiving, and networking. This decoupled platform release cycles and allowed synchronized feature rollouts.

---

iOS interoperability: SKIE and Swift concurrency

Developer experience on iOS has often been a stumbling block for KMP adoption. By default, the Kotlin/Native compiler generates Objective-C headers to bridge Kotlin code to Apple platforms. This creates friction for Swift developers:

• Kotlin Coroutine Flow<T> does not map directly to Swift's AsyncSequence, which leads to type erasure to AnyObject.
• Kotlin sealed class and sealed interface hierarchies lose exhaustiveness in Swift, requiring iOS developers to add unnecessary default branches in switch statements.
• Coroutine cancellation does not map cleanly into Swift structured concurrency (async/await and Task cancellation), which risks unhandled CancellationException errors showing up in iOS crash logs.

To address these issues, teams integrate Touchlab's SKIE (Swift Kotlin Interface Enhancer) into build pipelines. SKIE runs as a compiler plugin that generates Swift wrappers directly inside the output .xcframework. It translates Kotlin Flow into Swift AsyncSequence while preserving types, converts Kotlin sealed classes and enums into Swift enums for exhaustive pattern matching, and links into Swift's async/await system to manage two-way cancellation cleanly.

In Kotlin 2.0+, JetBrains also added experimental direct Kotlin-to-Swift export to bypass Objective-C bridges entirely, which teams test alongside SKIE.

---

Enterprise distribution: decoupling iOS teams with KMMBridge and SPM

When an organization has 50 to 200+ mobile developers, requiring iOS engineers to install the JVM, Android SDK, and Gradle just to build their apps causes dependency issues and slows down work. Distributing prebuilt binary artifacts solves this.

With Touchlab's KMMBridge Gradle plugin, teams separate repository access and tooling:

1. The shared team writes Kotlin Multiplatform code in a dedicated repository or modular tier of a monorepo.
2. CI (such as GitHub Actions, GitLab CI, or Bitrise) compiles the Kotlin code into an Apple universal .xcframework bundle (arm64 for devices and x86_64/arm64-simulator for simulators).
3. CI zips the binary framework, uploads it to an internal Maven or GitHub/Artifactory repository, calculates the checksum, and updates a Package.swift manifest in a private repository.
4. iOS developers import the artifact as a standard Swift Package Manager (SPM) binary dependency in Xcode.

Under this model, iOS developers work only with Swift types and compiled binaries. They never run Gradle tasks, which shields native iOS builds from Kotlin/Native compile times.

---

CI/CD scalability: managing LLVM linking overhead

Kotlin/Native relies on the LLVM backend to produce Mach-O binaries for Apple platforms. This linking step uses significant memory and takes longer than JVM compilation.

To keep CI fast, mobile infrastructure teams use three main techniques:

1. Migrating to the K2 compiler frontend

The Kotlin 2.0 (K2) compiler frontend, released in May 2024, can compile large multiplatform modules up to twice as fast as the Kotlin 1.9 pipeline.

2. Remote build caching with Gradle Develocity

Because tasks like compileCommonMainKotlinMetadata and iOS framework linking depend deterministically on source code inputs, teams run remote build caches with Gradle Develocity (formerly Gradle Enterprise). Caching avoids recompiling unchanged KMP modules in CI, typically cutting compilation work by 30% to 50% on multi-module builds.

3. Modular separation

Splitting shared code into distinct layers (such as :core:network, :core:database, and :feature:auth-domain) prevents broad recompilation after small edits. Linking tasks like linkPodReleaseFrameworkIosArm64 run only during artifact-release jobs instead of on every unit-test run.

---

Building a practical multiplatform strategy

Kotlin Multiplatform offers an incremental way to share business logic without replacing native UI. Done right, it removes duplicate code and unifies platform behavior while letting teams build native interfaces.

Making it work at scale comes down to how teams handle the boundary between platforms: keeping the Swift developer experience clean with SKIE, isolating iOS builds through SPM binary releases with KMMBridge, and keeping CI pipelines fast with current compilers and remote caching.

At Lidex Soluções Digitais, we help teams evaluate, design, and scale mobile architectures. Whether you are running an initial KMP pilot or restructuring existing enterprise applications, our team can help you set up shared codebases that remain maintainable and fast to build.