Kotlin Multiplatform promised shared business logic with native UI performance. Our adventure game seemed perfect for this approach: complex inventory systems, quest logic, and character progression could live in shared code.
Library Ecosystem Gaps
Essential game libraries had no Kotlin Multiplatform support. Physics engines, advanced rendering, and networking libraries required platform-specific implementations anyway. We ended up writing more platform-specific code than teams using separate native codebases, because we constantly bridged between shared Kotlin and native APIs.
Debugging Across Platforms
Bugs in shared code manifested differently on iOS and Android. Stack traces pointed to generated code, not our source. Developers spent days isolating whether issues originated in shared logic, platform bridges, or native implementations. Traditional native development provides clear separation and established debugging workflows.
The Maturity Problem
Documentation was sparse. Community support was limited. Each Kotlin update broke our build configuration. Teams using established frameworks like Unity or Godot had mature ecosystems, extensive tutorials, and predictable upgrade paths. We chose bleeding-edge technology for a production game and absorbed the instability costs ourselves.