On this page · 11 sections
- The two floors that actually gate a release
- The 16 KB question that separates Kotlin teams from NDK teams
- What Kotlin proficiency is worth, using only figures Google publishes
- Language versions: what "current Kotlin" means this month
- A technical screen that predicts delivery
- India-specific considerations
- Contract, retainer or embedded: choosing the engagement shape
- Where Kotlin hiring sits against the rest of your stack
- FAQ
- How eCorpIT can help
- References
Summary. Two dated constraints now decide whether an Android team can ship at all. From 31 August 2026, Google Play requires new apps and app updates to target Android 16 (API level 36) or higher, with an extension available to 1 November 2026. And the Jetpack Compose August 2026 release, BOM version 2026.08.00, moves compileSdk to API 37 and needs a minimum Android Gradle plugin of 9.1.1. Kotlin 2.4.0 shipped on 3 June 2026 with support running to 3 December 2027, and its current patch is 2.4.10 from 14 July 2026. A Kotlin developer who has not moved a real build across those four version boundaries is not a 2026 hire. PayScale put the average Android developer salary with Kotlin skills in India at ₹728,256 in 2026, from 145 salary profiles last updated on 24 June 2026 — but the salary band is the easy part of this decision.
Most Android hiring briefs still read like 2021: "3+ years Kotlin, MVVM, Retrofit, unit tests." That brief will get you someone who can write Kotlin and cannot get your app into the store. The binding constraints in 2026 are toolchain floors and Play policy dates, and they arrive on a calendar you do not control.
The two floors that actually gate a release
The first floor is Google Play policy. The Play Console Help page on target API level requirements states it plainly: "Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for 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, quieter floor in the same document, and teams miss it constantly. Existing apps that stop shipping updates do not get removed — they get hidden: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level." An app frozen at API 34 stays installed for people who already have it and stops appearing for anyone on a newer phone. That is an invisible revenue leak, not an outage, which is why it survives so long inside an organisation.
Google does offer relief on the submission floor: "You will be able to request an extension to November 1, 2026 if you need more time to update your app." Nine extra weeks. Not a strategy.
The second floor is the toolchain. In the Jetpack Compose August 2026 release post, published 12 August 2026, Nick Butcher, Product Manager for Jetpack Compose at Google, writes: "Compose 1.12 updates compileSdk to API 37, requiring a minimum AGP 9.1.1. As a reminder, Compose will always target the latest compileSdk." Taking the current Compose BOM means taking the current compile SDK. There is no supported way to sit on the new Compose and an old Gradle plugin.
Read that second sentence again, because it is the part that governs planning. Compose does not let you pin the UI toolkit and defer the platform. Every BOM bump is also a compile SDK bump and, periodically, a Gradle plugin bump, so "we'll upgrade Compose later" is a decision to fall behind on three axes at once. The Compose BOM documentation maps each BOM version to the library versions it pins, and it is the only mapping worth trusting when a candidate quotes a Compose version from memory.
| Constraint | The number | Date it binds | What happens if you miss it |
|---|---|---|---|
| Play submission floor | API level 36 | 31 August 2026 | New apps and updates rejected at submission |
| Play visibility floor | API level 35 | Ongoing | App hidden from new users on newer Android versions |
| Play extension window | API level 36 | 1 November 2026 | Extension request expires; submission floor applies |
| Compose 1.12 build floor | AGP 9.1.1 | On BOM 2026.08.00 adoption | Build fails; cannot take current Compose |
| Compose compile SDK | API 37 | On BOM 2026.08.00 adoption | Cannot take current Compose on an older SDK |
| 16 KB page support | 64-bit native code | 1 February 2027 | Updates blocked for apps with native libraries |
We cover the behaviour changes behind the newest of those numbers in our Android 17 API 37 migration guide and the policy mechanics in the API 36 Play Store deadline walkthrough.
The 16 KB question that separates Kotlin teams from NDK teams
The Android page-sizes guide, last updated 5 August 2026, sets a harder deadline further out: "Starting February 1, 2027, if your app updates don't support 16 KB memory page sizes, you won't be able to release these updates."
Ask a candidate whether this applies to your app and you learn a lot in ninety seconds. The same page answers it: "If your app only uses code written in the Java programming language or in Kotlin, including all libraries or SDKs, then your app already supports 16 KB devices." A pure-Kotlin app is already compliant. An app carrying a native SDK — a payment library, a video codec, an analytics agent with a bundled .so — is not, and nobody on the team may know which third-party dependency ships native code.
A good hire asks to see your dependency tree before answering. A weak one either panics or says "we're on Kotlin so we're fine" without checking what your vendors bundle.
What Kotlin proficiency is worth, using only figures Google publishes
Plenty of hiring content quotes precise-sounding adoption and salary-premium percentages for Kotlin. Most of them trace back to each other rather than to a survey. The figures Google publishes on its own Kotlin-first page, last updated 6 March 2026, are narrower and hold up:
- 67% of professional developers who use Kotlin say Kotlin has increased their productivity.
- Android apps that contain Kotlin code are 20% less likely to crash.
- Over 70 of Google's own apps are built using Kotlin, including Maps, Home, Play, Drive and Messages.
- On the Google Home team, moving new feature development to Kotlin produced a 33% reduction in codebase size and a 30% reduction in null-pointer-exception crashes.
The Google Home numbers are the useful ones in an interview. They describe what happens when a team migrates incrementally rather than rewriting, which is the situation almost every hiring manager is actually in. Ask a candidate to describe the sequence they would use to get a Java module onto Kotlin without a freeze. If the answer starts with "rewrite", keep looking.
Language versions: what "current Kotlin" means this month
Kotlin's release page is the only source worth quoting here. Kotlin 2.4.0 shipped on 3 June 2026, its support runs to 3 December 2027, and the latest bug-fix release on that line is 2.4.10 from 14 July 2026. Kotlin 2.4.20 is pencilled in for September 2026 and 2.5.0 for December 2026, both marked as approximate. The 2.4.0 line is compatible with Gradle 9.5.0 and added Java 26 support, stable context parameters and explicit backing fields, per JetBrains' 2.4.0 announcement.
For cross-platform work, Compose Multiplatform 1.11.0 landed in May 2026, with concurrent rendering on iOS now enabled by default rather than opt-in, and experimental native text input on UIView. If your roadmap has an iOS surface, that changes the shape of the hire: you may want one Kotlin Multiplatform engineer rather than two platform specialists. Our SwiftUI versus KMP comparison sets out where that trade actually pays and where it does not.
| Component | Version to hire against | Released | Support or next step |
|---|---|---|---|
| Kotlin language | 2.4.0 (patch 2.4.10) | 3 June 2026 (patch 14 July 2026) | Supported to 3 December 2027 |
| Compose BOM | 2026.08.00 | 12 August 2026 | Maps to Compose 1.12 modules |
| Android Gradle plugin | 9.1.1 | Required by Compose 1.12 | Hard floor for BOM 2026.08.00 |
| Gradle | 9.5.0 | Kotlin 2.4.0 compatibility target | Stated in JetBrains 2.4.0 post |
| Compose Multiplatform | 1.11.0 | May 2026 | Concurrent iOS rendering on by default |
A technical screen that predicts delivery
Résumé keywords do not separate candidates any more, because every Android CV lists Compose. These five questions do, and each one has a checkable answer in the sources above.
- "Our app targets API 34 and we last shipped in March. What is our Play status today, and what is our deadline?" The complete answer names both floors: the app is below API 35, so it is already hidden from new users on newer Android versions, and any update must reach API 36 by 31 August 2026 unless an extension to 1 November 2026 is requested.
- "We want the August 2026 Compose BOM. What breaks first?" The build, on Android Gradle plugin version, because Compose 1.12 needs AGP 9.1.1 and moves
compileSdkto 37.
- "Does the 16 KB page size rule apply to us?" Correct answer: it depends on whether any dependency ships 64-bit native code, and the way to find out is to inspect the merged APK, not to assume.
- "Walk me through raising `compileSdk` without raising `targetSdk`." This is the standard de-risking move — compile against the new SDK to surface deprecation warnings before opting into behaviour changes. A candidate who does not know the two knobs are separate has never run a migration.
- "Which of our crashes would Kotlin have prevented?" Tests whether they reason about null-safety concretely, in the spirit of the 30% NPE reduction the Google Home team reported, rather than reciting language marketing.
Give a take-home only if you are prepared to pay for it. A better substitute is a ninety-minute paired session on your actual build file. Version-catalogue conflicts and an AGP upgrade in a real repository reveal more than a greenfield to-do app ever will.
India-specific considerations
For teams hiring in India, PayScale reports an average salary of ₹728,256 in 2026 for an Android software developer with Kotlin skills, drawn from 145 salary profiles and last updated on 24 June 2026, with entry-level roles under one year of experience at ₹350,000. Treat that as a floor for calibration rather than a market rate: it is a self-reported dataset and a small one, and Bengaluru, Gurugram and Hyderabad do not price the same role identically.
The privacy question matters more than the salary question. Any Android app handling personal data of users in India falls under the Digital Personal Data Protection Act 2023, and the engineering consequences are concrete: consent capture in the app itself, deletion paths that reach analytics and crash-reporting SDKs, and a data inventory that includes anything a third-party SDK exfiltrates by default. A Kotlin developer who has instrumented consent gating around an advertising or analytics SDK is materially more useful than one who has only read the Act.
One more India-specific point on staffing shape. Teams here often carry a large Java codebase inherited from an earlier vendor. The Google Home figures above describe exactly that transition, and they argue for hiring one engineer who has done an incremental interoperability migration over three who have only built new Compose screens.
Contract, retainer or embedded: choosing the engagement shape
The version calendar should decide the engagement, not the other way round.
A fixed-scope migration fits when the work is bounded by a date you can read off Google's documentation: get to API 36 before 31 August 2026, or clear the 16 KB requirement before 1 February 2027. The scope is defined by someone else's deadline, which makes it estimable.
A retained platform capability fits when the problem is that these deadlines keep arriving. Kotlin ships a bug-fix release roughly every quarter, Compose ships a BOM on a similar cadence, and Play publishes a new target API floor every year. A team without standing capacity to absorb that will be late every single time, and lateness compounds: the further behind the toolchain you fall, the more expensive each jump becomes.
An embedded engineer inside your team fits when the codebase, not the calendar, is the constraint — a large Java estate, an undocumented build, or a dependency graph nobody has audited.
eCorpIT staffs all three shapes. We do not publish a rate card, because the honest answer depends on the state of your build file, and anyone quoting a day rate before seeing it is guessing.
Where Kotlin hiring sits against the rest of your stack
Kotlin is rarely hired in isolation. If the same roadmap includes a services layer, our pages on hiring Go developers and hiring Node.js developers cover the equivalent version constraints on the backend. If the choice is still open between native Android and a cross-platform framework, Jetpack Compose versus Flutter sets out the trade in build and hiring terms, and our Kotlin app development company page covers delivery rather than staffing. For the broader programme view, start at our mobile app development company in India overview.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based engineering organisation, founded in 2021, holding CMMI Level 5, MSME and ISO 27001:2022 certifications, with senior-led Android and Kotlin teams. We take on bounded migrations tied to a published deadline, retained capacity for teams that keep falling behind the toolchain calendar, and embedded engineers inside an existing squad. We design applications aligned with Digital Personal Data Protection Act 2023 requirements, including consent capture and deletion paths that reach third-party SDKs. Tell us where your build file sits today at /contact-us/ and we will tell you what the API 36 and AGP 9.1.1 work actually involves.
References
_Last updated: 19 August 2026._