Kotlin
Google Play closed testing for Kotlin and KMM apps
Whether your Android app is plain Kotlin or the Android target of a Kotlin Multiplatform project, Play sees one thing: an Android App Bundle that needs 12 real testers for 14 consecutive days. Here is the path, plus what KMM projects specifically should use the window for.
Getting your build onto Play
- 1
Build a signed release bundle
Play Console expects an Android App Bundle. Configure your release signing in the Android module, then assemble it from your project root.
./gradlew bundleRelease - 2
Confirm the Android target's manifest and SDK levels
For a KMM project the shared module carries no manifest - permissions, minSdk and target SDK all come from the Android application module. Check them there.
- 3
Upload to a closed testing track
Create the closed test in Play Console, upload the bundle, and add TestSlot's single tester group email to the tester list. One entry covers every TestSlot tester.
- 4
Share the opt-in URL
The track's opt-in link is what testers use to join and install. TestSlot testers are taken straight to it from the listing.
What breaks a Kotlin closed test
- Assuming shared logic means shared behaviour
KMM's business logic runs identically across targets, but your Android UI is platform-specific. Most KMM bugs found in closed testing live at that seam - state management, navigation, and platform-specific API calls.
- Wasting the window instead of using it
The 14 days are mandatory either way. Use them to verify the Android UI integrates correctly with the shared module, and document the places Android behaviour diverges from your iOS implementation.
- Thin release notes
Specific, technically substantive notes about what you fixed make far stronger production access questionnaire answers than generic ones. KMM platform-divergence fixes are exactly that kind of material.
The part most Kotlin developers get stuck on
Shipping the build is the easy half. Google still requires 12 real testers who keep your app installed for 14 consecutive days before it will grant production access.
- TestSlot supplies real people on real Android devices, not emulators or scripts.
- Testers use your app as an ordinary Android app - that it is built on KMM is transparent to them.
- Streaks are counted server-side, so a changed device clock does nothing to the count.
- If a tester drops out, replacement coverage keeps you at the required headcount.
Questions
- Does Kotlin Multiplatform change the closed testing requirement?
- No. Google evaluates the Android App Bundle you ship and the tester activity behind it. A KMM app faces the same 12-tester, 14-consecutive-day requirement as any other Android app.
- Do I need a separate closed test for the iOS side?
- No - this requirement is Google Play's. Your iOS target goes through Apple's own review process, which is unrelated.
- What should KMM developers actually test during the 14 days?
- The integration between your shared module and the Android-specific UI: state management, navigation, and any platform-specific API calls. That is where behaviour diverges, and it is genuine testing value rather than waiting out a clock.
- Will testers notice it is a multiplatform app?
- No. They install it from the Play opt-in link and use it like anything else on their phone.