Kotlin Multiplatform - Actually Works Unlike Most Cross-Platform BS

JetBrains finally made a cross-platform tool that doesn't completely suck. KMP hit stable in November 2023, and Google officially supports it for sharing business logic between Android and iOS. The Kotlin Foundation now oversees the language development, while JetBrains maintains the toolchain. Took them long enough.

How This Thing Actually Works

The magic happens with three folders that will confuse the hell out of iOS developers:

• commonMain: Your business logic goes here. Write once, pray it works everywhere.
• androidMain: Platform-specific Android code and the usual Android bullshit
• iosMain: iOS-specific implementations. Good luck debugging this on a Mac.

The expect/actual mechanism is KMP's secret sauce. You declare what you expect in common code, then provide actual implementations per platform. It's like interfaces but more annoying to set up initially.

// In commonMain
expect fun getCurrentPlatform(): String

// In androidMain  
actual fun getCurrentPlatform(): String = "Android"

// In iosMain
actual fun getCurrentPlatform(): String = "iOS"

Two Ways to Not Hate Your Life

Option 1: Share Logic, Keep Native UI
Share your business logic, keep platform UIs native. Your users get the native feel, you get to write your API calls once. Netflix does this for their studio apps—not the main Netflix app, just internal tools most people never see.

Option 2: Go Full Compose Multiplatform
Compose for iOS went stable in May 2025. Now you can share UI too, but your app will look slightly off on iOS because Compose still feels like Android UI. iOS users will notice.

Libraries That Don't Completely Suck

The ecosystem finally has useful stuff:

• Ktor: HTTP client that works everywhere. Better than Retrofit for multiplatform, though setup is more verbose. Full KMP setup guide here.
• SQLDelight: Type-safe SQL that actually compiles. Room for KMP is coming but SQLDelight works today. Check the multiplatform database guide.
• Koin: Dependency injection without annotation processors breaking your build. Better than Dagger for shared code.
• Napier: Logging that works on iOS. Surprisingly not painful. Alternative to Kotlin logging.
• Kotlinx.serialization: JSON parsing that doesn't randomly break between platforms. More reliable than Gson for KMP.
• Coroutines: Async programming that works across platforms, though iOS threading is tricky.

Real Companies Using This in Production

McDonald's handles 6.5 million payments monthly with KMP. Started with payments (smart—nobody wants payment logic to randomly break differently per platform), then expanded to the whole app. Check JetBrains case studies for more details.

Forbes shares 80% of their app logic between iOS and Android. Not bad for a media company that probably has more content than engineering resources. See their technical deep dive.

Netflix uses it for internal studio apps—the ones production crews use, not the consumer app you binge-watch on. Makes sense since those tools have complex workflows and a small user base. TouchLab has a detailed analysis of their implementation.

Other notable adopters include Cash App, 9GAG, VMware, and Philips Healthcare.

Performance: Actually Native

Unlike React Native's JavaScript bridge or Flutter's custom rendering, KMP compiles to actual native code. Android gets JVM bytecode, iOS gets native machine code. No interpretation layers, no weird performance quirks at runtime.

The catch? iOS builds will make you question your life choices. We're talking 15-20 minutes versus 5 minutes for pure native. LLVM compilation is brutal, and Xcode randomly breaks KMP builds after updates with cryptic linker errors. Budget 2-3 days just to get CI working reliably, and expect your iOS developers to hate you for a few weeks.

The Real Learning Curve

If you're coming from pure Android development, expect about 2-3 weeks to get comfortable with the multiplatform setup. The Gradle configuration is more complex, and you'll spend time figuring out which dependencies work across platforms.

iOS developers will have a steeper curve learning Kotlin and Gradle. Expect 4-6 weeks minimum, and they'll complain about missing Xcode's integrated debugging tools the entire time. Watch them rage when they get duplicate symbols for architecture x86_64 errors from CocoaPods integration issues, or when Gradle sync takes 10 minutes on bad days while Xcode builds fly by.

Here's what actually happens when real companies try KMP in production, complete with the mistakes they don't mention in their tech blogs.

Netflix:

Internal Tools Only (Not What You Think)

Netflix uses KMP for their studio apps, not the streaming app you watch Netflix on.

