On this page · 11 sections
Summary. From 31 August 2026, new apps and app updates on Google Play must target Android 16 (API level 36) or higher, with Wear OS and Android Automotive at API 35 and Android TV and Android XR at API 34. Existing apps must target API 35 or higher just to stay available to new users on newer devices. Extensions run to 1 November 2026. Meanwhile Kotlin 2.4.0 landed on 3 June 2026 with stable context parameters, Compose BOM 2026.08.00 shipped on 12 August 2026 and requires Android Gradle Plugin 9.1.1, and JetBrains reports that 92% of professional Android developers now use Kotlin. Kotlin Multiplatform has been stable since Kotlin 1.9.20 in November 2023, and Compose Multiplatform for iOS since version 1.8.0 on 8 May 2025. Both decisions land in the same sprint, and taking them separately is how teams end up doing the work twice.
The deadline first, because it is 13 days away
Google's target API level requirements page, last updated 14 August 2026, is unambiguous. Starting 31 August 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play, except Wear OS and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher.
There is a second, lower floor on the same date that catches people out. Existing apps must target API 35 or higher to remain available to new users on devices running an Android OS higher than the app's target level. Apps targeting API 34 or lower will only be available on devices running an Android OS the same as or lower than the app's target. In other words, an app that does not ship an update simply becomes invisible to most new phones.
If the work will not land in time, Google says an extension can be requested to 1 November 2026, with the extension forms appearing in Play Console later this year. The only listed exception is permanently private apps restricted to a specific organisation for internal distribution. If you are still on API 34 today, treat that extension as the plan and the deadline as the target, and read our Android target API 36 migration guide alongside this page.
| Requirement from 31 August 2026 | Target API level | Applies to |
|---|---|---|
| New apps and updates, phones and tablets | 36 (Android 16) | Submission to Google Play |
| New apps and updates, Wear OS and Automotive | 35 (Android 15) | Submission to Google Play |
| New apps and updates, Android TV and XR | 34 (Android 14) | Submission to Google Play |
| Existing apps, to stay visible to new users | 35 (Android 15) | Distribution on newer devices |
| Extension deadline | n/a | Requested through Play Console, to 1 November 2026 |
Two more dated constraints behind it
The target level is not the only thing moving. Google's page-size guidance, updated 5 August 2026, requires all apps targeting API 35 and higher to support 16 KB memory page sizes on 64-bit devices, and states that from 1 February 2027, updates that do not support 16 KB page sizes cannot be released. That one bites native libraries and third-party SDKs rather than Kotlin code, which is precisely why it gets missed until a release is blocked.
And the toolchain floor moved this month. Compose BOM 2026.08.00, released 12 August 2026, brings Compose 1.12 across core modules; Compose 1.12 raises compileSdk to API 37 and requires Android Gradle Plugin 9.1.1 as a minimum. A build that is behind on AGP therefore has to move before it can adopt the current Compose line, which is the same class of upgrade sequencing we cover in the AGP 9 and Kotlin Gradle Plugin migration decision.
Kotlin itself, as of August 2026
The current stable Kotlin is 2.4.10, released 14 July 2026, and it is a bug-fix release. The features arrived in Kotlin 2.4.0 on 3 June 2026: stable context parameters, explicit backing fields, and several changes to annotation use-site targets on the language side; Swift packages as dependencies, updates to Swift export, and the concurrent mark-and-sweep garbage collector enabled by default in Kotlin/Native; and Java 26 support with annotations in metadata enabled by default on Kotlin/JVM.
Swift packages as dependencies is the line that matters for the multiplatform decision. It is the difference between a shared Kotlin module that can consume the iOS ecosystem and one that needs a bridge written by hand.
On adoption, JetBrains reported at KotlinConf'26 that Google has been using Kotlin in production for over a decade and that 92% of professional Android developers now use Kotlin for Android applications. The same post says the number of top apps using Kotlin Multiplatform more than doubled over the past year, without giving an absolute figure. The klibs.io directory listed more than 3,500 community libraries at that point and more than 4,100 by August 2026.
Multiplatform or Android-only: the actual tradeoff
Kotlin Multiplatform has been stable since Kotlin 1.9.20 in November 2023. Compose Multiplatform for iOS reached stable with version 1.8.0 on 8 May 2025, where JetBrains stated that all major APIs are officially stable with strong compatibility guarantees. The same announcement gives two numbers worth quoting to a stakeholder: Compose Multiplatform adds roughly 9 MB to an iOS app compared with a fully native SwiftUI app with the same UI logic and assets, and over 96% of teams using Compose Multiplatform on iOS reported no major performance concerns.
Nine megabytes is a real cost and a small one. The larger cost is elsewhere.
| Factor | Android-only Kotlin | KMP with shared logic, native UI | KMP with Compose Multiplatform UI |
|---|---|---|---|
| Shared code | None | Business logic, networking, storage | Logic plus most of the UI |
| iOS UI work | Separate team or later | SwiftUI, written once by iOS engineers | Largely shared |
| iOS app size impact | n/a | Small | About 9 MB over native SwiftUI |
| Team shape | Android engineers | Android and iOS engineers who agree a contract | Kotlin engineers, one iOS specialist |
| Biggest risk | Building the same app twice later | Interface between shared and native drifts | UI conventions that feel non-native |
| Best fit | Android-first market, one platform funded | Two platforms, distinct native feel required | Two platforms, speed over platform idiom |
Our working rule after several of these: share the logic before you share the UI. The layer that pays back fastest is networking, models, validation and offline data synchronization, because that is where the same bug otherwise gets fixed twice with two different fixes. Sharing the UI pays back when the design system is already unified and the app is not competing on platform-native feel. If you want the same comparison run against native iOS rather than against Android, our SwiftUI versus KMP analysis takes that side.
The honest counter-case: if only Android is funded this year and the iOS decision is genuinely undecided, Android-only Kotlin with a clean module boundary costs less now and does not close the door. Kotlin Multiplatform can be introduced into an existing Android codebase module by module. It is not a rewrite gate.
What we build
New Android apps in Kotlin with Jetpack Compose, targeting the current API level and built against a pinned Compose BOM rather than floating versions. Kotlin Multiplatform products, where a shared module carries the domain, and the UI is either native per platform or Compose Multiplatform depending on the decision above. Compliance and migration work: raising an app to API 36, resolving 16 KB page-size issues in native dependencies, and moving builds onto the AGP version the current Compose line requires. And retained engineering for a live app, where the work is a rolling mix of features and the platform deadlines Google sets each year.
Our delivery process
- Discovery, 1 week. Current
targetSdkandcompileSdk, AGP and Kotlin versions, the third-party SDK inventory with 16 KB page-size status against each native library, and the Play Console policy position. This produces the deadline risk list first, because that is the thing with a date on it.
- Architecture, 1 week. The multiplatform decision, made explicitly and written down: what is shared, what is native, and where the boundary sits. Getting that boundary wrong is the expensive mistake, not choosing the wrong framework.
- Build, 6-14 weeks. Feature work with instrumented and unit tests from the first sprint, a pinned toolchain in version catalogs, and an internal track release from week two so distribution problems surface early rather than at launch.
- Release and compliance, 1-2 weeks. Play Console data safety and policy declarations, staged rollout, and Android vitals watched against crash and ANR thresholds after release rather than a month later.
- Run. Annual target API level work planned before Google announces it, because the pattern is now predictable, plus SDK and dependency upgrades on a fixed cadence. Our software testing team owns the regression pass for each platform bump.
Why eCorpIT
eCorp Information Technologies Private Limited was founded in 2021 and works from Gurugram, Haryana. We are CMMI Level 5 appraised, MSME certified, and ISO 27001:2022 certified, and we are a Google partner alongside AWS and Microsoft. Teams are senior-led and multi-disciplinary, so a Kotlin engagement has an engineer who has shipped through a Play policy deadline rather than one reading about it for the first time.
We work to an engagement model rather than a rate card. Discovery is a fixed-price package that produces the compliance risk list and the multiplatform recommendation. A new app build is fixed-scope once the architecture decision is signed. A live product is a monthly dedicated squad sized to the release cadence, and if you would rather hold the roadmap yourself and add Kotlin engineers to your team, our staff augmentation services page sets out that route. Compliance-only work, such as an API 36 migration, is scoped and priced on its own; see our Android target API 36 migration service.
India-specific considerations
Three things change the build for an India-first app. Device mix: budget 64-bit devices make the 16 KB page-size requirement a real compatibility question rather than a theoretical one, so native dependencies need auditing rather than assuming the SDK vendor has done it. Distribution: an app that slips past 31 August 2026 without an extension stops reaching new users on newer devices, and in a market where handset replacement is fast, that is a growth stop rather than a slow leak. Privacy: an app collecting names, phone numbers, location or payment identifiers is processing personal data under the Digital Personal Data Protection Act 2023, so the Play Console data safety declaration and the app's actual retention behaviour have to agree. We design Android and Kotlin Multiplatform apps aligned with DPDP requirements, with retention and deletion implemented in the shared data layer so both platforms behave identically.
FAQ
How eCorpIT can help
We start with the deadline, because it has a date and the architecture question does not. That means an inventory of your current target and compile SDK levels, your AGP and Kotlin versions, and every native dependency checked against the 16 KB page-size requirement, producing a risk list you can act on before 31 August 2026 or file an extension against. Once that is stable, we make the multiplatform call properly: what to share, what to keep native, and where the boundary sits. If you are choosing between Android-only Kotlin and Kotlin Multiplatform, or you need an app moved to API 36 quickly, send us the current build configuration and we will come back with a scoped plan and an engagement model. Start at /contact-us/.
References
Last updated: 18 August 2026.
