Swift to Kotlin: Unifying Mobile Codebases Across iOS and Android

Running two native mobile codebases is expensive. Not just in engineering hours — though those are significant — but in cognitive overhead. Every feature ships twice. Every bug fix is applied twice. Every architecture decision is made twice, and the two implementations inevitably drift apart.

The good news: Swift and Kotlin are more similar than most developers realize. If you're considering code sharing between iOS and Android, the business logic layer is the natural starting point.

The Surprising Similarity

Swift and Kotlin were both designed as modern improvements over their predecessors (Objective-C and Java, respectively). They independently converged on remarkably similar features:

// Swift
protocol Cacheable {
    var cacheKey: String { get }
    func invalidate() -> Bool
}

struct User: Cacheable {
    let name: String
    let email: String?
    var cacheKey: String { "user_\(name)" }
    func invalidate() -> Bool { true }
}

// Kotlin
interface Cacheable {
    val cacheKey: String
    fun invalidate(): Boolean
}

data class User(
    val name: String,
    val email: String?
) : Cacheable {
    override val cacheKey: String get() = "user_$name"
    override fun invalidate(): Boolean = true
}

Protocols map to interfaces. Optionals work nearly identically. Generics, closures/lambdas, and pattern matching all have close equivalents. The syntactic differences are minor; the semantic overlap is substantial.

What Converts Cleanly

Business logic. Domain models, validation rules, calculation engines, state machines. Anything that doesn't touch platform APIs translates well between Swift and Kotlin.

Networking layers. HTTP clients, JSON parsing, API response models. The patterns are identical even if the libraries differ (URLSession vs. OkHttp, Codable vs. kotlinx.serialization).

Data models. Swift structs map to Kotlin data classes. Enums with associated values map to sealed classes.

What Diverges

UI frameworks. UIKit/SwiftUI and Jetpack Compose are different worlds. Don't try to convert UI code — rewrite it for each platform.

Platform APIs. Core Data vs. Room, Keychain vs. EncryptedSharedPreferences, Push notifications, camera access. These are platform-specific by nature.

Concurrency. Swift's structured concurrency (async/await with actors) and Kotlin coroutines are conceptually similar but architecturally different. Converting between them requires understanding both models.

The KMP Strategy

Kotlin Multiplatform (KMP) lets you write shared business logic in Kotlin that compiles to both JVM (Android) and native (iOS). Converting your Swift business logic to Kotlin is the first step toward KMP adoption.

Cash App's KMP implementation shares networking, data models, and business logic across platforms. Netflix uses KMP for similar shared layers. The pattern works — but it starts with having the shared code in Kotlin.

Swift → Kotlin and Kotlin → Swift are both supported at quality level 2 (good) on B&G CodeFoundry. Automated conversion of the business logic layer creates a solid starting point for KMP adoption.

---

References: Cash App KMP adoption blog; Netflix platform engineering talks; Kotlin Multiplatform documentation; Jetpack Compose adoption data (Android developer surveys).