Kotlin Multiplatform (KMP) Interview Questions
ADVANCED › Emerging
Walk me through how you'd introduce KMP into an app that currently has two fully separate Android and iOS codebases, without freezing feature work on either platform.
What a strong answer covers: A strong answer starts small: pick a stateless, low-risk slice like validation logic or a networking client to prove out the shared module, CI, and publishing pipeline before touching business-critical code, and keeps both native implementations running in parallel until the shared version is trusted. It also names that the real friction is organizational as much as technical, getting iOS engineers comfortable with Kotlin tooling and Xcode integration, and flags that trying to convert everything at once is the classic way these migrations stall.
When would you choose not to share the ViewModel or presentation layer in commonMain, even though KMP supports it, and keep it native on each platform instead?
What a strong answer covers: Sharing ViewModels works cleanly when both platforms want the same screen flow and state shape; if iOS and Android diverge in navigation pattern or interaction model, forcing a shared ViewModel creates a lowest-common-denominator abstraction that leaks through the UI. It should also note that SwiftUI's state and lifecycle model doesn't map 1:1 onto Android's ViewModel, so a shared ViewModel typically needs a thin native wrapper on iOS (an ObservableObject bridging a StateFlow), and many teams deliberately stop at sharing logic below the ViewModel to avoid that plumbing.
You've shipped a KMP module that's core to both apps, and a critical bug shows up only on iOS in the shared Kotlin/Native code. Walk me through how you'd debug it.
What a strong answer covers: A strong answer reproduces the failure with a fast unit test in commonTest or iosTest before touching the full app, then checks whether it's an interop issue such as threading or Kotlin GC interaction with Objective-C ARC, or an expect/actual mismatch that only fires on the iOS actual. It should also flag that iOS crash reports won't have readable Kotlin stack traces unless the KMP framework's debug symbols are set up for symbolication, and that debugging via LLDB in Xcode against the compiled framework is a heavier workflow than Android Studio's, which is a trap engineers new to KMP often underestimate.