Question 1

Kotlin Multiplatform documentation increasingly discourages using expect class in favor of shared interfaces with platform-specific factory implementations. Explain the maintenance, testing, and coupling issues that arise with expect class when designing a multiplatform SecureStorage client.

Accepted Answer

An `expect class` forces you to write a full `actual` implementation in every source set, even for the parts of the class that are identical everywhere. For a `SecureStorage` client, things like key validation, TTL logic, or error wrapping usually don't differ per platform — but because `expect class` can't ship a default/common implementation of its members, that logic gets copy-pasted into the Android and iOS `actual class` bodies instead of living once in `commonMain`. Any bug fix or new validation rule has to be applied twice (or four times, once per target).

Testing is the bigger pain. You can't easily inject a fake `SecureStorage` into `commonMain` unit tests because the `expect class` is resolved at compile time per source set — you'd need to write and maintain a fake `actual` implementation just for the test source set on every platform, or fall back to running tests per-target instead of once in `commonTest`.

The cleaner pattern is a plain interface in `commonMain`:
```kotlin
// commonMain
interface SecureStorage {
    suspend fun put(key: String, value: String)
    suspend fun get(key: String): String?
}

expect fun createSecureStorage(): SecureStorage
```
Now `commonTest` just implements `SecureStorage` with an in-memory fake — no `expect`/`actual` involved in tests at all — and the interface can be swapped, decorated (e.g. wrapped with logging), or mocked with normal Kotlin tools instead of being tied to the multiplatform compiler machinery. It also avoids the ABI/versioning fragility that `expect class` has across Kotlin releases (see kmp_exp_04).

Question 2

How do you use expect/actual typealiases to map a shared multiplatform PlatformUUID type directly to the native UUID types on JVM/Android and iOS/Native, and what are the performance and zero-cost abstraction benefits compared to wrapper classes?

Accepted Answer

You declare the type as `expect class` in `commonMain` with no members you need to reimplement, then satisfy it on each platform with `actual typealias` pointing straight at the platform's real UUID type instead of writing an `actual class` that wraps it:
```kotlin
// commonMain
expect class PlatformUUID

// androidMain
actual typealias PlatformUUID = java.util.UUID

// iosMain
actual typealias PlatformUUID = platform.Foundation.NSUUID
```
Because `actual typealias` doesn't create a new class, there's no wrapper object allocated and no delegation layer — code in `commonMain` that receives a `PlatformUUID` compiles, on each platform, to direct calls against `java.util.UUID` or `NSUUID` respectively. There's zero runtime indirection: no extra `invokevirtual`/method-dispatch hop through a wrapper, no extra heap allocation per instance, and full interop (you can pass the value straight into any platform API expecting a real `UUID`/`NSUUID`).

The trade-off is that `commonMain` can only call members that exist identically (in name and signature) on both real types, which is rarely the case for anything beyond `toString()`. In practice this pattern is used for simple value types (UUIDs, timestamps as epoch millis, byte arrays) rather than for anything with rich, divergent platform APIs — for those, a real wrapper interface (like in kmp_exp_01) is worth the small allocation cost.

Question 3

In commonMain, the standard IO dispatcher is unavailable on legacy native targets or requires specific configuration. How do you construct an expect/actual background Coroutine dispatcher abstraction that maps to a real IO dispatcher on Android/JVM and a multithreaded queue dispatcher on iOS/Native?

Accepted Answer

You define an `expect val` (or `expect fun`) in `commonMain` that returns a `CoroutineDispatcher`, then let each platform supply what's actually appropriate for background I/O there:
```kotlin
// commonMain
expect val ioDispatcher: CoroutineDispatcher

// androidMain / jvmMain
actual val ioDispatcher: CoroutineDispatcher = Dispatchers.IO

// iosMain
actual val ioDispatcher: CoroutineDispatcher =
    newFixedThreadPoolContext(4, "IO-Pool")
```
On the JVM, `Dispatchers.IO` is backed by a large, elastic thread pool tuned for blocking calls, so there's nothing to build — you reuse it. On Kotlin/Native, there's no equivalent shared elastic pool baked into the standard library the same way, so you create your own fixed-size worker-backed dispatcher (`newFixedThreadPoolContext`) to move blocking file/network/database work off the main thread, since blocking the main thread on iOS freezes the UI immediately.

The key thing shared repository code needs to remember is to wrap blocking calls with `withContext(ioDispatcher)` rather than assuming a specific dispatcher exists globally — that keeps `commonMain` code portable while each platform controls its own concurrency primitives and thread-pool sizing.

Question 4

Compiling a KMP library with a recent Kotlin version generates warnings that expect/actual classifier declarations are in Beta and may cause binary compatibility issues. How do you audit your multiplatform architecture and migrate to interface-based dependency injection to ensure ABI stability?

Accepted Answer

The warning exists because `expect`/`actual` *classes* (not functions/properties) don't yet have a fully stabilized binary representation across Kotlin releases — the compiler can change how it mangles and links these declarations between versions, which is dangerous for a published library whose consumers pin different Kotlin versions than the library itself was built with. Functions and properties marked `expect`/`actual` don't have this problem; only classifiers (classes, and to a lesser extent interfaces with default actuals) do.

To audit, grep the codebase for `expect class` / `expect abstract class` declarations and classify each one: is it a data holder that could become a plain shared class, or does it truly need per-platform implementation? For the latter, replace the pattern with a shared interface plus an `expect fun` factory, matching the fix from kmp_exp_01:
```kotlin
// Before
expect class Analytics { fun track(event: String) }

// After
interface Analytics { fun track(event: String) }
expect fun createAnalytics(): Analytics
```
Functions and top-level factory declarations have a stable, well-understood ABI, so consumers building against a different (compatible) Kotlin version than the library was compiled with won't hit link errors. Run `kotlinx-binary-compatibility-validator` (see kmp_gen_016) as part of this migration to lock in the new public API surface and catch accidental future breaks.

Question 5

You are sharing a database layer across Android and iOS using SQLDelight. How do you configure schema migrations, handle asynchronous queries across different platform drivers, and ensure queries execute off the main thread on iOS without freezing the UI?

Accepted Answer

SQLDelight versions your schema with numbered `.sqm` migration files (`1.sqm`, `2.sqm`, ...) sitting alongside your `.sq` files; each migration is plain SQL (`ALTER TABLE ...`) that SQLDelight applies in order when it detects the on-disk database is behind the current schema version. The driver you construct is what actually runs those migrations at startup:
```kotlin
// commonMain
expect class DatabaseDriverFactory {
    fun createDriver(): SqlDriver
}

// androidMain
actual class DatabaseDriverFactory(private val context: Context) {
    actual fun createDriver(): SqlDriver =
        AndroidSqliteDriver(AppDatabase.Schema, context, "app.db")
}

// iosMain
actual class DatabaseDriverFactory {
    actual fun createDriver(): SqlDriver =
        NativeSqliteDriver(AppDatabase.Schema, "app.db")
}
```
Both `AndroidSqliteDriver` and `NativeSqliteDriver` run `Schema.migrate()` automatically against the stored `user_version` when they're first created, so you don't call migrations manually.

For threading: SQLDelight's generated queries are synchronous by nature, so in `commonMain` you wrap every call with `withContext(ioDispatcher)` (the dispatcher from kmp_exp_03) before executing a query, rather than calling it directly from a UI-bound coroutine scope. `NativeSqliteDriver` internally serializes access through its own connection pool/worker, but that only protects the database from concurrent-access corruption — it does *not* move the caller off the main thread for you, so the `withContext` wrapping on the repository layer is still required to avoid janking the iOS UI.

Question 6

Design a shared networking repository using Ktor Client with an OkHttp engine on Android and a Darwin engine on iOS. How do you configure platform-specific TLS certificate pinning and proxy authentication within the shared multiplatform client configuration?

Accepted Answer

You keep the `HttpClient` construction itself in `commonMain` (headers, content negotiation, timeouts, logging) but delegate the actual `HttpClientEngine` — where TLS pinning lives — to an `expect`/`actual` factory, because certificate pinning APIs are entirely engine-specific and can't be expressed in common code:
```kotlin
// commonMain
expect fun httpClientEngine(): HttpClientEngine

fun createHttpClient() = HttpClient(httpClientEngine()) {
    install(ContentNegotiation) { json() }
}

// androidMain — OkHttp engine
actual fun httpClientEngine(): HttpClientEngine = OkHttp.create {
    config {
        certificatePinner(
            CertificatePinner.Builder()
                .add("api.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
                .build()
        )
        proxyAuthenticator { _, response -> /* basic auth challenge */ null }
    }
}

// iosMain — Darwin engine
actual fun httpClientEngine(): HttpClientEngine = Darwin.create {
    configureSession {
        // NSURLSessionDelegate hook for server-trust evaluation / pinning
        setChallengeHandler { _, _, challenge, completionHandler -> /* validate SecTrust against pinned cert */ }
    }
}
```
On Android, OkHttp's `CertificatePinner` compares the SHA-256 of the presented cert's public key against the pinned hash at the TLS handshake. On iOS, Darwin's engine gives you a `URLSession` challenge handler where you manually evaluate `SecTrust` against a bundled certificate/public key.

