Big Tech's Secret Weapon: How Netflix, McDonald's & Cash App Ship Faster with Kotlin Multiplatform (2025)

When the stakes are billions, what do tech giants choose?

In 2020, something remarkable happened: Netflix publicly announced they were adopting Kotlin Multiplatform for their mobile studio apps. As the first FAANG company to make this move, they sent shockwaves through the mobile development community.

Fast forward to 2025, and the adoption story has exploded. KMP usage jumped from 12% to 23% in just 18 months. But here's what the numbers don't tell you: these aren't side projects or experiments.

McDonald's is processing millions of real payments. Cash App is handling people's actual money. Philips is building healthcare-grade medical device SDKs. When you're operating at this scale, with this much revenue on the line, you don't choose technologies on hype—you choose them because they work.

Let's dive into the real case studies, with actual metrics, code patterns, and honest lessons learned from companies shipping KMP in production.

The FAANG Pioneer: How Netflix ships faster for TV and movie production

In October 2020, Netflix made history by becoming the first FAANG company to publicly adopt Kotlin Multiplatform and put it into production. But why would a company known for engineering excellence take a bet on a relatively new technology?

The challenge: Building mobile tools for Hollywood

Netflix needed to build Prodicle, a mobile app designed to innovate in the physical production of TV shows and movies. The app helps production teams manage everything from scheduling to on-set logistics in the fast-paced world of entertainment production.

The challenge? They needed to ship features fast, maintain high quality, and avoid writing everything twice for iOS and Android.

Why Netflix chose Kotlin Multiplatform

After following KMP's evolution for years, Netflix identified a key insight: almost 50% of the production code in their Android and iOS apps was decoupled from the underlying platform. This business logic—networking, data processing, authentication—didn't need to be platform-specific.

The Netflix engineering team noted:

"The technology has reached an inflection point. Tooling and build system integrations for Xcode have improved significantly, making it viable for production use."

What Netflix built with KMP

Netflix's KMP architecture:

Prodicle mobile app - Full production management system
Hendrix mobile SDK - Lightweight, platform-agnostic SDK
Shared business logic - Authentication, data synchronization, API clients
Native UIs - Platform-specific interfaces for optimal user experience

Here's a simplified version of Netflix's architecture pattern:

kotlin
// Shared Kotlin code (runs on Android & iOS)
class ProductionRepository(
    private val api: ProductionApi,
    private val database: ProductionDatabase
) {
    suspend fun syncProduction(productionId: String): Production {
        // Complex business logic written once
        val remoteData = api.fetchProduction(productionId)
        val localData = database.getProduction(productionId)

        return mergeProductionData(remoteData, localData).also {
            database.saveProduction(it)
        }
    }

    suspend fun updateSchedule(
        productionId: String,
        schedule: Schedule
    ): Result<Unit> {
        return try {
            api.updateSchedule(productionId, schedule)
            database.updateSchedule(productionId, schedule)
            Result.success(Unit)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }
}

// This code compiles to:
// - Kotlin library for Android
// - Native Universal Framework for iOS via Kotlin/Native

Results and impact

Netflix achieved their goals:

Eliminated code duplication for platform-agnostic logic
Faster, more reliable development in the fast-paced TV/movie industry
Shared codebase between Android and iOS teams
High-quality features delivered efficiently

Most importantly, Netflix proved that FAANG-scale companies could successfully adopt KMP for production-critical applications.

Scale at billions: McDonald's serves 69 million daily customers with KMP

If Netflix proved KMP works for media production, McDonald's proved it works at unprecedented scale. We're talking about an app with:

100+ million downloads on Android alone
69 million daily customers worldwide
6.5 million monthly purchases processed through the app
Complex payment systems requiring bank-grade security

The challenge: One codebase, global scale

McDonald's Global Mobile App needed to handle in-app payments, loyalty programs, menu customization, and real-time order tracking. The complexity? Every feature had to work flawlessly across both platforms, in dozens of countries, with different payment systems and regulations.

Writing this twice meant double the bugs, double the testing, and double the time to market. They needed a better solution.

McDonald's implementation approach

McDonald's explored options to reduce code duplication and landed on a key insight: if an application is designed around dependency injection and uses clean architecture, KMP fits perfectly as a shared domain layer.

What McDonald's shares with KMP:

Payment processing logic - Complex transactions, validation, error handling
Order management - Cart logic, customization rules, order status
Loyalty programs - Points calculation, rewards redemption
API clients - Network requests, response parsing, caching
Data storage - Local persistence for offline functionality

What stays native: UI components, animations, platform-specific integrations

Here's how McDonald's structures their payment logic:

kotlin
// Shared domain layer for payments
class PaymentProcessor(
    private val paymentGateway: PaymentGateway,
    private val orderValidator: OrderValidator,
    private val analytics: Analytics
) {
    suspend fun processPayment(
        order: Order,
        paymentMethod: PaymentMethod
    ): PaymentResult {
        // This complex logic is written once for both platforms
        analytics.trackEvent("payment_initiated", order.toAnalyticsData())

        // Validate order before payment
        val validationResult = orderValidator.validate(order)
        if (validationResult.isFailure) {
            analytics.trackEvent("payment_validation_failed")
            return PaymentResult.ValidationError(validationResult.error)
        }

        // Process payment with retry logic
        return try {
            val result = paymentGateway.charge(
                amount = order.total,
                method = paymentMethod,
                metadata = order.toPaymentMetadata()
            )

            when (result) {
                is PaymentSuccess -> {
                    analytics.trackEvent("payment_success", result.data)
                    PaymentResult.Success(result.transactionId)
                }
                is PaymentDeclined -> {
                    analytics.trackEvent("payment_declined", result.reason)
                    PaymentResult.Declined(result.reason)
                }
            }
        } catch (e: NetworkException) {
            analytics.trackEvent("payment_network_error")
            PaymentResult.NetworkError(e.message)
        }
    }
}

// Platform-specific implementations use expect/actual
expect class PaymentGateway {
    suspend fun charge(
        amount: Money,
        method: PaymentMethod,
        metadata: Map<String, String>
    ): PaymentGatewayResult
}

Results: Improved performance, reduced crashes, unified team

McDonald's adoption of Kotlin Multiplatform delivered measurable results:

6.5 million monthly purchases processed successfully
Improved performance across both platforms
Reduced crashes through shared, thoroughly tested code
Streamlined testing - Test business logic once instead of twice
Unified development team - iOS and Android developers collaborating on shared code
Faster feature development - New features developed and tested in one location

The key insight from McDonald's? Early adoption of shared functionalities like networking and data storage reduces repeated code, and even mature projects benefit as new features only need to be developed once.

The cautious adopter: Cash App's 7-year KMP journey

While Netflix and McDonald's showcase successful large-scale adoption, Cash App's story is different—and perhaps more instructive for most companies. They show us how to adopt KMP gradually, safely, and pragmatically.

Timeline: From experiment to production standard (2018-2025)

2018 - Started testing KMP technology with help from TouchLab
2019 - Began experimenting with Kotlin/Native on iOS
2021 - Adopted Kotlin/JavaScript for shared presentation logic
2025 - KMP now powers critical features in production

The Cash App approach: Feature flags and organic growth

Cash App didn't go all-in overnight. They used a feature flag strategy, slowly rolling out KMP code behind flags to ensure they could safely deploy and address any early adopter issues.

Their philosophy? "The vast majority of our code is written natively, as developer happiness and productivity remains most important."

What Cash App shares with KMP:

Persistence layer - Database access with SQLDelight
Pure functions - Business logic without side effects
Money formatting - Critical for financial accuracy (now in production on Android)
Network APIs - Protocol buffers with Wire
Data validation - Shared validation rules for financial transactions

Key technologies:

SQLDelight for type-safe database access
Wire for protocol buffers
CrashKiOS for better iOS stack traces
Redwood for multiplatform reactive UI (in beta rollout)

Here's Cash App's production money formatter:

kotlin
// Real production code from Cash App (simplified)
class MoneyFormatter(
    private val locale: Locale,
    private val currencyCode: String
) {
    fun format(amount: Long, currency: Currency): String {
        // This exact logic runs on Android and iOS
        val majorUnits = amount / currency.minorUnitsPerMajor
        val minorUnits = amount % currency.minorUnitsPerMajor

        return when (locale) {
            Locale.US -> formatUS(majorUnits, minorUnits, currency)
            Locale.UK -> formatUK(majorUnits, minorUnits, currency)
            else -> formatDefault(majorUnits, minorUnits, currency)
        }
    }

    private fun formatUS(major: Long, minor: Long, currency: Currency): String {
        val symbol = currency.symbol
        val formatted = String.format("%,d", major)
        val cents = String.format("%02d", minor)
        return "$symbol$formatted.$cents"
    }

    // Additional formatting logic...
}

// This formatter is CRITICAL for Cash App
// Any bug could cost real money to real users
// That's why sharing the code (and tests) is so valuable

Cash App's open source contributions

Rather than keeping their learnings internal, Cash App has contributed significantly to the KMP ecosystem:

Redwood - Multiplatform reactive UI framework (native UI + multiplatform Compose)
Poko - Compiler plugin now supporting multiplatform
SQLDelight contributions - Improvements to multiplatform database access

Results: Organic adoption that scales

Cash App's patient approach yielded sustainable results:

7+ years in production proves long-term viability
Critical financial features running reliably on shared code
Developer happiness maintained - adoption grows naturally, not forced
Easy experimentation - Teams can try KMP without company-wide mandates
Production-ready on Android - Money formatter and other features live
Redwood beta rollout - Next-generation UI sharing coming to customers

The Cash App lesson? You don't need to rewrite everything. Start small, prove value, and let adoption grow organically.

Beyond the big three: More production success stories

Netflix, McDonald's, and Cash App make headlines, but they're far from alone. Here's what other major companies are achieving with KMP:

Forbes: Publishing at scale

What they share: 80%+ of application logic

Key benefit: Simultaneous feature rollout across platforms

Impact: iOS and Android apps stay in perfect sync—no more "Android got this feature first" complaints from users.

Philips: Healthcare-grade reliability

What they built: HealthSuite Digital Platform mobile SDK

Use case: Connecting medical devices, collecting patient data, uploading medical images

Key benefit: Accelerated feature implementation, improved iOS/Android team collaboration

Technical approach: OpenAPI code generation for KMP, automatically staying in sync with cloud services

Why it matters: When you're dealing with healthcare data and medical devices, reliability isn't optional—it's life-or-death. Philips chose KMP for mission-critical infrastructure.

VMware: Enterprise productivity at scale

What they built: Workspace ONE platform modules

Approach: Various KMP modules enabling consistent cross-platform functionality

Key benefit: Unified productivity app portfolio across devices

Challenge overcome: Limited library support in early days—they built bridges using expect/actual for platform-specific implementations

9GAG: Choosing KMP after trying everything

Journey: Evaluated Flutter, React Native, and KMP

Decision: Chose KMP for gradual adoption

Result: Shipping features faster while maintaining native feel

Key insight: Unlike other frameworks, KMP allowed them to adopt incrementally without rewriting their entire app.

Baidu: China's tech giant goes multiplatform

What they built: Wonder App with KMP

What they share: Unified data layer and business logic

Results:

Consistent user experiences across iOS and Android
Significantly reduced maintenance costs
Improved team productivity

The patterns: What these companies actually share

After analyzing dozens of case studies, clear patterns emerge about what works (and what doesn't) when adopting KMP at scale.

What successful companies share with KMP

1. Networking and API clients

HTTP requests with Ktor
Response parsing with kotlinx.serialization
Error handling and retry logic
Authentication token management

2. Data persistence and caching

Local databases with SQLDelight
Key-value storage
Cache invalidation logic
Offline-first architectures

3. Business logic and validation

Payment processing (McDonald's, Cash App)
Data synchronization (Netflix)
Complex calculations (Cash App's money formatter)
Form validation rules

4. Analytics and monitoring

Event tracking logic
User property management
Error reporting
Performance monitoring

What they DON'T initially share

UI components (at first)

Most companies start with native UIs
Compose Multiplatform adoption comes later
Platform-specific animations and gestures
Native navigation patterns

Why? Teams want to maintain maximum native feel while they validate the KMP approach. Once proven, many migrate to shared UI with Compose Multiplatform.

Architecture patterns that work

Clean Architecture + Dependency Injection

McDonald's insight: "If an application is designed around dependency injection and uses clean architecture, KMP fits perfectly as a shared domain layer."

┌─────────────────────────────────────┐
│         Platform UI Layer           │
│    (Android/iOS Native or CMP)      │
├─────────────────────────────────────┤
│      Presentation Layer (KMP)       │
│    ViewModels, UI State, Events     │
├─────────────────────────────────────┤
│       Domain Layer (KMP) ← Perfect fit!
│   Use Cases, Business Logic         │
├─────────────────────────────────────┤
│        Data Layer (KMP)             │
│   Repositories, API Clients, DB     │
├─────────────────────────────────────┤
│   Platform-Specific (expect/actual) │
│   Native APIs, Platform Services    │
└─────────────────────────────────────┘

Team evolution patterns

Before KMP:

Separate Android and iOS teams
"Us vs them" mentality
Features ship at different times
Duplicate bug fixes
Knowledge silos

After KMP adoption:

Unified mobile team
iOS developers contributing Kotlin code
Shared ownership of features
Synchronized releases
Collaborative problem-solving

Real quote from a case study: "iOS engineers now contribute to shared Kotlin code just as actively as Android engineers."

Decision framework: Should YOUR company adopt KMP?

Netflix, McDonald's, and Cash App all found success with KMP—but that doesn't mean it's right for every company. Here's an honest assessment of when KMP makes sense (and when it doesn't).

KMP is an excellent fit when...

1. You have existing Android expertise

Your Android team already knows Kotlin. The learning curve for KMP is minimal—mostly understanding expect/actual and platform interop.

2. You have complex business logic to share

Payment processing (McDonald's), financial calculations (Cash App), data synchronization (Netflix)—these benefit hugely from shared implementation.

3. You use clean architecture or dependency injection

As McDonald's discovered, KMP slots perfectly into well-architected apps as the domain layer.

4. You want flexibility: native UI OR shared UI

Unlike Flutter or React Native, KMP lets you choose:

Start with native UI (maximum platform feel)
Gradually adopt Compose Multiplatform for shared UI
Mix both approaches as needed

5. You're migrating existing Android apps to iOS

You can share logic while keeping existing Android UI untouched. No "big rewrite" required.

6. Long-term maintenance cost matters more than initial speed

KMP's initial setup takes longer than Flutter, but maintenance costs drop dramatically once shared code is established.

7. Native performance is critical

Financial apps, healthcare apps, real-time features—KMP compiles to actual native code with zero performance overhead.

Consider carefully when...

1. You have no Kotlin experience

Learning Kotlin + KMP + platform specifics is a steep learning curve. Consider hiring experienced developers or starting with training.

2. You need the absolute fastest time-to-market

For MVPs and prototypes, Flutter might get you to market faster. KMP's strength is long-term maintenance, not initial velocity.

3. Your team is 100% JavaScript-focused

If your entire company is built on React and Node.js, React Native might be more natural—unless you're willing to invest in Kotlin skills.

4. You need extensive third-party libraries NOW

React Native's ecosystem is larger. KMP's library ecosystem is growing rapidly but still catching up in some areas.

KMP might not be right when...

1. You're building a simple CRUD app

If your app is mostly forms and lists with no complex logic, the benefits of code sharing are minimal. Any framework will work fine.

2. You only need one platform right now

Don't adopt KMP "just in case" you need iOS later. Build native for your current platform, migrate later if needed.

3. Your platform-specific features dominate

If 80% of your app is camera processing, AR features, or complex animations, the shared logic portion might be too small to justify KMP.

4. You can't dedicate time to learning and setup

KMP requires investment in learning, tooling setup, and CI/CD configuration. If you're under extreme time pressure, wait until you have breathing room.

The Cash App approach: Start small, prove value

Don't know if KMP is right for you? Do what Cash App did:

Pick ONE feature to build with KMP (something with clear business logic)
Put it behind a feature flag so you can safely deploy
Measure the results - development time, bug rates, team satisfaction
Decide based on data, not hype
If it works, expand gradually - let adoption grow organically

Cash App is now 7 years into their KMP journey and still going strong. The gradual approach works.

2025 and beyond: Why adoption is accelerating

When Netflix adopted KMP in 2020, they were pioneers taking a calculated risk. By 2025, the landscape has changed dramatically.

Google's official backing changes everything

At Google I/O 2024, Google made it official: Kotlin Multiplatform has first-class support for sharing business logic between Android and iOS.

What this means in practice:

Kotlin Multiplatform plugin now built into Android Studio - No more third-party plugin setup
Project wizards for KMP - Create KMP projects with one click
Compose Hot Reload - See changes instantly without restarts (game-changer for productivity)
Improved debugging tools - Debug iOS code directly from Android Studio

Jetpack libraries gaining KMP support

The biggest development in 2025: Jetpack libraries are becoming multiplatform.

Now available for KMP:

Room - SQLite database with type-safe queries (works on iOS!)
DataStore - Type-safe key-value storage for preferences
ViewModel - Lifecycle-aware state management across platforms
Navigation - Type-safe navigation coming to multiplatform

This is HUGE. Android developers can now use familiar tools on iOS without learning new libraries.

Compose Multiplatform for iOS: Now stable

In May 2025, JetBrains released Compose Multiplatform 1.8.0 with iOS support marked as stable and production-ready.

What's included:

iOS-native scrolling physics - Feels like native iOS
Native text editing - Selection, right-to-left, all working perfectly
System drag-and-drop integration
Adaptive UI - Respects iOS font size, contrast settings
Native gestures - Back swipes, long press, all feel right
VoiceOver support - Full accessibility for iOS users

The data is compelling: Over 96% of teams using Compose Multiplatform on iOS report no major performance concerns.

Swift Export: The final piece of the puzzle

Coming in Kotlin 2.2.20: Direct Kotlin-to-Swift export.

What this means:

No more fighting with Objective-C headers
Swift developers can call KMP code that looks and feels like native Swift
Better IDE autocomplete and type inference in Xcode
Easier to convince iOS-first teams to adopt KMP

This addresses one of the biggest complaints about KMP: the Objective-C interop friction. With Swift Export, that friction disappears.

The 2025 verdict: KMP has crossed the chasm

In 2020, Netflix was a pioneer taking a risk.

In 2025, KMP is mainstream and production-proven:

✅ Stable tooling - First-class Android Studio support
✅ Stable Compose for iOS - 96% of teams report no performance issues
✅ Google's official backing - Not just JetBrains anymore
✅ Jetpack libraries going multiplatform - Room, DataStore, ViewModel work on iOS
✅ Swift Export coming - Native Swift interop without Objective-C friction
✅ Proven at scale - Netflix, McDonald's, Cash App, Philips, VMware, Forbes, Baidu
✅ 7+ years in production - Cash App proves long-term viability

The question is no longer "Is KMP ready?" The question is: "Is KMP right for YOUR specific use case?"

What can you learn from these pioneers?

Let's distill the key lessons from Netflix, McDonald's, Cash App, and the other companies shipping KMP in production:

Lesson 1: Start with business logic, not UI

Every successful company started by sharing business logic (networking, data, validation) before considering shared UI. Native UI keeps stakeholders happy while you prove KMP works.

Lesson 2: Clean architecture is your friend

As McDonald's learned: dependency injection + clean architecture = perfect fit for KMP. The domain layer is the sweet spot.

Lesson 3: Gradual adoption beats big rewrites

Cash App's 7-year journey shows the power of patience. Feature flags, small experiments, organic growth—these work better than "rewrite everything" mandates.

Lesson 4: Team collaboration improves dramatically

When iOS and Android developers work on shared Kotlin code, the "us vs them" mentality disappears. Features ship simultaneously. Knowledge silos break down.

Lesson 5: Performance is not a concern at scale

McDonald's processes 6.5M monthly purchases. Netflix ships critical production tools. Cash App handles real money. If KMP works for them, performance isn't your bottleneck.

Lesson 6: You don't need to wait for perfect tooling

VMware and Netflix adopted KMP when tooling was much rougher. If they could make it work then, you can definitely make it work now with stable tooling in 2025.

Ready to ship like the big players?

Netflix, McDonald's, and Cash App spent months (or years) building their KMP infrastructure from scratch. They had to figure out:

Authentication flows (Google, Apple, Email)
Payment processing and in-app purchases
Push notifications setup
CI/CD pipelines for both platforms
Project structure and architecture
Build configurations and signing

You don't have to. What these companies built internally, you can have ready-to-deploy in minutes.

KMPShip: Production-ready Kotlin Multiplatform in minutes, not months

Stop building boilerplate. Start building features that make you money.

Everything you need, ready to ship:

🔐 Authentication (Google, Apple, Email/Password)
💳 In-app purchases and subscriptions
🔔 Push notifications (FCM + APNs)
🚀 CI/CD pipelines (GitHub Actions + Fastlane)

Built on proven patterns:

📱 Complete sample app (not just hello world)
📚 Comprehensive documentation
🏗️ Clean architecture (like McDonald's uses)
⚡ Compose Multiplatform for shared UI

While your competitors spend 2 months on setup, you'll be shipping features on Day 1.

Get KMPShip Now →

Join the companies shipping faster with Kotlin Multiplatform

Sources and references

Note: Metrics and quotes are sourced from official company blogs, case studies, and JetBrains documentation. Some code examples are simplified for clarity but represent actual production patterns used by these companies.

Continue your Kotlin Multiplatform journey

Want to learn more about specific KMP topics?

Quick Questions About KMP Development

Still have questions about Kotlin Multiplatform? Get instant answers:

Do I need a Mac for iOS development? - Platform requirements explained
How long does setup actually take? - Real timeline expectations
What's the total cost comparison? - KMP vs traditional development costs

Ready to skip the setup hassle?

While your competitors spend weeks configuring authentication, payments, and CI/CD, you could be building features that matter.