Kotlin Multiplatform (KMP) Quiz

ADVANCED › Emerging

In a 'share logic, native UI' KMP app, which layer is usually NOT placed in commonMain?

• The networking/API client used to fetch and send data
• Data models and DTOs shared between platforms
• The platform-specific screen UI, like SwiftUI views
• Business and domain logic used by both platforms

Answer: The platform-specific screen UI, like SwiftUI views

Networking, models, and logic are the prime sharing candidates; with native UI the actual SwiftUI/Compose screens stay in each platform's code, not commonMain.

What is the purpose of expect/actual in KMP?

• Declare an API in commonMain, with a platform implementation per source set
• Mark code that should be excluded entirely from the iOS target build
• Generate type-safe database query APIs from your .sq SQL schema files at build time
• Convert suspend functions into Swift completion-handler callbacks

Answer: Declare an API in commonMain, with a platform implementation per source set

expect/actual lets common code reference an API while each target provides its own implementation; it is the core mechanism for platform-specific behavior behind a shared declaration.

How does shared Kotlin code actually run on iOS in a KMP project?

• It runs on a lightweight JVM bundled inside the iOS app package
• It is transpiled directly to Swift source code at build time
• It runs inside a JavaScript engine through the Kotlin/JS backend at runtime
• Kotlin/Native compiles it to a native Objective-C framework binary

Answer: Kotlin/Native compiles it to a native Objective-C framework binary

iOS uses the Kotlin/Native backend, which compiles to a native binary exposed to Swift as an Objective-C framework; there is no JVM or Swift transpilation involved.

Which statement about Ktor Client in KMP is correct?

• It works only on Android and needs a completely separate iOS HTTP library of its own
• A multiplatform HTTP client using a pluggable engine like OkHttp or Darwin
• It generates shared cross-platform UI components for all app targets
• It fully replaces kotlinx.serialization for every JSON parsing task

Answer: A multiplatform HTTP client using a pluggable engine like OkHttp or Darwin

Ktor is multiplatform and abstracts the HTTP engine, letting each target plug in its own (OkHttp, Darwin, CIO); it works with kotlinx.serialization rather than replacing it.

What does SQLDelight do in a KMP project?

• Provides a cloud-synced NoSQL document database service for KMP apps
• Wraps Room so existing Android database code runs unchanged on iOS
• Generates type-safe Kotlin from your SQL at compile time, driver per platform
• Is a compact binary serialization format competing with Protocol Buffers

Answer: Generates type-safe Kotlin from your SQL at compile time, driver per platform

SQLDelight reads .sq SQL files and generates type-safe Kotlin at compile time, backed by a platform-specific SqlDriver (AndroidSqliteDriver, NativeSqliteDriver). It is not a wrapper around Room.

A common friction point when exposing shared Kotlin to Swift is that:

• suspend functions become completion handlers and generics map poorly to Swift
• Swift is completely unable to call into any of the shared Kotlin code
• Kotlin classes must be manually hand-rewritten in Objective-C first
• Coroutines are entirely unavailable on the Kotlin/Native backend

Answer: suspend functions become completion handlers and generics map poorly to Swift

Interop goes through an Objective-C framework, so Kotlin suspend functions become completion handlers and generics/sealed types map awkwardly; tools like SKIE smooth this over.

Which scenario most clearly justifies adopting KMP despite its build and tooling overhead?

• A single-platform Android app with no iOS target or shared code needs
• A tiny app whose code is mostly platform-specific UI with trivial logic
• A team that wants KMP but never wants to install Xcode or use a Mac
• Android and iOS apps sharing core business, networking, and data logic

Answer: Android and iOS apps sharing core business, networking, and data logic

KMP's reuse benefits outweigh its costs when there is meaningful shared logic across two platforms; single-platform or near-pure-UI apps gain little, and iOS work still requires a Mac with Xcode.

What does the default hierarchy template provide in a modern KMP project?

