Software Engineering · Chapter 18 of 31
The platform gates: distribution as an engineering constraint
Target-API deadlines, the end of anonymous Android distribution, an AI consent screen you must build, and a fee model that changed last week.
Mobile platform policy is usually treated as somebody else's problem — legal's, or the product manager's. It is not. Several of the changes below alter what you have to build, and one of them ends a distribution model that has existed since Android launched.
Target API levels, and what non-compliance actually does
From 31 August 2026, new apps and updates on Google Play must target Android 16 for mobile, with lower floors for watch, automotive, TV and mixed-reality form factors. Existing apps must target Android 15 or later to stay available to new users on devices running a newer OS than the app targets.
The consequence is precise and often misstated: non-compliant apps do not stop working and are not removed. They become undiscoverable to users on newer Android versions — existing installs continue, new installs stop. An extension is available to 1 November 2026, and permanently private internal-distribution apps are exempt.
Developer verification: the biggest distribution change in a decade
From 30 September 2026, in Brazil, Indonesia, Singapore and Thailand, an app must be registered by a verified developer to install on certified devices running Android 7 or later — across participating stores, not just Google Play. Global rollout follows from 2027.
Play auto-registers about 99% of existing apps. Developers distributing exclusively outside Play register through a separate console.
Standard accounts require a government-issued ID and a registration fee. Limited-distribution accounts for students, teachers and hobbyists need no ID and no fee — but cap at 20 devices.
Sideloading unverified apps survives through an ‘advanced flow’ for power users, which press reports adds a mandatory waiting period.
Why this belongs in an engineering chapter: it ends anonymous Android distribution. It reaches internal enterprise app delivery, independent app stores, and any continuous-integration pipeline that installs an unsigned build onto a certified device. And it is the first time the sideloading path itself has been gated by identity rather than just by a warning dialog.
Apple: the SDK floor, and an AI disclosure you have to build
- Since 28 April 2026, uploads must be built with the current major Xcode and platform SDKs. This gate moves annually and blocks submission outright, so it belongs in your release-tooling upgrade plan rather than in a compliance spreadsheet.
- Since May 2024, privacy manifests must declare approved reasons for required-reason API use — file timestamps, disk space, active keyboard, user defaults, system uptime. For your own code and every third-party SDK you embed. It remains among the most common rejection causes, and the reason is almost always a dependency rather than your own code.
- Since 31 January 2026, updated age-rating questions must be answered or submissions are interrupted.
The AI consent screen is an engineering requirement, not paperwork
Apple revised its review guideline on third-party data sharing in November 2025. It now requires that you clearly disclose where personal data will be shared with third parties, including third-party AI, and obtain explicit permission before doing so.
In practice that means an in-app consent screen naming the specific provider and the data shared. A link to your privacy policy is not sufficient.
On-device inference does not trigger it, because nothing leaves the device. Any transmission to an external model does — even a transient one.
Why this is engineering work: it changes your onboarding flow, adds consent state you must persist and respect, affects your analytics, and makes “which model provider” a user-visible product decision rather than an internal one. Switching providers becomes a user-facing change.
Expect this in interviews at any company shipping AI features on iOS. Most candidates have not heard of it yet.
The EU fee model, which changed this month
Apple announced an overhaul of its EU regime on 18 August 2026, settling its dispute with the European Commission. The per-install fee is replaced by a 5% Core Technology Commission on digital goods and services revenue, applied across every EU distribution path — the App Store, web distribution and alternative marketplaces alike. App Store apps using Apple's payment system land at 26% in total; web-distributed apps pay the 5%. Developers may now offer Apple's payment system alongside alternatives. Effective 1 October 2026.
Operating an alternative marketplace from that date requires meeting one of several bars — publicly traded, venture-funded, audited, government or nonprofit, a million-dollar standby letter of credit, or a million first-year installs worldwide.
The durable point for an engineer: EU distribution is now a commercial architecture decision with a real number attached — a 5% floor regardless of path — rather than a hypothetical. And it is moving fast enough that anything you read about it carries an expiry date.
Review timelines, and why they are an architecture input
Apple's own published guidance is that half of apps are reviewed within 24 hours and 90% within 48. Independent trackers report meaningfully more variance, with first submissions slower than updates. Plan for 24–72 hours on updates and up to a week on a first submission.
That is precisely why over-the-air update capability is an architectural advantage rather than a nicety. If your incident response for a production bug is ‘submit and wait’, your mean time to recovery is set by a review queue you do not control. If it is ‘push a JavaScript bundle’, it is set by your own pipeline. That difference is a legitimate input to the cross-platform decision in the previous chapter, and it is a much better argument for React Native than code sharing is.
Check yourself