Proxy authentication is similarly engine-native: OkHttp exposes a `proxyAuthenticator`, while Darwin relies on the `URLSession` challenge callback responding to `NSURLAuthenticationMethodNTLM`/basic proxy challenges. Keeping this split at the engine-factory boundary means `commonMain`'s repository code never needs to know which platform it's running on — it just calls `createHttpClient()`.

Question 7

An API returns a polymorphic list of UI widget configurations. How do you configure kotlinx.serialization with polymorphic serializers and sealed class hierarchies in commonMain so that both Android and iOS can serialize and deserialize dynamic JSON payloads reliably?

Accepted Answer

Model the widget types as a `sealed class` (or `sealed interface`) hierarchy annotated `@Serializable`, and register each subtype against a discriminator with `@SerialName`. kotlinx.serialization reads a `type` field (configurable) in the JSON to decide which subclass to deserialize into:
```kotlin
@Serializable
sealed class WidgetConfig {
    @Serializable
    @SerialName("text")
    data class Text(val content: String, val size: Int) : WidgetConfig()

@Serializable
    @SerialName("image")
    data class Image(val url: String) : WidgetConfig()
}

val json = Json {
    classDiscriminator = "type"
    ignoreUnknownKeys = true
}

val widgets: List<WidgetConfig> = json.decodeFromString(rawJson)
```
Because this all lives in `commonMain` and kotlinx.serialization's plugin generates the (de)serializers at compile time (not via reflection), the exact same `Json` instance and sealed hierarchy work identically on Android (JVM) and iOS (Native) — there's no platform-specific reflection API to worry about, which is normally a blocker for polymorphic JSON on Kotlin/Native.

`ignoreUnknownKeys = true` matters here specifically for a widget-config feed: it means the backend can add a brand-new widget type or extra fields without breaking already-shipped app versions, as long as you also add a default/`Unknown` fallback subtype for types the client doesn't recognize yet, rather than crashing the whole decode.

Question 8

You are sharing a KMP ViewModel that exposes a StateFlow view-state. How do you collect this flow safely in Jetpack Compose on Android using a lifecycle-aware collector while consuming it as a native async sequence or publisher in SwiftUI without leaking coroutine scopes on iOS?

Accepted Answer

On Android, since the ViewModel is a real `androidx.lifecycle.ViewModel` (or wraps one), Compose just uses the standard lifecycle-aware collector so the flow stops collecting when the screen isn't visible and resumes on `STARTED`:
```kotlin
val state by viewModel.uiState.collectAsStateWithLifecycle()
```
iOS has no `ViewModel`/lifecycle owner, so you can't `collect` a `StateFlow` directly from Swift — Swift doesn't understand suspend functions or Kotlin `Flow`. The shared ViewModel exposes a plain callback-subscribe method built on top of the StateFlow instead:
```kotlin
// commonMain / shared ViewModel
fun observeState(onUpdate: (UiState) -> Unit): Closeable {
    val job = viewModelScope.launch {
        uiState.collect { onUpdate(it) }
    }
    return Closeable { job.cancel() }
}
```
SwiftUI then calls `observeState` in `.onAppear` and stores the returned `Closeable`, cancelling it in `.onDisappear` (or in `deinit`) — that's what prevents leaking the coroutine job, since nothing on the Kotlin side knows about SwiftUI's view lifecycle without being told explicitly. Newer setups can skip hand-writing this bridge by using the KMP-NativeCoroutines or SKIE (kmp_gen_022) libraries, which auto-generate a native `AsyncSequence`/`Publisher` wrapper around a `Flow` so Swift can `for await` over it directly, with cancellation tied to Swift's own `Task` cancellation instead of a manually-managed `Closeable`.

Question 9

How do you configure a dependency injection framework in commonMain to assemble shared ViewModels, repositories, and use-cases, while allowing platform-specific modules (e.g., Android Context and iOS UserDefaults) to be injected cleanly at application startup?

Accepted Answer

With Koin, you define the shared graph as a plain `commonMain` module — repositories, use-cases, and ViewModels that don't need anything platform-specific — and an `expect fun platformModule(): Module` for the pieces that do:
```kotlin
// commonMain
val sharedModule = module {
    single { UserRepository(get()) }
    factory { GetUserUseCase(get()) }
    factory { UserViewModel(get()) }
}
expect fun platformModule(): Module

fun initKoin(extra: List<Module> = emptyList()) = startKoin {
    modules(sharedModule, platformModule(), *extra.toTypedArray())
}
```
```kotlin
// androidMain
actual fun platformModule() = module {
    single { androidContext().getSharedPreferences("app", MODE_PRIVATE) }
}

// iosMain
actual fun platformModule() = module {
    single { NSUserDefaults.standardUserDefaults }
}
```
On Android, `initKoin` is called from `Application.onCreate()` with `androidContext(this)` passed in via Koin's Android extension so `androidContext()` resolves inside `platformModule()`. On iOS, it's called once from `AppDelegate`/`@main App init`, with no context object needed since `NSUserDefaults.standardUserDefaults` is a global singleton.