These are internal tools for TV/film production crews—think crew scheduling, equipment management, script annotations. You can find technical implementation details and their [open-source contributions](https://github.com/Netflix

OSS).

Why internal tools first? Smart move. Lower user expectations, smaller blast radius when things break, and users who can't switch to a competitor when your app crashes.

They share about 50% of their code, which sounds disappointing until you realize that's still thousands of lines of business logic they don't have to maintain twice. The other 50% is platform-specific UI and integrations with iOS/Android APIs.

What they learned: Start with tools where perfect UI isn't critical.

Production crews care more about functionality than whether buttons look exactly like native iOS controls.

McDonald's: Payment Processing (High Stakes)

McDonald's went full KMP for their mobile app, handling 6.5 million monthly payments.

That's actually ballsy—payment processing is not where you want cross-platform bugs. Read their technical blog series and check the JetBrains case study.

They started with payment logic (smart—nobody wants different payment behavior per platform), then expanded to ordering, localization, and eventually rebuilt the whole app.

The real win? They merged their separate Android/i

OS teams into one mobile team. Less coordination overhead, shared knowledge, faster feature development.

The catch: Build times increased significantly. iOS builds that used to take 5 minutes now take 15-20 minutes.

They had to optimize their CI/CD pipeline and buy more powerful build machines.

Forbes: Media App Challenges

Forbes shares 80% of their app logic between platforms.

For a media company, that's actually impressive—article parsing, ad integration, analytics, user preferences, offline reading.

Their biggest surprise? Platform-specific article rendering was harder than expected. i

OS users expect different typography, spacing, and reading experiences than Android users. They ended up keeping more UI code separate than initially planned.

Learning: Just because you can share UI doesn't mean you should.

Reading experiences are deeply tied to platform conventions.

What These Success Stories Don't Tell You

Team Structure Reality

• Netflix: Already had strong Android expertise and could hire iOS developers who were willing to learn Kotlin
• McDonald's: Large enough engineering org to handle increased build complexity
• Forbes: Mostly business logic sharing, native UI preserved

None of these are 3-person startups.

They all have the engineering resources to handle KMP's complexity.

The Build Time Problem Nobody Talks About

i

OS compilation with KMP is significantly slower than pure native. We're talking 2-3x longer build times in many cases. That's fine if you deploy twice a week, but painful if you're doing rapid iteration.

Real numbers from a mid-size team:

• Pure iOS build: 3-4 minutes
• KMP iOS build: 8-12 minutes
• Android build:

Still fast (2-3 minutes)

Debugging Shared Code Is Still Pain

When shared business logic crashes on i

OS, debugging involves: 1.

Reproducing the issue in the iOS simulator 2. Finding the corresponding Kotlin code 3. Understanding the generated Objective-C headers that look like shared_module_kn_suspend_impl 4. Debugging through platform boundaries where stack traces just say "native code"

You'll spend hours on errors like NSInvalidArgumentException: unrecognized selector sent to instance when your expect/actual implementations don't match, or LLVM ERROR: out of memory during iOS compilation on machines with less than 16GB RAM.

The Kotlin/Native memory manager documentation becomes your bible.

Migration Patterns That Actually Work

Start Small (Netflix Approach)

Pick one feature that's mostly business logic—user preferences, data parsing, API calls.

Get comfortable with the tooling before expanding.

Payment-First (Mc

Donald's Approach) If you handle transactions, start there. Payment logic should be identical across platforms anyway, and it's complex enough to show real KMP benefits.

Green Field Projects

If you're building something new, KMP makes more sense than retrofitting existing apps. No legacy code, no "this worked fine in pure native" complaints.

Team Requirements Nobody Mentions

Minimum team size for KMP: 4-5 developers.

You need someone comfortable with Kotlin, someone who understands i

OS development, and someone willing to become the "KMP expert" who fixes build issues.

Don't try KMP if:

• Your team is 1-2 people
• Nobody has significant Android/Kotlin experience
• You can't afford 20-30% longer build times
• Your app is mostly UI with minimal business logic

Perfect KMP candidate:

• Android-first company expanding to iOS
• Complex business logic shared across platforms
• Team willing to invest 2-3 months in tooling setup
• Build pipeline that can handle longer compilation times

The companies succeeding with KMP aren't magical. They're just the right size with the right technical expertise and realistic expectations about the tradeoffs.