Mobile apps for Android 16 KB pages, passkeys and store deadlines
Cohash keeps enterprise and consumer mobile apps shippable when Google and Apple change their rules. We raise target SDKs, rebuild native libraries for Android's 16 KB memory pages, move iOS builds to the current Xcode, and update third-party SDKs that block either. While the app is open, we add passkey sign-in through Android Credential Manager and iOS, wired to your identity provider.
- 01Build and dependency audit
- 02Android target and 16 KB fixes
- 03iOS toolchain update
- 04Passkey sign-in
- 05Staged release
The story
Told without the client's name or anything that could identify them.
Play Console started warning a retailer's mobile team that its Android app didn't support 16 KB page sizes. On the iOS side, CI still used an Xcode version App Store Connect had stopped accepting. With Google Play requiring Android 16 (API 36) targets since 31 August 2026, the team was close to being unable to ship a fix. We audited SDK levels, toolchains and every native library, which showed exactly which third-party SDKs were blocking the build. Both apps now build on current toolchains, and customers can sign in with a passkey.
why it was urgentSince 31 August 2026, Google Play has required new apps and updates to target Android 16 (API 36), with extensions to 1 November 2026. From 1 February 2027, an app that targets Android 15 or higher can't release updates without 16 KB page size support. Apple's side is simpler. Uploads have needed Xcode 26 and the iOS 26 SDK since 28 April 2026.
- openPlay Console warns that your app does not support 16 KB page sizes.
- recurringThe app bundles native .so libraries from an SDK the vendor stopped updating.
- blockedYour CI still builds iOS with an Xcode version App Store Connect no longer accepts.
- openAccount takeover and password reset tickets keep going up. Security asked about passkeys.
The estate, before and after
Before: builds the stores were about to refuse
Android bundled native libraries from an SDK with no 16 KB build, and iOS CI was on an Xcode version the App Store no longer accepts. Customers signed in with passwords against the identity provider.
Read the diagram as text
- Unmaintained native SDK → Android app: unaligned .so
- Android build → Android app: build
- iOS CI → iOS app: build
- Android app → Google Play Console: update blocked
- iOS app → App Store Connect: upload rejected
- Android app → Identity provider: password
- iOS app → Identity provider: password
After: current toolchains and passkey sign-in
Both apps now build on the toolchains the stores require, with native libraries rebuilt for 16 KB pages. Users sign in with passkeys through the platform credential APIs, checked against the app's domain files, with the same identity provider behind them.
Read the diagram as text
- Updated native SDKs → Android build: 16 KB .so
- Android build → Android app: release build
- iOS build → iOS app: release build
- Android app → Google Play: staged rollout
- iOS app → TestFlight and App Store: TestFlight build
- Android app → Asset links · associated domains: asset links check
- iOS app → Asset links · associated domains: associated domains
- Android app → Identity provider: passkey sign-in
- iOS app → Identity provider: passkey sign-in
How we run it, phase by phase.
5 phases take you from Mobile apps on older SDKs and password sign-in to Current Android and iOS SDKs with passkey sign-in. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Build and dependency audit
Write down target and compile SDK levels, Xcode version, Gradle and Android Gradle Plugin versions, plus every third-party SDK with native code. Check the ELF alignment of each native library for 16 KB pages.
- phase 02
Android target and 16 KB fixes
Raise targetSdk to 36, handle behavior changes for that level, update or rebuild native libraries with 16 KB alignment, and test on a 16 KB emulator image before release.
- phase 03
iOS toolchain update
Move CI to Xcode 26 and the iOS 26 SDK, and fix what's deprecated. Check that the minimum deployment target still covers your users at iOS 13 or higher.
- phase 04
Passkey sign-in
Passkeys go in through Android Credential Manager and the iOS passkey APIs. We set up the asset links and associated domains files and connect everything to Auth0, Okta or Entra ID. Passwords stay available as a fallback until adoption numbers are in.
- phase 05
Staged release
Ship through Play staged rollout and TestFlight, watch crash rates and sign-in errors, then widen the rollout.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Android releases target API 36 with 16 KB-aligned libraries
The app targets SDK 36 now, with that level's behavior changes dealt with. We updated or rebuilt each native library for 16 KB alignment and tested them on a 16 KB emulator image.
- result 02
iOS builds run on Xcode 26 and the iOS 26 SDK
We moved iOS CI to the toolchain App Store Connect requires and cleared the deprecations, keeping a minimum deployment target that covers the app's users.
- result 03
Customers can sign in with a passkey
We added passkeys through Android Credential Manager and the iOS passkey APIs, put the asset links and associated domains files in place, and connected the existing identity provider. Passwords stay as a fallback.
- result 04
Losing a phone doesn't lock a customer out
We built and tested a recovery flow for users who lose every device, before passwords became optional.
- result 05
Store deadlines have a checklist
Each release goes through a checklist for target API, page size and Xcode rules, then out through Play staged rollout and TestFlight while we watch crash and sign-in errors.
Risks we plan for
-
Abandoned native SDKs
One analytics or payment SDK with no 16 KB build blocks the whole app. We find these in the audit, so there's time to replace them.
-
Behavior changes at a new target level
Each Android target level changes permissions, background work or edge-to-edge layout rules. Testing covers those; a clean build proves little.
-
Passkey account recovery
Someone who loses every device is locked out of passkeys unless recovery was designed in. We build and test recovery flows before passwords become optional.
Where AI helps, and where it needs guardrails
AI assistants help with this sort of work: reading release notes, spotting deprecated APIs, drafting Gradle and Xcode fixes, which we then check on real devices. An app with an AI agent inside it is a different matter. The agent has to act with the signed-in user's scoped token. A shared API key in the app bundle is the thing to avoid.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- evidence01
SDK, toolchain and native library audit with a fix per item
yours to keep - code02
Android build targeting API 36 with 16 KB-aligned libraries
yours to keep - code03
iOS build on Xcode 26 and the iOS 26 SDK
yours to keep - document04
Passkey sign-in with recovery flow, connected to your identity provider
yours to keep - document05
Release checklist for future store deadlines
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01What happens if we miss the Google Play target API deadline?
Play won't accept new updates until the app meets the target level, apart from any extension you got. People who already have it keep using it. You just can't ship them a fix.
02Does 16 KB page support affect us if we have no native code?
If the app is pure Kotlin or Java, it probably works already. Native libraries are the risk, and plenty of third-party SDKs and cross-platform frameworks bundle them. The audit shows which ones you have.
03Do passkeys replace our identity provider?
No. A passkey is just a way to sign in. Auth0, Okta or Entra ID still owns accounts, sessions and policy. The app plugs into whatever passkey support your provider offers.
04Can you handle React Native or Flutter apps?
Yes, the same rules apply. Usually the framework version and its native modules need updating before anything else.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study0c890878 - 01Google Play: Target API level requirementssupport.google.com ↗
- 02Android Developers: Support 16 KB page sizesdeveloper.android.com ↗
- 03Apple Developer: Upcoming requirementsdeveloper.apple.com ↗
- 04Android Developers: Passkeys with Credential Managerdeveloper.android.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it