The important design point is that `UserRepository` and `UserViewModel` only ever declare dependencies on interfaces/abstractions (`get()` resolves whatever's bound), so the exact same shared-module code works whether the underlying preference store is `SharedPreferences` or `NSUserDefaults` — Koin resolves that at the platform module boundary, not inside shared business logic.

Question 10

Your KMP module needs to integrate a proprietary third-party C/Objective-C iOS SDK. Walk through creating a cinterop definition file, configuring cinterop in Gradle, handling C pointer types in Kotlin, and linking the native framework into the iOS build target.

Accepted Answer

You start with a `.def` file describing the headers and linker flags cinterop needs to generate Kotlin bindings: ``` # src/nativeInterop/cinterop/thirdPartySdk.def language = Objective-C headers = ThirdPartySDK/ThirdPartySDK.h compilerOpts = -framework ThirdPartySDK linkerOpts = -framework ThirdPartySDK -F$projectDir/Frameworks ``` Then wire it into the iOS target in `build.gradle.kts`: ```kotlin kotlin { iosArm64 { compilations.getByName("main") { cinterops.create("thirdPartySdk") { defFile(project.file("src/nativeInterop/cinterop/thirdPartySdk.def")) } } binaries.getTest("DEBUG").linkerOpts("-F$projectDir/Frameworks") } } ``` Running the build generates a Kotlin `.klib` with bindings — Objective-C classes become Kotlin classes, C structs become Kotlin value classes, and raw C pointers surface as `CPointer` (or `CValuesRef` for structs passed by value). You interact with them via `memScoped { }` blocks for stack-allocated native memory, and `.reinterpret()`/`.pointed` to dereference, e.g. `val buffer = allocArray(size)` inside a `memScoped` to get a `CPointer` you can hand to the C API. Finally, the compiled `.framework` (or `.xcframework`, see kmp_build_01) that embeds this cinterop module needs the third-party framework physically present at the linker path referenced in `linkerOpts` — typically vendored into a `Frameworks/` directory and added to the Xcode project's "Frameworks, Libraries, and Embedded Content" so it's both linked at compile time and embedded/signed in the final app bundle.

Question 11

When using Compose Multiplatform for iOS, UI rendering is powered by a Skia-based canvas rendering engine inside a hosting view controller. Explain the performance and accessibility trade-offs compared to native SwiftUI components, particularly regarding native text editing and VoiceOver support.

Accepted Answer

Compose Multiplatform for iOS renders everything — text, shapes, images — onto a single Skia canvas hosted inside one `UIViewController`, rather than composing real `UIView`/`UIKit` elements the way SwiftUI does under the hood. This gives you pixel-identical UI across Android and iOS and avoids re-implementing layout per platform, but it also means the OS doesn't see individual widgets — from UIKit's point of view there's just one big view being painted by Skia.

Text editing is the sharpest trade-off: native text fields get you the system keyboard's autocomplete, secure-text handling, cursor/selection gestures, and IME behavior for free, because `UITextField`/`UITextView` are real UIKit responders. Compose's `TextField` on iOS has historically had to reimplement cursor rendering, selection handles, and keyboard-input bridging manually (via a hidden native input proxy), so subtle native-feeling behaviors (long-press magnifier, system autofill, spell-check UI) lag behind or need explicit workarounds — some teams drop to a `UIKitView` interop wrapper around a real `UITextField` for critical input fields specifically to get this back.

VoiceOver has a similar story: UIKit's accessibility tree is built automatically from real view hierarchies, but a Skia-canvas UI has no view hierarchy for the OS to introspect, so Compose Multiplatform has to publish an explicit accessibility tree via semantics modifiers (`Modifier.semantics { ... }`) mapped onto `UIAccessibilityElement`s under the hood. This works, but it's more manual — every custom composable needs deliberate semantics annotation, whereas a native `SwiftUI Text`/`Button` is accessible by default with zero extra code.

Question 12

Exporting Kotlin shared code to iOS historically generates Objective-C bridging headers where Kotlin sealed interfaces and default parameters produce mangled, awkward Swift APIs. How does newer Direct Swift Export tooling improve native Swift ergonomic interop?

Accepted Answer

The old pipeline is Kotlin → Objective-C header → Swift, and Objective-C simply can't express several Kotlin language features. A `sealed class` with subclasses shows up in Swift as a base class with unavailable-looking `init` methods and a flat `is`-check pattern instead of an exhaustive `switch`; default parameter values disappear and get expanded into multiple overloaded methods with awkward suffixes (`doThing()`, `doThingWithCount(count:)`); Kotlin's nullability sometimes gets flattened to Objective-C's more permissive optional semantics, losing some of the non-null guarantees the Kotlin code actually has.

Direct Swift Export (built on the K2 compiler front-end) skips the Objective-C intermediate step entirely and compiles Kotlin declarations straight into real Swift API surface. A Kotlin sealed class can be exported closer to an actual Swift representation that supports pattern matching more naturally, default parameters map to genuine Swift default arguments (`func doThing(count: Int = 1)`) instead of overload explosion, and named parameters/labels come through as idiomatic Swift call sites (`viewModel.submit(form: form, retry: true)`) instead of the older Objective-C-style flattened argument names.

The practical effect for a team maintaining a Kotlin-Swift boundary is less hand-written bridging/wrapper code on the Swift side just to make the generated API feel native, and fewer surprises where a Kotlin API that looks clean in `commonMain` turns into something clunky once it crosses to Swift.

Question 13

Explain how Kotlin/Native's garbage-collected memory model manages references across the Swift ARC / Kotlin GC boundary, and how circular references between a Swift UI delegate and a Kotlin shared presenter can cause silent memory leaks.

Accepted Answer

Kotlin/Native's current memory model uses a tracing garbage collector (like the JVM), while Swift/Objective-C objects are reference-counted via ARC. At the boundary, each side wraps the other in a way its own memory management understands: a Kotlin object exposed to Swift is backed by a retain-counted proxy so ARC can hold and release it normally, and a Swift/Objective-C object referenced from Kotlin is tracked by Kotlin's GC as a normal object it can trace and collect.

The problem is that neither side's memory manager can see *through* the other's reference graph. If a Swift `ViewController` holds a strong reference to a Kotlin `Presenter`, and that `Presenter` holds a strong reference back to the `ViewController` as a delegate (e.g. to call `showError()`), you've created a cycle that spans both runtimes. ARC's retain-count-based collection can't detect this cycle because part of it lives in Kotlin's GC-managed heap, and Kotlin's tracing GC can't detect it either because it can't fully trace through the ARC-managed Swift side. Neither garbage collector considers the object unreachable, so it just leaks silently — no crash, no warning, just growing memory over the app's lifetime.

The fix is the same one you'd use for a same-language delegate cycle: break the reference in one direction, typically by declaring the delegate reference as `weak var delegate: PresenterDelegate?` on the Swift side, or having the Kotlin presenter never hold a persistent reference to its UI delegate at all — passing it in per-call, or clearing it explicitly in a `onCleared()`/`deinit` hook tied to the screen's lifecycle.

Question 14

Configure a Gradle task using XCFramework to bundle multiple iOS target architectures into a single universal binary artifact suitable for distribution via Swift Package Manager (SPM) in a continuous integration pipeline.

Accepted Answer

You declare the iOS targets you need (device + simulator, both architectures for Apple Silicon and Intel Macs) and wrap their framework outputs in a single `XCFramework` block:
```kotlin
kotlin {
    val xcf = XCFramework("Shared")
    listOf(iosArm64(), iosSimulatorArm64(), iosX64()).forEach { target ->
        target.binaries.framework {
            baseName = "Shared"
            isStatic = true
            xcf.add(this)
        }
    }
}
```
Running `./gradlew assembleSharedXCFramework` (or `assembleSharedDebugXCFramework`/`Release`) produces one `.xcframework` bundle in `build/XCFrameworks/` containing per-slice binaries for real devices and both simulator architectures, so Xcode/SPM picks the right slice automatically at build time instead of you needing separate artifacts (or a manually-lipo'd fat binary, which Apple no longer accepts for device+simulator combos on Apple Silicon anyway).

In CI, the pipeline runs that Gradle task, then either zips the `.xcframework` and computes its checksum for a remote SPM `binaryTarget(url:, checksum:)` declaration, or commits it into a local SPM package that the iOS app's `Package.swift` references directly — the CI step just needs to run before the Xcode/SPM build step so the framework exists when SPM tries to resolve it.

Question 15

Your engineering organization is migrating its KMP integration from the CocoaPods Gradle plugin to native Swift Package Manager (SPM) direct embedding. How do you configure Xcode build phases and handle local dependency linking during debug builds?

Accepted Answer

First, remove the `cocoapods { ... }` block from `build.gradle.kts` and replace it with a plain native framework declaration, since SPM doesn't understand Podspecs:
```kotlin
kotlin {
    listOf(iosArm64(), iosSimulatorArm64()).forEach {
        it.binaries.framework {
            baseName = "Shared"
            isStatic = true
        }
    }
}
```
Instead of CocoaPods' `pod install` generating a workspace that wires everything automatically, SPM needs a `Package.swift` with a `binaryTarget` pointing at either a pre-built `.xcframework` (for CI/release, per kmp_build_01) or, for local development, a `Run Script` build phase in Xcode that runs `./gradlew :shared:assembleSharedDebugXCFramework` *before* SPM tries to resolve the package, so the binary exists on disk when Xcode needs it.

The tricky part is debug-build iteration speed: CocoaPods users were used to just hitting "Run" and letting the existing Gradle-integration script rebuild the framework inline. With SPM's binaryTarget approach, you add a Build Phase (positioned *before* "Compile Sources", under Target → Build Phases → "+" → New Run Script Phase) that shells out to Gradle, and mark its output the `.xcframework` path so Xcode's incremental build system knows to re-run it when Kotlin sources change (via `outputFiles`/`inputFileLists` on the script phase) — otherwise Xcode may cache and skip the script, and the app silently runs against a stale shared framework.

Question 16

A large KMP project with 30 modules suffers from 4-minute incremental build times in Xcode. How do you enable Gradle Configuration Cache, tune Kotlin/Native compiler cinterop caching, and filter compilation targets during local iOS development to achieve sub-10-second builds?

Accepted Answer

The biggest single win is usually not rebuilding targets you don't need locally. A 30-module project targeting `iosArm64`, `iosSimulatorArm64`, `iosX64`, plus Android/JVM will, by default, compile all of them every time Xcode's build-phase script invokes Gradle — but a developer running the simulator on an M-series Mac only needs `iosSimulatorArm64`. Gate the target list behind a Gradle property read from `local.properties` or an env var:
```kotlin
val enabledTargets = (findProperty("kmp.targets") as String?)
    ?.split(",") ?: listOf("iosSimulatorArm64", "android")
// only apply framework/binaries config for targets in enabledTargets
```
Second, enable Gradle's configuration cache and build cache in `gradle.properties`:
```properties
org.gradle.configuration-cache=true
org.gradle.caching=true
org.gradle.parallel=true
kotlin.native.cacheKind=static
```
`kotlin.native.cacheKind=static` (or the newer incremental native caching flags) lets the Kotlin/Native compiler reuse previously-compiled klib caches for unchanged dependencies instead of recompiling the whole native compilation unit on every invocation — this specifically targets Kotlin/Native's historically slow cold-compile time, which is the dominant cost in cinterop-heavy projects.

Third, make sure the Xcode "Run Script" build phase that invokes Gradle declares proper `inputFileLists`/`outputFiles` so Xcode's own incremental build system can skip it entirely when nothing Kotlin-related changed, rather than shelling out to Gradle (which has its own up-to-date checks, but the process-spawn + Gradle-daemon-handshake overhead alone can cost several seconds even on a no-op build). Combined, these three changes — target filtering, configuration/build cache, and native compilation caching — are what typically take a 4-minute loop down to single-digit seconds for a no-op or small-change rebuild.

Question 17

How do you configure Kotlin's default source set hierarchy in Gradle to share code across iOS and macOS targets without duplicating platform implementations or creating cyclic source-set dependencies?

Accepted Answer

Since Kotlin 1.9.20, the Kotlin Gradle plugin applies a "default hierarchy template" automatically once you declare your targets — you don't hand-wire `dependsOn` between source sets yourself anymore. Declaring `iosArm64()`, `iosSimulatorArm64()`, and `macosArm64()` causes the plugin to automatically create and wire an intermediate `appleMain`/`appleTest` source set (and a broader `nativeMain` above that) that all Apple targets depend on:
```kotlin
kotlin {
    iosArm64()
    iosSimulatorArm64()
    macosArm64()
    sourceSets {
        val appleMain by getting {
            // shared iOS + macOS code goes here — e.g. Foundation-based date parsing
        }
    }
}
```
Code that's identical across iOS and macOS — anything using `Foundation`/`CoreFoundation` APIs common to both Apple platforms, for instance — goes in `appleMain` instead of being duplicated in `iosMain` and `macosMain` separately. Kotlin resolves the hierarchy as a DAG (`commonMain` → `nativeMain` → `appleMain` → `iosMain`/`macosMain`), so there's no cycle risk as long as you only add code to the appropriate level and don't manually add cross-dependencies between sibling source sets (e.g. `iosMain` depending on `macosMain` directly) — the template's whole point is that shared code moves *up* the hierarchy to a common ancestor instead of one leaf depending on another leaf.

Question 18

What is Kotlin Multiplatform and what core problem does it solve for mobile teams?

Accepted Answer

Kotlin Multiplatform (KMP) is a feature of the Kotlin compiler that lets you write business logic once — networking, data models, validation, database access, view-state management — and compile that same source to run natively on Android (JVM), iOS (Native, no VM), and optionally web, desktop, and server targets, while still letting each platform keep its own native UI.

The problem it solves is the duplicate-logic tax that comes from maintaining fully separate Android and iOS codebases: the same "is this email valid," "how do I retry a failed request," or "how do I parse this API response" logic historically got written twice, in Kotlin and Swift, and inevitably drifted out of sync as bugs got fixed in one place and not the other.

For example, a team might put `UserRepository`, `LoginValidator`, and the networking layer in a `shared` KMP module, then have the Android app consume it directly as a Kotlin dependency and the iOS app consume it as a compiled `.framework` imported into Swift — both apps calling the exact same `validateEmail()` function, compiled from the exact same source. Unlike Flutter or React Native, the UI layer itself stays fully native (unless you opt into Compose Multiplatform, see kmp_gen_026), so the app still looks and feels like a normal iOS/Android app.

Question 19

What is the difference between Kotlin Multiplatform (KMP) and Kotlin Multiplatform Mobile (KMM)?

Accepted Answer

They're the same underlying technology — KMM was JetBrains' branding specifically for the "share code between Android and iOS" use case, with its own dedicated tooling (an Android Studio plugin, a project wizard, its own docs site). Kotlin Multiplatform is the broader, more general compiler feature that also covers desktop, web (JS/Wasm), and server (JVM) targets, not just mobile.

In 2023 JetBrains folded the KMM name back into the general "Kotlin Multiplatform" branding and retired the separate KMM plugin/wizard — everything now goes through the single Kotlin Multiplatform plugin and project templates. So today, if someone says "KMM," they almost always mean the Android+iOS sharing use case specifically, but the actual technology, Gradle plugin, and terminology in current docs is just "KMP." There's no functional difference left to configure differently — it's purely a naming/history distinction at this point.

Question 20

What are source sets in a KMP project, and what do commonMain, androidMain, and iosMain each contain?

Accepted Answer

A source set is just a named folder of Kotlin source files plus its own dependencies, scoped to which target(s) that code compiles for. `commonMain` holds code compiled for every target the module declares — this is where the bulk of shared business logic, models, and `expect` declarations live. `androidMain` and `iosMain` hold code that only compiles for their respective platform — this is where `actual` implementations, and any platform API calls (Android `Context`, iOS `Foundation`/`UIKit` types) go.

For example, a `NetworkClient` interface and the request/response data classes live in `commonMain`; the `expect fun httpClientEngine()` declaration also lives in `commonMain`, but its two `actual` bodies — one using OkHttp, one using Darwin — live in `androidMain` and `iosMain` respectively. Each source set also has a matching `*Test` counterpart (`commonTest`, `androidUnitTest`, `iosTest`) for tests scoped the same way. Modern KMP projects with more than two native targets typically also have intermediate source sets like `appleMain` or `nativeMain` sitting between `commonMain` and the platform-specific ones (see kmp_build_04).

Question 21

Write a simple expect/actual example for getting the device platform name.

Accepted Answer

This is the canonical "hello world" of KMP — a single function whose implementation genuinely differs per platform, declared once in `commonMain` and implemented once per target:
```kotlin
// commonMain
expect fun platformName(): String

fun greeting(): String = "Running on ${platformName()}"
```
```kotlin
// androidMain
actual fun platformName(): String = "Android ${android.os.Build.VERSION.SDK_INT}"

// iosMain
actual fun platformName(): String =
    platform.UIKit.UIDevice.currentDevice.systemName() +
    " " + platform.UIKit.UIDevice.currentDevice.systemVersion
```
The compiler enforces that every declared target has a matching `actual` — if you add a `jsMain` target and forget to implement `platformName()` there, the build fails at compile time rather than at runtime, which is the main safety guarantee `expect`/`actual` gives you over, say, reflection-based platform detection.

Question 22

What is the difference between the Kotlin/JVM, Kotlin/Native, and Kotlin/JS compiler backends?

Accepted Answer

Kotlin/JVM compiles Kotlin to standard `.class` bytecode that runs on any JVM — this is what powers the Android target and any regular JVM/server module, and it relies on the JVM's garbage collector, class loading, and reflection.

Kotlin/Native compiles Kotlin directly to native machine code (via LLVM) with no VM involved at all — this is what makes it possible to run Kotlin on iOS, where Apple doesn't allow shipping a JIT/VM-based runtime for third-party apps. It ships its own garbage collector and its own concurrency/memory model, entirely separate from the JVM's.

Kotlin/JS compiles Kotlin to JavaScript (either targeting the browser or Node.js), so it can run inside a web page or in a JS runtime with no native binary at all; there's also a newer Kotlin/Wasm backend (kmp_gen_017) that compiles to WebAssembly instead of JS text output. A single `commonMain` module can target all three backends simultaneously — the same `UserRepository` class can end up compiled three completely different ways depending on which target is building it, which is exactly what makes KMP "multiplatform" rather than "cross-compiled to one runtime."

Question 23

What is Compose Multiplatform and how is it related to Jetpack Compose?

Accepted Answer

Compose Multiplatform is JetBrains' extension of Google's Jetpack Compose UI toolkit to run outside Android — on iOS, desktop (Windows/macOS/Linux via JVM), and web. It reuses the exact same declarative composable-function programming model (`@Composable fun`, `remember`, `mutableStateOf`) and, on Android specifically, *is* Jetpack Compose — there's no separate rendering engine there. On the other targets, it's rendered via Skia (the same 2D graphics library Chrome and Android itself use internally) instead of going through each OS's native UI toolkit.

The practical implication: a team can share not just business logic but the entire UI layer across platforms by writing composables once in `commonMain`, at the cost of losing some native platform-specific behaviors — see kmp_native_02 for the concrete trade-offs on iOS around text input and VoiceOver. Teams that want fully native UI per platform (SwiftUI on iOS, Jetpack Compose on Android) use plain KMP for shared logic only and skip Compose Multiplatform's UI-sharing layer entirely — both are valid, coexisting strategies (kmp_gen_026).

Question 24

Why can't you use Retrofit directly in commonMain, and what do you use instead for shared networking?

Accepted Answer

Retrofit is a JVM-only library — it's built on `java.lang.reflect` (to generate implementations of your `@GET`/`@POST` interfaces at runtime) and on OkHttp specifically as its transport. Kotlin/Native has no JVM reflection API and doesn't run OkHttp at all, so Retrofit simply cannot compile against `commonMain`, let alone run on iOS.

The standard replacement is Ktor Client, which is a Kotlin-first HTTP client explicitly built with multiplatform in mind — the same `HttpClient` API works in `commonMain`, and you plug in a different *engine* per platform (OkHttp or Android's built-in engine on Android/JVM, Darwin on iOS/macOS, Js on web). This is exactly the pattern shown in kmp_logic_02: the request-building and response-parsing code lives once in `commonMain`, and only the low-level engine wiring (like TLS pinning) differs per platform. There's no reflection involved anywhere — Ktor's request builders and content negotiation are plain Kotlin function calls and kotlinx.serialization, both of which compile cleanly to Kotlin/Native.

Question 25

How does kotlinx.coroutines support multiplatform concurrency, and what's different about Dispatchers.Default vs Dispatchers.Main across platforms?

Accepted Answer

kotlinx.coroutines ships a multiplatform artifact with the same `suspend`/`Flow`/`CoroutineScope` API surface across JVM, Native, and JS — `launch`, `async`, `withContext`, structured concurrency, and cancellation all behave the same conceptually regardless of target, which is what lets shared repository/use-case code written once in `commonMain` run identically on Android and iOS.

What differs is what the built-in dispatchers actually map to underneath. `Dispatchers.Default` is a CPU-bound thread pool sized to the number of cores on both JVM and Native — on Android that's a real JVM thread pool, on iOS/Native it's backed by worker threads managed by Kotlin/Native's own runtime. `Dispatchers.Main` is more platform-specific: on Android it dispatches onto the Android main/UI thread's `Looper`; on iOS it dispatches onto the native main run loop (via a Native-specific `Dispatchers.Main` implementation using `NSRunLoop`/GCD's main queue). There's deliberately no `Dispatchers.IO` guaranteed to exist identically everywhere — that's exactly why teams build the `expect`/`actual` IO dispatcher shown in kmp_exp_03 rather than assuming one dispatcher name works the same way on every target.

Question 26

How are Kotlin suspend functions exposed to Swift when calling shared code from iOS?

Accepted Answer

The Objective-C/Swift interop layer has no concept of Kotlin's `suspend` keyword, so the Kotlin/Native compiler transforms every exported `suspend fun` into a regular function that takes a completion-handler closure and returns immediately:
```kotlin
// commonMain / iosMain
suspend fun fetchUser(id: String): User
```
from Swift, this shows up roughly as:
```swift
repository.fetchUser(id: "42") { user, error in
    if let error = error { /* handle */ }
    else { /* use user */ }
}
```
Under the hood the coroutine still runs on a Kotlin coroutine dispatcher; the generated wrapper just bridges its completion back into a plain callback Swift can consume, since Swift (pre-`async`/`await` bridging tooling) has no native equivalent of a suspend function to call directly.

Newer tooling improves the ergonomics considerably: libraries like KMP-NativeCoroutines generate an actual Swift `async`/`await`-compatible wrapper on top of that same completion-handler mechanism, so you can write `let user = try await repository.fetchUser(id: "42")` instead of nesting callbacks — and Direct Swift Export (kmp_native_03) aims to make this bridging closer to a first-class compiler feature rather than a generated-wrapper workaround.

Question 27

What was Kotlin/Native's old memory model, what did freeze() do, and why was it removed in the new memory model (Kotlin 1.7.20+)?

Accepted Answer

Before Kotlin 1.7.20's new memory model became default, Kotlin/Native enforced a strict rule: a mutable object could only be accessed from the single thread that created it, *unless* you explicitly called `.freeze()` on it, which made the object (and everything it transitively referenced) permanently immutable and safe to share across threads. Trying to mutate a frozen object at runtime threw an `InvalidMutabilityException` — a purely native-only failure mode with no JVM equivalent, which made shared `commonMain` code that assumed normal JVM-style mutable state break in confusing, native-only ways.

This was painful in practice: a `MutableStateFlow` you wanted to observe from a background thread on iOS had to have its backing state frozen, but freezing was viral (freezing an object froze its whole reference graph), so it was easy to accidentally freeze something you still needed to mutate elsewhere, or to leak a frozen object into code that expected to write to it and get a runtime crash with a stack trace that gave little indication of the real cause.

The new memory model replaced this with a proper tracing garbage collector (much closer to how the JVM works) that allows normal cross-thread references and mutation without freezing, using synchronization primitives instead of an all-or-nothing frozen/unfrozen state. `freeze()` still exists as a deprecated no-op-ish legacy API for migration compatibility, but new code should just use ordinary `Mutex`/`AtomicReference`-based synchronization (kmp_gen_031) the same way you would on the JVM, since the strict single-thread-ownership restriction no longer exists.

Question 28

How do you write and run unit tests that execute against every KMP target using kotlin.test?

Accepted Answer

You write tests once in `commonTest` using `kotlin.test`'s multiplatform assertion API (`assertEquals`, `assertTrue`, `@Test`), and Gradle compiles and runs that same test class separately against every declared target's own test runner:
```kotlin
// commonTest
class LoginValidatorTest {
    @Test
    fun `rejects empty email`() {
        assertFalse(LoginValidator.isValidEmail(""))
    }
}
```
Running `./gradlew allTests` (or `./gradlew check`) executes this same test class on the JVM (via JUnit under the hood for `androidUnitTest`/`jvmTest`) and also compiles and runs it as a native test binary for each configured Kotlin/Native target (e.g. `iosSimulatorArm64Test`), so a passing test genuinely proves the logic works correctly when compiled by both the JVM and Kotlin/Native backends — catching real backend-specific behavior differences (like differing floating-point rounding or platform-specific string formatting) that a single-target test suite would miss entirely.

Question 29

How do you fake or mock a platform-specific expect dependency when testing shared commonMain code?

Accepted Answer

Since `expect`/`actual` declarations are resolved per source set at compile time, you can't swap in a mock the way you would with a runtime DI container — instead, `commonTest` gets its own `actual` implementation, separate from the real `androidMain`/`iosMain` ones, purely for test purposes. If the `expect` is a class or function returning an interface, that interface is what makes this clean:
```kotlin
// commonMain
interface Clock { fun nowMillis(): Long }
expect fun createClock(): Clock

// commonTest
actual fun createClock(): Clock = object : Clock {
    override fun nowMillis() = 1_700_000_000_000L // fixed, deterministic
}
```
Because `commonTest` is itself a source set that participates in `expect`/`actual` resolution, this fake `createClock()` is used automatically whenever `commonTest` code (running as part of any target's test suite) calls it — you never touch the real Android/iOS `actual` implementations at all.

The cleaner alternative, and generally preferred, is to avoid putting the `expect`/`actual` at the boundary your business logic directly depends on in the first place — inject a plain `Clock` interface via constructor/DI (as in kmp_exp_01's SecureStorage redesign) so tests just pass a fake `Clock` instance like any other normal unit test, with no `expect`/`actual` machinery involved in the test at all.

Question 30

What problem does the multiplatform-settings library solve, and why not just write your own expect/actual key-value wrapper?

Accepted Answer

You *can* write your own `expect class Settings` wrapping `SharedPreferences` on Android and `NSUserDefaults` on iOS — it's a small enough surface area that plenty of teams do exactly that as their first pass. `multiplatform-settings` (by Russell Wolf) is a ready-made library that does the same thing, but has already solved the edge cases you'd hit writing it yourself: consistent behavior for missing keys, typed getters/setters (`Int`, `Boolean`, `String`, with proper defaults), a `Flow`-based reactive API for observing changes, and additional backends beyond just the two mobile platforms (browser `localStorage` for JS, in-memory for tests).

```kotlin
val settings: Settings = ... // platform-provided instance
settings.putBoolean("onboarding_complete", true)
val isDone: Boolean = settings.getBoolean("onboarding_complete", false)
```
The 80%-extension argument for reaching for the library instead of a hand-rolled wrapper is straightforward: a key-value settings abstraction is exactly the kind of "two real use cases already exist across the ecosystem" utility that's not worth re-deriving edge cases for (type coercion, null-key defaults, reactive observation) when a maintained, widely-used library already covers it — you'd only write your own if you needed something the library genuinely doesn't support, like encrypted storage (which circles back to the SecureStorage interface pattern in kmp_exp_01).

Question 31

Why is structured, leveled logging harder to get right in a KMP app than in a single-platform app, and what does a library like Kermit provide?

Accepted Answer

On Android alone you'd just call `Log.d(tag, message)`; on iOS you'd use `os_log` or `print`. Neither exists in `commonMain` — `android.util.Log` isn't available on Kotlin/Native, and there's no shared logging primitive in the Kotlin standard library at all, so shared repository/use-case code that wants to log has nothing built-in to call without an `expect`/`actual` wrapper of its own.

Kermit is a small multiplatform logging library that solves exactly this: a single `Logger` API usable from `commonMain` (`Logger.d { "fetching user $id" }`, `Logger.e(throwable) { "request failed" }`) that routes to `android.util.Log` on Android and to `NSLog`/`os_log` on iOS under the hood, plus configurable severity levels and the ability to attach custom "writers" (e.g. forwarding error-level logs to a crash-reporting SDK).

```kotlin
val logger = Logger.withTag("UserRepository")
logger.d { "Fetching user $id" }
logger.e(exception) { "Failed to fetch user $id" }
```
The value beyond just "it compiles on both platforms" is consistency — the same tag/level filtering behavior and the same call sites work everywhere, so you're not debugging with `println` on iOS and `Log.d` on Android and getting differently-formatted output from each.

Question 32

What is an XCFramework, and why do you need one instead of a plain .framework when supporting both iOS devices and simulators?

Accepted Answer

A plain `.framework` built by Kotlin/Native targets exactly one architecture/environment combination — say, `arm64` for real devices. Historically, teams combined a device build and a simulator build into one "fat" binary using `lipo`, but Apple Silicon Macs broke that trick: the simulator build for an M-series Mac is also `arm64`, the same architecture as a real iPhone, so `lipo` can no longer disambiguate them by architecture slice alone — you can't merge a device-`arm64` and simulator-`arm64` slice into one fat binary the old way.

An `XCFramework` solves this by being a *container* format rather than a single binary: it bundles multiple complete framework builds side by side, each tagged with its own platform+architecture+environment metadata (`ios-arm64`, `ios-arm64-simulator`, `ios-x86_64-simulator`), and Xcode/SPM picks the correct slice automatically based on what you're building for — no manual `lipo` merging needed, and no ambiguity even when two slices share the same CPU architecture.

This is exactly what the `XCFramework("Shared")` Gradle DSL block in kmp_build_01 produces — you declare `iosArm64()`, `iosSimulatorArm64()`, and (if still supporting Intel Macs) `iosX64()`, and the single `assembleSharedXCFramework` Gradle task packages all of them into one `.xcframework` you distribute as one artifact.

Question 33

What is kotlinx-binary-compatibility-validator and why does it matter for a published KMP library?

Accepted Answer

When you publish a KMP library (as opposed to an internal app module), any consumer might build against your library with a different — but supposedly compatible — Kotlin or library version than what you built and tested against. If you accidentally remove a public function, change a parameter type, or alter a class's public shape between releases, consumers get link/runtime errors that only surface when *they* build, often much later than when you actually broke it.

`kotlinx-binary-compatibility-validator` is a Gradle plugin that generates a `.api` file listing every public declaration's exact signature across all your targets, and fails the build if that signature set changes without you having deliberately updated ("approved") the dump file:
```kotlin
// build.gradle.kts
plugins {
    id("org.jetbrains.kotlinx.binary-compatibility-validator") version "..."
}
```
Running `./gradlew apiCheck` in CI catches an accidental breaking change (e.g. someone silently renamed a public function, or an `expect class` declaration's binary shape shifted the way described in kmp_exp_04) before it ships, and running `./gradlew apiDump` explicitly regenerates the approved `.api` snapshot when you *intend* to change the public surface — turning "did I just break ABI compatibility" from a manual code-review judgment call into an automated, enforced CI gate.

Question 34

What is Kotlin/Wasm, and where does it fit alongside JVM, Native, and JS as a Kotlin Multiplatform target?

Accepted Answer

Kotlin/Wasm is a compiler backend that compiles Kotlin directly to WebAssembly bytecode, as an alternative to the existing Kotlin/JS backend that compiles to JavaScript text. It's a separate target you can add to a KMP module (`wasmJs { browser() }`), sitting alongside `jvm()`, the various `ios*()`/`macos*()` native targets, and `js()` — a `commonMain` module can, in principle, target all of them from the same source.

The motivation is performance and interop consistency: WebAssembly runs closer to native speed in the browser than transpiled JavaScript, has a more predictable execution model (no JS-engine-specific JIT warm-up quirks), and — combined with the Wasm garbage-collection proposal (WasmGC) that modern browsers now support — lets Kotlin ship a real garbage-collected runtime in the browser without needing to emulate one in JS.

It's the newest and least mature of the mainstream KMP targets, so library support (does your networking/serialization/DI library actually publish a `wasmJs` artifact?) is the main practical gating factor before adopting it for anything beyond experimentation — Compose Multiplatform does have Wasm support for browser UI, which is the main current use case (a shared Compose UI running as a web app via Wasm rather than the older JS/Canvas rendering path).

Question 35

How does kotlinx-datetime help you avoid platform-specific date/time bugs in shared code?

Accepted Answer

`java.time` is JVM-only and Foundation's `NSDate`/`Calendar` is iOS-only, so neither can be used directly in `commonMain` — a shared repository that needs to compare timestamps or format a date has nothing built into the Kotlin standard library to reach for without an `expect`/`actual` wrapper.

kotlinx-datetime is JetBrains' own multiplatform date/time library providing a consistent set of types (`Instant`, `LocalDateTime`, `LocalDate`, `TimeZone`) usable identically from `commonMain`, backed by `java.time` on the JVM and by native platform APIs on Kotlin/Native under the hood — but the API surface you write against is the same everywhere:
```kotlin
val now: Instant = Clock.System.now()
val localTime: LocalDateTime = now.toLocalDateTime(TimeZone.currentSystemDefault())
val isExpired = now > Instant.parse("2026-01-01T00:00:00Z")
```
This avoids two classic multiplatform date bugs: writing your own naive epoch-millis math (which silently breaks around leap seconds, DST transitions, and calendar-specific edge cases), and having Android and iOS format or compare dates subtly differently because each was implemented against its own native date API by different engineers on different platform teams.

Question 36

What is a klib, and how does Kotlin/Native use it to distribute and consume compiled multiplatform library code?

Accepted Answer

A `.klib` ("Kotlin library") is Kotlin/Native's own compiled-artifact format — the native-target equivalent of a `.jar` on the JVM. When you compile a `commonMain`/`nativeMain` module (rather than linking a final executable or framework), the Kotlin/Native compiler produces a `.klib` containing serialized IR (intermediate representation) plus metadata describing the module's public declarations, rather than final machine code — actual native code generation happens later, when a *consuming* module links against that klib and compiles down to a real binary for a specific target.

This is why a single published KMP library artifact can be consumed by projects targeting different concrete Kotlin/Native platforms (`iosArm64`, `iosSimulatorArm64`, `macosArm64`, etc.) from what looks like one dependency coordinate — Gradle actually resolves a separate klib variant per target under the hood, and the final machine-code compilation happens in the consumer's build, using whatever target it's actually building for.

The practical relevance for day-to-day KMP work is mostly during dependency resolution debugging: if a library only publishes klibs for some native targets and you add a target it doesn't support, you get a "could not find klib for target X" style resolution error — checking a library's published target list (usually in its Maven/`.module` metadata or README) before adding it is the way to avoid discovering this only after adding the dependency.

Question 37

How would you structure a KMP project so the same networking and validation code is shared between an Android/iOS client and a Ktor-based JVM backend?

Accepted Answer

Since Ktor ships both a client (`io.ktor:ktor-client-*`) and a server (`io.ktor:ktor-server-*`) library with a genuinely multiplatform client API, you can put shared request/response data classes, validation logic, and even API-route path constants into a `commonMain` module that both the client apps and the server depend on:
```
shared-models/   -> commonMain: data classes, kotlinx.serialization, validators
client-app/      -> shared KMP module (Android + iOS), depends on shared-models
server/          -> plain JVM module, Ktor server, depends on shared-models
```
A `LoginRequest` data class and its `isValidEmail()` validator, both defined once in `shared-models`, get used identically by the Android/iOS app when building the request and by the Ktor server when validating an incoming payload — eliminating the classic client/server drift where a frontend's validation rule and a backend's validation rule for the "same" field silently diverge over time.

The server module itself doesn't need to be a KMP module at all — it's a normal Kotlin/JVM project — it just needs to depend on the shared `commonMain`-only artifact for the models/validators it wants to reuse, since JVM can always consume a klib/common Kotlin artifact even without needing to also target Native or JS itself.

Question 38

What does the @Throws annotation do in Kotlin/Native, and why is it necessary when a shared function that throws is called from Swift?

Accepted Answer

Swift's error handling model is checked at compile time via `throws`/`try` — a Swift function that can fail must be explicitly marked `throws`, and callers must explicitly `try` it. Kotlin's exceptions are unchecked (any function can throw anything without declaring it), so by default, when Kotlin/Native exports a function to Objective-C/Swift, it has no way to know which Kotlin exceptions, if any, should map to a Swift `throws` call versus just crashing/trapping at runtime if left unhandled.

`@Throws(SomeException::class)` tells the Kotlin/Native compiler exactly which exception types (and their subtypes) should be translated into a genuine Swift `throws` function signature at the interop boundary:
```kotlin
@Throws(NetworkException::class)
suspend fun fetchUser(id: String): User {
    if (id.isBlank()) throw NetworkException("invalid id")
    // ...
}
```
Without the annotation, that exception crossing into Swift as an *unchecked* Objective-C exception would, in the worst case, terminate the whole process rather than being catchable — Swift has no mechanism to `catch` an unchecked NSException the way Kotlin/JVM code can catch any `Throwable`. With `@Throws` declared, the generated Swift signature becomes `func fetchUser(id: String) async throws -> User`, letting Swift code wrap the call in a normal `do { } catch { }` block and handle the failure gracefully instead of crashing.

Question 39

How is a Kotlin Flow typically consumed from Swift, and what problem does a tool like SKIE solve compared to the default Objective-C-generated API?

Accepted Answer

By default, exporting a `Flow` to Objective-C/Swift produces a fairly raw, low-level interop surface — you get something like a `Kotlinx_coroutines_coreFlow` type with a `collect(collector:)` method that takes an Objective-C-style callback object, with none of Swift's native `AsyncSequence` ergonomics (`for await value in flow { }`) and generic type information often erased to `Any`/`AnyObject` on the Swift side, forcing manual casts. SKIE (from Touchlab) is a Kotlin compiler plugin that post-processes the generated Objective-C header/Swift interop layer specifically to make these APIs feel native: it turns exported `Flow`s into genuine Swift `AsyncSequence`/`SkieSwiftFlow` types you can `for await` over with the concrete generic type preserved, turns Kotlin sealed classes into proper Swift enums usable in exhaustive `switch` statements (addressing the same rough edge described in kmp_native_03), and generally removes a lot of boilerplate bridging code teams previously hand-wrote themselves: ```swift // with SKIE, roughly: for await state in viewModel.uiState { render(state) } ``` It's a build-time code-generation plugin rather than a runtime library, so it doesn't change what's actually running (still the same Kotlin coroutine machinery underneath) — it just changes the *shape* of the generated Swift API surface to be idiomatic instead of a raw Objective-C-interop artifact.

Question 40

When would you deliberately avoid a DI framework like Koin in a small KMP project and just use manual constructor injection instead?

Accepted Answer

Koin (and DI frameworks generally) earn their keep once you have enough classes with overlapping, multi-level dependencies that wiring them by hand becomes repetitive and error-prone — a `UserViewModel` needing a `UserRepository` needing an `HttpClient` and a `Database`, multiplied across a dozen screens. For a small app or a library module with a handful of classes, that graph is trivial to wire by hand:
```kotlin
// no DI framework at all
fun createUserViewModel(): UserViewModel {
    val httpClient = createHttpClient()
    val database = DatabaseDriverFactory().createDriver()
    val repository = UserRepository(httpClient, database)
    return UserViewModel(repository)
}
```
The case for avoiding Koin specifically here: it adds a runtime dependency, a small startup cost for building its dependency graph, and a layer of indirection (`get()` calls resolved by string/type lookup rather than a direct constructor call) that makes "where does this dependency actually come from" one step harder to trace by just reading the code — for a handful of classes, that trade-off doesn't pay for itself. This is the same YAGNI judgment call as any other abstraction: reach for Koin once you have a genuinely deep or frequently-changing dependency graph (real multi-module apps almost always do), not as a default for every new KMP project regardless of size.

Question 41

What Gradle setup issues commonly show up the first time a module is made multiplatform (e.g. duplicate classes, missing native artifacts, wrong plugin order)?

Accepted Answer

A very common first mistake is applying `kotlin("multiplatform")` alongside a leftover `kotlin("android")` or `kotlin("jvm")` plugin in the same module — the multiplatform plugin already declares its own Android/JVM targets internally via the `kotlin { androidTarget() }`/`kotlin { jvm() }` DSL, so applying the single-platform plugin too causes duplicate-declaration or duplicate-class errors because the same source gets registered as belonging to two conflicting target configurations at once.

Another frequent one: forgetting to declare `sourceSets { androidMain.dependencies { ... } }` per-source-set and instead putting a dependency in the top-level `dependencies { }` block outside the `kotlin { }` DSL — this silently applies the dependency only to whatever the default/main configuration resolves to (often not what you expect for a multiplatform module), rather than to the specific source set that actually needs it, which shows up later as an "unresolved reference" only when compiling one particular target.

A third is running `./gradlew build` on a machine without Xcode/the right SDKs installed and being confused that iOS-target tasks fail or produce no artifact — Kotlin/Native's Apple targets (`iosArm64`, `iosSimulatorArm64`, `macosArm64`, etc.) can only actually compile on a macOS host with Xcode command-line tools installed; a Linux or Windows CI runner building the same project will simply skip or fail those specific target tasks, which is expected, not a config bug, and usually means CI needs a macOS runner stage specifically for the Apple-target build/test steps.

Question 42

How do generics and variance in Kotlin get represented when a shared class is exported to Objective-C/Swift, and what breaks?

Accepted Answer

Objective-C generics are much weaker than Kotlin's — Objective-C's "lightweight generics" are essentially just compile-time annotations for the Objective-C compiler with no real runtime enforcement, and they don't support variance (`in`/`out`) or bounded type parameters the way Kotlin does. When Kotlin/Native exports a generic class through the Objective-C bridging header, it typically has to erase or flatten the more expressive parts of Kotlin's generic system to fit what Objective-C can express. Concretely, a Kotlin `Result` or a `Repository` with a bounded type parameter loses its variance/bound information at the Objective-C boundary — Swift code consuming the generated API often sees the type parameter as unconstrained `Any`/`AnyObject`, forcing manual `as!`/`as?` casts on the Swift side that the Kotlin compiler would have caught for you if the same code stayed inside `commonMain`/Kotlin-to-Kotlin calls. This is one of the concrete motivations behind Direct Swift Export (kmp_native_03): compiling straight to Swift instead of going through Objective-C headers means Swift's own (much closer to Kotlin's) generics and variance model can be targeted directly, preserving more of the original type information instead of lossy-flattening through Objective-C's weaker generic system first. Until that's the default, a common practical workaround is to avoid exposing complex generic bounds/variance at the public API boundary that crosses to Swift specifically, keeping the richer generic types internal to `commonMain` and exporting simpler, concrete (non-generic) wrapper types instead.

Question 43

What is the actual difference between "shared code" and "shared UI" strategies in KMP (sharing only business logic vs. also sharing UI with Compose Multiplatform)?

Accepted Answer

"Shared code" (sometimes still called by the older KMM framing) means only the non-UI layer — networking, data models, database access, view-state/ViewModels — lives in `commonMain`, while each platform keeps its own fully native UI: Jetpack Compose (or the older View system) on Android, SwiftUI/UIKit on iOS. This is the lower-risk, more incremental adoption path — you can add KMP to an existing native app one shared module at a time without touching either app's UI layer at all.

"Shared UI" additionally puts the UI layer itself into `commonMain` using Compose Multiplatform, so the same composable functions render the actual screens on both platforms (via Skia on iOS, as described in kmp_native_02), not just the logic behind them. This maximizes code reuse and cross-platform consistency but accepts the trade-offs already covered in kmp_native_02 (text-input ergonomics, accessibility tree, native look-and-feel divergence from platform UI conventions).

Most teams starting out choose shared-code-only specifically because it's additive and low-risk against an existing native app, and only move to shared UI later (or for a greenfield project) once they've evaluated whether Compose Multiplatform's current maturity level meets their specific app's UI/UX bar — this project's own CLAUDE.md UI-quality rules, for instance, would be a factor in deciding whether the current state of Compose-for-iOS accessibility support is acceptable for a given feature.

Question 44

Can Kotlin Multiplatform target desktop and web, or is it mobile-only?

Accepted Answer

No, KMP is not mobile-only — "mobile" (Android + iOS) is just the most common and most heavily marketed use case, largely because that's the pairing with the biggest historical code-duplication pain (two completely separate native codebases, two languages). The underlying Kotlin Multiplatform mechanism supports any combination of the compiler's backends: `jvm()` covers desktop apps (e.g. via Compose Multiplatform for Desktop, producing a real Windows/macOS/Linux JVM app) and server backends equally well, `js()`/`wasmJs()` cover web browsers, and the various `ios*()`/`macos*()`/`watchos*()`/`tvos*()` Native targets cover the full Apple device family, not just iPhone.

A single `commonMain` module can, in principle, be consumed by an Android app, an iOS app, a desktop JVM app, and a web frontend all at once — the practical limiting factor is almost always library support (does everything you depend on — networking, DI, database, serialization — actually publish artifacts for every target you want) rather than any fundamental restriction in KMP itself.

Question 45

What is the role of a Gradle version catalog in a multiplatform project with many source sets and shared dependency versions?

Accepted Answer

A KMP project typically ends up with the same library referenced from several places — a networking library declared in `commonMain`, its OkHttp engine variant in `androidMain`, its Darwin engine variant in `iosMain`, plus the same Kotlin/coroutines/serialization version needing to line up consistently across a dozen modules in a multi-module setup. Hardcoding version strings (`"io.ktor:ktor-client-core:2.3.7"`) directly in each module's `build.gradle.kts` means bumping a version requires a find-and-replace across every file that mentions it, and it's easy to miss one and end up with mismatched versions silently causing resolution conflicts.

A Gradle version catalog (`gradle/libs.versions.toml`) centralizes every version and dependency coordinate in one TOML file:
```toml
[versions]
ktor = "2.3.7"

[libraries]
ktor-client-core = { module = "io.ktor:ktor-client-core", version.ref = "ktor" }
ktor-client-okhttp = { module = "io.ktor:ktor-client-okhttp", version.ref = "ktor" }
```
Every module's `build.gradle.kts` then references `libs.ktor.client.core` via Gradle's generated type-safe accessors instead of a raw string, so bumping `ktor = "2.3.7"` to a new version in one place updates every module and every source set (`commonMain`, `androidMain`, `iosMain`) that depends on it consistently — directly addressing the "single source of truth, one config change reflects everywhere" principle this codebase already applies to things like `planEntitlements.json`.

Question 46

How do enum classes behave when exported from Kotlin to Swift, and what limitation historically existed with exhaustive when/switch matching across the boundary?

Accepted Answer

A plain Kotlin `enum class` (with no properties beyond ordinal/name) exports to Objective-C/Swift relatively cleanly as a genuine Swift `enum`, because Objective-C has NS_ENUM support that maps closely enough to Kotlin's simple enum case. Swift code can `switch` over it exhaustively and the compiler will complain if a new case isn't handled, same as native Swift enums — this simple case has generally worked well for a long time.

The historical pain was with Kotlin `sealed class`/`sealed interface` hierarchies used as a richer "enum with data" pattern (each subtype carrying different associated data) — that's a much closer semantic match to a Swift enum with associated values, but the Objective-C bridging layer has no native representation for "associated values," so it exported sealed hierarchies as a flat class hierarchy instead (a base class with several unrelated-looking subclasses), losing Swift's ability to `switch` over it exhaustively with compiler-enforced case coverage — you'd fall back to a chain of `if let x = state as? StateA` checks instead, with no compiler warning if you forgot to handle a new subtype added later.

This is exactly the gap that both SKIE (kmp_gen_022) and Direct Swift Export (kmp_native_03) specifically target — converting sealed hierarchies into genuine Swift enums-with-associated-values so exhaustive `switch` matching (and the compile-time safety net that comes with it) works the same way it would for a hierarchy defined natively in Swift.

Question 47

How would you decide whether a new feature's business logic belongs in commonMain versus staying platform-specific?

Accepted Answer

The practical test is: does this logic depend on any platform API, and would getting it wrong differ in outcome between platforms? Pure computation and decision-making — validating a form, computing a price with a discount, deciding which screen to navigate to next based on server state, parsing and transforming an API response — has no platform dependency at all and belongs in `commonMain` by default, since duplicating it per platform is exactly the maintenance/drift risk KMP exists to eliminate.

Logic that genuinely needs a platform API — reading a file from platform-specific storage, showing a native permission dialog, integrating a platform-specific push-notification SDK, anything touching `UIKit`/`Foundation` or `android.*` packages directly — has to live in `androidMain`/`iosMain` (behind an `expect`/`actual` boundary if the shared layer needs to call it, per the pattern in kmp_exp_01).

The one nuance worth being deliberate about: something being *technically* shareable doesn't automatically mean it *should* be shared today — per this project's own YAGNI principle, if only one platform currently needs a given piece of logic and there's no second concrete use case yet, it's fine to write it directly in that platform's source set and only extract it into `commonMain` once a second real caller on the other platform actually shows up, rather than speculatively sharing everything up front.

Question 48

Two engineers both call a shared Kotlin/Native singleton object that mutates a plain var from a background coroutine on Android and from a Swift Task on iOS at the same time — what actually happens under the new memory model, and how do you make that state thread-safe in commonMain?

Accepted Answer

Under the new Kotlin/Native memory model (post-1.7.20, default since 1.9.20), a plain `var` on a Kotlin `object` singleton is a normal mutable field with no automatic cross-thread protection — unlike the old frozen/unfrozen model, nothing throws an exception here, which is actually the more dangerous outcome. Two threads (the Android background coroutine and the iOS-side call, both ultimately executing Kotlin code through Kotlin/Native's own thread-safe-by-default GC) can race on reading and writing that field concurrently, producing a classic data race: lost updates, torn reads on multi-word state, or a value that's neither the old nor the new write cleanly. The new memory model makes concurrent access *possible without crashing*, but it does not make plain mutable state *correct* under concurrent access — that responsibility is still entirely on you, exactly like writing multi-threaded code on the JVM.

The fix is the same as it would be for any shared mutable state on the JVM: don't rely on a bare `var`. Use `kotlinx.atomicfu`'s `AtomicRef`/`AtomicInt` for simple scalar state, since it compiles down to real atomic hardware instructions on every Kotlin/Native target (and to `java.util.concurrent.atomic` on JVM) with a single common API:
```kotlin
object SessionState {
    private val _token = atomic<String?>(null)
    var token: String?
        get() = _token.value
        set(value) { _token.value = value }
}
```
For anything more than a single field — a multi-field state update that needs to happen as one unit — wrap the mutation in a `kotlinx.coroutines.sync.Mutex` (`mutex.withLock { ... }`) instead, since atomics only guarantee atomicity per individual field, not across a group of related fields being updated together. Either way, the shared `commonMain` code needs to make this explicit itself — it can't rely on "iOS only has one thread anyway" or any other platform assumption, since the whole point of the shared singleton is that both an Android coroutine and an iOS-originated call can genuinely execute it concurrently.

Question 49

What does expect/actual cost you in terms of testing — specifically, how do you cover platform-specific actual implementations that live outside commonMain's test target?

Accepted Answer

A test written in `commonTest` only ever exercises whatever `actual` implementation gets resolved for the specific target that test run is compiling against — running `./gradlew jvmTest` verifies the `androidMain`/`jvmMain` `actual`, and running `iosSimulatorArm64Test` verifies the `iosMain` `actual`, but neither run alone proves *both* implementations are correct. If you only ever run tests on your CI's default target (commonly just the JVM one, since it's fastest and needs no macOS runner), a bug specific to the iOS `actual` implementation — say, an off-by-one in the native dispatcher setup from kmp_exp_03 — can silently ship without any test ever having executed that code path at all.

The fix is making sure CI actually runs `allTests` (or explicitly both `jvmTest`/`androidUnitTest` and an iOS simulator test task) rather than just whichever target happens to be fastest or most convenient to run — this generally means the CI pipeline needs a macOS runner stage specifically to execute the native test binaries, similar to the build-time requirement noted in kmp_gen_024.

For `actual` implementations that wrap something inherently hard to unit test in CI (an actual push-notification SDK call, actual biometric-auth prompt), the practical answer is usually to keep the `actual` implementation itself as thin as possible — just enough to satisfy the platform API's shape — and push any testable branching/logic back up into `commonMain` behind the interface, so the bulk of the logic is covered by ordinary `commonTest` tests and only a thin, hard-to-break platform shim is left genuinely untested by automation.

Question 50

Why does adding a single Kotlin/Native target to a KMP module sometimes multiply CI build minutes far more than adding an equivalent Android build variant would, and what's the underlying compilation-model reason?

Accepted Answer

Adding an Android product flavor or build variant is comparatively cheap because the JVM/Android Gradle plugin's incremental compilation is mature, and — crucially — Android/JVM compilation shares a single, well-cached toolchain (`javac`/`kotlinc-jvm`) whose intermediate artifacts (compiled classes, the Kotlin compiler's own incremental compilation cache) are highly reusable between variants that mostly overlap in source.

A Kotlin/Native target is a fundamentally heavier compilation unit: each native target (`iosArm64`, `iosSimulatorArm64`, `iosX64`, etc.) is compiled through LLVM down to real machine code for that specific architecture/environment combination — there is no shared bytecode-then-JIT step the way JVM targets get; each target essentially re-runs a full native compile-and-link pipeline. Kotlin/Native also links against its own klib-based standard library and any cinterop-generated bindings *per target*, so a project with three iOS targets is, from the compiler's perspective, closer to three mostly-independent native builds than three lightweight variants of one build — and cinterop specifically (kmp_native_01) adds its own binding-generation step per target on top of that.

This is exactly why the caching/target-filtering advice in kmp_build_03 matters so much more for Kotlin/Native than the equivalent Android build-variant tuning would: `kotlin.native.cacheKind=static` and limiting the locally-built target list aren't just nice-to-haves, they're addressing a genuinely more expensive compilation model, not just poor Gradle configuration — the LLVM-backed, per-target, no-shared-bytecode nature of Kotlin/Native compilation is the root mechanism, not something you can tune away entirely, only mitigate.

Question 51

What does a typical Kotlin Multiplatform Mobile project's folder structure look like (androidApp, iosApp, shared), and what goes in each part?

Accepted Answer

A standard KMP mobile project is usually split into three top-level modules: `shared`, `androidApp`, and `iosApp`. The `shared` module is the Kotlin Multiplatform Gradle module — it contains the source sets you actually write shared logic in (`commonMain` for code used by every platform, plus `androidMain`/`iosMain` for platform-specific bits), and it compiles to two different outputs depending on who's consuming it: a normal Kotlin/JVM artifact for Android, and a native `.framework` for iOS.

`androidApp` is a completely ordinary Android Studio module — an Android `Application`, Activities/Fragments or Jetpack Compose screens, an `AndroidManifest.xml` — that adds `shared` as a regular Gradle module dependency (`implementation(project(":shared"))`) and calls into it just like any other Kotlin library. `iosApp` is a normal Xcode project with Swift/SwiftUI code, which imports the compiled `shared.framework` and calls its exported classes and functions from Swift.

So a simplified layout looks like:
```
MyKmpProject/
├── shared/
│   ├── src/commonMain/kotlin/   # UserRepository, models, validation — used everywhere
│   ├── src/androidMain/kotlin/  # actual implementations needing Android APIs
│   └── src/iosMain/kotlin/      # actual implementations needing iOS APIs
├── androidApp/                  # native Android UI, depends on shared
└── iosApp/                      # native Xcode/Swift UI, depends on shared.framework
```
The key mental model for a beginner: only `shared/` is where Kotlin Multiplatform's `expect`/`actual` and multi-target compilation apply. `androidApp` and `iosApp` are each 100% normal, single-platform apps that simply happen to both depend on the same compiled shared code, which is exactly what lets each platform's UI stay fully native while business logic (networking, data models, validation) is written and maintained only once.

Kotlin Multiplatform Interview Questions & Answers

Ready to practice these live?