Your org wants to share code between an Android and an iOS app with Kotlin Multiplatform. How do you decide what belongs in the shared module versus staying native, and how do you handle platform-specific APIs?
technical-conceptual · Senior level · software-engineering
What the interviewer is really asking
Assesses whether the candidate understands KMP's shared-logic-not-shared-UI philosophy and the expect/actual mechanism for bridging platform APIs.
What to say
- Frame the boundary: share business logic, networking, data models, validation, and caching in commonMain, while keeping UI native (SwiftUI / Compose) unless you have a deliberate reason to adopt Compose Multiplatform.
- Explain expect/actual: declare the API in common code with expect, provide the platform implementation with actual in each source set, so common code stays portable while touching platform-specific capabilities.
- Discuss the trade-offs honestly: shared logic cuts duplicated bugs and effort, but you add a build-and-tooling tax and need each platform team comfortable consuming the shared module.
What to avoid
- Treating KMP as share-everything-including-UI by default and ignoring that native UI is the common production choice.
- Not knowing how to call a platform-specific API from common code (the expect/actual mechanism).
- Pitching it purely on cost savings while ignoring the integration and tooling burden on both teams.
Example answers
Strong: I put business logic, the API client, models, validation, and caching in commonMain because that's where duplicated bugs across two codebases hurt most, and I keep the UI native in SwiftUI and Compose. When the shared code needs something platform-specific, like secure storage, I declare an expect function in common and provide the actual implementation per platform. I'm upfront that we're trading some build and tooling overhead for one tested copy of the rules, so both teams need to be on board with consuming the module.
Weak: KMP lets you share everything, so I'd move as much as possible into the shared module, including the UI with Compose Multiplatform, to maximize reuse. That way both platforms run the same code and we cut the team size roughly in half.