• Auto-created intermediate source sets like iosMain for a target family
• A prebuilt SwiftUI design system shared across every platform in the app
• Automatic conversion of Gradle build files into Xcode project settings
• A default bundle of Ktor and SQLDelight dependencies added to each module

Answer: Auto-created intermediate source sets like iosMain for a target family

The default hierarchy template auto-creates intermediate source sets for target families, so code common to all iOS targets lives in iosMain without manually wiring source-set dependencies.

Besides expect/actual, what is a commonly recommended way to supply platform-specific behavior in KMP?

• Use reflection in common code to load the right platform class at runtime
• Copy the same implementation into each source set and keep them in sync
• Define a common interface, then inject a platform implementation via DI
• Put one androidMain implementation in place and reuse it for every target

Answer: Define a common interface, then inject a platform implementation via DI

A plain interface in common code with platform implementations provided through DI (e.g. Koin) is often preferred over expect/actual because it is more flexible, testable, and avoids tight compiler coupling.

Which statement reflects the modern Kotlin/Native memory manager used by current KMP versions?

• Objects must be frozen with freeze() before sharing them across threads
• Coroutines cannot run on background threads in iOS apps
• Mutable state can be shared across threads without old freezing rules
• Garbage collection is disabled, so you must free memory manually

Answer: Mutable state can be shared across threads without old freezing rules

The newer Kotlin/Native memory manager removed the old strict object-freezing model, so concurrent code and coroutines behave much like on the JVM and no longer require freeze().

When a KMP project targets the browser/web, which Kotlin backend(s) compile the shared code?

• Kotlin/JVM running inside a server-side sandbox
• Kotlin/Native compiled only to WebAssembly
• Swift transpilation through a web compatibility shim
• Kotlin/Wasm or Kotlin/JS

Answer: Kotlin/Wasm or Kotlin/JS

Web targets use Kotlin/JS, which emits JavaScript, or Kotlin/Wasm, which emits WebAssembly; the JVM and Kotlin/Native backends are not used for the browser.

How can shared Kotlin/Native code call into an existing platform C or Objective-C library?

• Through cinterop, which generates Kotlin bindings from C headers
• It cannot; Kotlin/Native supports only pure Kotlin source code
• By bundling a JVM and calling the library through JNI at runtime
• By first rewriting the native library in pure Kotlin before sharing

Answer: Through cinterop, which generates Kotlin bindings from C headers

Kotlin/Native ships a cinterop tool that generates Kotlin bindings from C/Objective-C headers, letting shared code call native platform APIs directly without a JVM or JNI.

What is the standard way to deliver the compiled shared KMP module to an Xcode/iOS project?

• By copying the raw Kotlin source files directly into the Xcode project
• As an Objective-C framework or XCFramework, via embedding, CocoaPods, or SPM
• As a compiled JAR file added directly to the iOS app's build phases
• As a prebuilt JavaScript bundle that Swift imports and runs at runtime

Answer: As an Objective-C framework or XCFramework, via embedding, CocoaPods, or SPM

Kotlin/Native produces an (XC)Framework that iOS consumes through direct framework embedding, CocoaPods, or Swift Package Manager; JARs and JS bundles are not usable on iOS.

Why is kotlinx.serialization the typical JSON choice in KMP rather than Gson or Moshi?

• It is guaranteed to be faster than every native JSON parser on iOS
• Compiler-plugin based, it avoids JVM reflection and runs on Kotlin/Native too
• It is the only JSON library that can parse arbitrary data without any schema
• It comes with the Ktor HTTP client engine bundled directly inside it

Answer: Compiler-plugin based, it avoids JVM reflection and runs on Kotlin/Native too

kotlinx.serialization uses a compiler plugin to generate serializers at compile time with no runtime reflection, which is why it works across all KMP targets including Kotlin/Native, unlike the reflection-based Gson and Moshi.

Back to Kotlin Multiplatform (KMP)