Short answer. From 1 October 2026, Apple's new EU business terms apply to developers who accept them. On 30 September, Google's deadline for registering Play package names passed, and Android developer verification started in Brazil, Indonesia, Singapore and Thailand. Play updates already have to target Android 16 (API level 36), and apps that sell through Google Play Billing need Billing Library 8 or later. The extensions some apps got end on 1 November 2026. App Store uploads need Xcode 26. Next, in 2027: four Play policy changes on 27 January; no Android updates without 16 KB page-size support from 1 February; memory and code-optimisation thresholds from February; sign-in restore on a new phone from April; App Store uploads built with the iOS 27 SDK from April; Billing Library 9 from 31 August; and developer verification worldwide, on a date Google hasn't set yet.
Three terms used below.
- Target API level (targetSdkVersion): the Android version your app says it was built and tested for. Raising it switches on that version's new behaviour.
- Native code: libraries written in C or C++ (.so files). They often arrive inside third-party SDKs, game engines and cross-platform frameworks.
- 16 KB pages: Android has always handled memory in 4 KB pages. From Android 15, devices can use 16 KB pages, and native libraries must be built for that [5].
What changed by 1 October 2026
Google Play and Android
| Rule | Applies to | Date | Status as of 1 Oct 2026 | What you need to do | Source |
|---|---|---|---|---|---|
| Target Android 16 (API level 36) | New apps and app updates on phones, tablets and Android Auto | 31 Aug 2026 | In force. An extension to 1 Nov 2026 could be requested from the Policy status page in Play Console | Raise targetSdkVersion to 36 before your next release. Test the behaviour changes below | [1] |
| Target at least Android 15 (API level 35) to stay visible | Existing apps you are not updating | 31 Aug 2026 | In force (same extension) | Below API 35, your app is only offered to devices on the same or an older Android version. New users on newer phones won't find it; people who already installed it keep it | [1] |
| Other form factors | Wear OS and Android Automotive OS: API 35 for new apps and updates. Android XR: API 34. Android TV: API 34 (since 31 Aug 2025) | 31 Aug 2026 | In force | Existing-app thresholds differ per form factor; check Google's table | [1] |
| 64-bit and 16 KB page-size support on TV and Wear OS | New Android TV and Wear OS app bundles that contain native code | TV: 1 Aug 2026. Wear OS: 15 Sep 2026 | In force | Ship 64-bit native libraries built for 16 KB pages. Kotlin- or Java-only apps are compatible by default | [10] |
| Use Play Billing Library 8 or later | New apps and app updates that sell through Google Play Billing | 31 Aug 2026 | In force. An extension to 1 Nov 2026 could be requested from the warning in Play Console | Update the billing library before your next release. Going straight to version 9 saves a second update before 31 Aug 2027 | [13] |
| Register every app's package name | All Play developers | 30 Sep 2026 | Deadline passed | Google registered 99% of apps automatically. Open your Play Console home page today. If it still lists an app, register it: Google set the deadline "to avoid global removal from Google Play" | [4] |
| Android developer verification, first countries | Apps installed from participating stores (Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore, GetApps) in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7+ | 30 Sep 2026 | In force | Apps from developers who haven't verified and registered are blocked from install on certified devices there. If you only distribute on Play, check Play Console for any app that wasn't registered automatically | [2], [3], [4] |
Apple App Store
| Rule | Applies to | Date | Status as of 1 Oct 2026 | What you need to do | Source |
|---|---|---|---|---|---|
| Build with Xcode 26 and a 26-series SDK | Every upload to App Store Connect (iOS, iPadOS, tvOS, visionOS, watchOS) | 28 Apr 2026 | In force | If your build machine or CI still runs an older Xcode, you can't ship an update | [7] |
| Target iOS 13 or later | iOS and iPadOS uploads | 9 Sep 2026 | In force | Raise the deployment target to at least iOS 13 | [7] |
| Answer the updated age-rating questions | Every app | 31 Jan 2026 | In force | Unanswered questions can interrupt update submissions. Check App Information in App Store Connect | [7] |
| EU trader status (Digital Services Act) | Apps on EU storefronts | Updates since 16 Oct 2024; removal since 17 Feb 2025 | In force | Provide and verify trader status, or the app is removed from EU storefronts | [7] |
| Approved reasons for listed APIs | New apps and updates, including code from third-party SDKs | 1 May 2024 | In force | Declare approved reasons for the listed APIs your app and its SDKs use | [7] |
Apple's new EU business terms (from 1 October 2026)
This section matters only if you sell digital goods or subscriptions to users on EU storefronts, or distribute outside the App Store in the EU.
Apple updated its Developer Program License Agreement on 18 August 2026. The new EU terms apply from 1 October 2026, or from the date you agree to them, whichever is later. Only the Account Holder can accept them [8]. On Apple's page (read 29 September 2026):
- One set of terms for the EU. The Core Technology Fee (a per-install fee) is replaced by the Core Technology Commission: 5%. It applies to digital sales in apps distributed outside the App Store, through alternative marketplaces or Web Distribution. The Initial Acquisition Fee and the Store Services Fee go away.
- App Store commission in the EU: 26% on sales through Apple In-App Purchase. It is 15% for members of the Small Business Program, the Mini Apps Partner Program and the Video Partner Program, and for auto-renewing subscriptions after the first year. With alternative payment processing inside the app: 20%, or 10% for the same groups.
- Link-outs: out-of-app offers with an actionable link carry a store services commission of 15% (10% for the same groups) on sales made within 7 days of the tap.
- Your payment choice is fixed for 12 months. Whatever mix you choose (Apple In-App Purchase, alternative processing, links to the web) must stay for 12 months.
- Child safety. For users under 13, alternative-payment purchases need a parental gate and out-of-app offers are not allowed. For users aged 13–17, both alternative processing and out-of-app offers need a parental gate. Apps in the Kids category must gate alternative-payment purchase flows and can't offer purchases on a website. Where an EU storefront sets a higher age of parental consent, that age applies instead of 13.
- Old addenda retire. From 1 October 2026, Attachment 14 of the license agreement takes over. It replaces the Alternative Terms Addendum for Apps in the EU and the StoreKit External Purchase Link Entitlement (EU) Addendum.
What is due next
| Date | What happens | Who should act now | Source |
|---|---|---|---|
| 1 Nov 2026 | Play's extensions end for the API 36 / API 35 requirements and for Billing Library 8 | Apps that asked for more time | [1], [13] |
| 27 Jan 2027 | Four Play policy changes take effect. Apps that don't need broad access to contacts must use the Android Contact Picker. The location button becomes the recommended minimum scope for precise location. READ_CALL_LOG is no longer allowed for verifying accounts by phone call. Geofencing is no longer an approved foreground-service use case | Apps that read contacts, ask for precise location, verify phone numbers through the call log, or run a foreground service for geofencing | [12] |
| 1 Feb 2027 | Play stops accepting updates without 16 KB page-size support (apps targeting Android 15+) | Any Android app with native code, directly or through an SDK | [5] |
| Feb 2027 (no day given) | New Play thresholds for memory use and bitmap memory on phones and tablets. Apps with more than 10 MB of DEX code (games: 50 MB) need at least 25% optimisation, obfuscation and shrinking. Apps that miss them "may see reduced app visibility and publishing capabilities" | Apps that use a lot of memory or keep bitmaps in memory in the background, and apps whose release builds skip R8 or another shrinker | [10], [11] |
| Apr 2027 (no day given) | Apps with a sign-in must restore it automatically when a user moves to a new Android phone or tablet ("Zero-Tap Sign-In", through the Restore Credentials API). Games are exempt for now. A Block Store integration live by 30 Sep 2026 counts. Apps under strict regulation, such as finance or healthcare, can ask for an exemption in Play Console before enforcement | Any app with a login | [10], [11] |
| Apr 2027 (no day given) | App Store uploads must be built with the iOS 27 / iPadOS 27 SDK or later (tvOS 27, visionOS 27 and watchOS 27 SDKs for those platforms), so Xcode 27 | Anyone whose build machine or CI image is on Xcode 26 | [15] |
| 31 Aug 2027 | New apps and updates must use Play Billing Library 9 or later: Google's table ends version 8 on this date. An extension to 1 Nov 2027 can be requested | Apps that sell through Google Play Billing | [13] |
| 2027, no exact date yet | Android developer verification covers all certified Android devices worldwide | Anyone who distributes Android apps outside Google Play; organisations without a D-U-N-S number | [2], [3] |
Already in force: crash and ANR thresholds. The February 2027 memory limits join the bad-behaviour thresholds Play already applies. Above a 1.09% user-perceived crash rate or a 0.47% ANR rate across all devices, or 8% for either on a single phone model, Play "may reduce the visibility" of your app and may show users a warning on its store listing. Play judges the last 28 days of data [14].
16 KB pages: who actually has work to do
- Kotlin or Java only? If your app and all its libraries and SDKs are written only in Kotlin or Java, Google says it already supports 16 KB devices. Google still recommends a test on a 16 KB emulator image [5].
- Not sure? In Android Studio, open Build > Analyze APK, pick your APK and look in the lib folder. Any .so file there means native code [5].
- Native code of your own: Android Gradle Plugin 8.5.1 or newer aligns uncompressed shared libraries for 16 KB. NDK r28 and newer compiles 16 KB-aligned by default. To check alignment from the command line, you need build-tools 35.0.0 or newer [5].
- Native code inside a third-party SDK: you need a version of that SDK its vendor has rebuilt. You can't fix someone else's binary, so ask the vendor first.
Developer verification in 2027
- Google's timeline says "2027 and beyond: global rollout for all certified Android devices", with no exact date yet [2].
- If you register as an organisation, you need a D-U-N-S number. It is free, but getting one can take up to 28 days [3]. Start before Google names the date.
- Apps installed with ADB are exempt, so your own testing is unaffected. Apps from an organisation's managed store are exempt too, though Google recommends registering them [3].
- Since August 2026, Google also offers limited distribution accounts: sharing with up to 20 devices, with no government ID or fee. Google describes them for students, teachers and hobbyists [2].
Not announced yet (29 September 2026): Play's next target-API step. Our reading of the past, not a forecast: Play's last two target-API steps both took effect on 31 August (API 35 in 2025, API 36 in 2026) [1].
Apple has announced its next minimum. Apple opened App Store submissions for iOS 27 on 9 September 2026 with the Xcode 27 release candidate, and from April 2027 uploads need the iOS 27 SDK (Xcode 27) [15]. That is in line with every earlier iOS Xcode minimum on Apple's page, which took effect in late April: Xcode 14.1 on 25 April 2023, Xcode 15 on 29 April 2024, Xcode 26 on 28 April 2026 (tvOS apps got their Xcode 14.1 minimum later, on 31 July 2023) [7]. If your build machine is older, plan the update for spring.
What a target-API bump actually changes
Raising targetSdkVersion is one line. The work is in what Android then stops doing for you. From API 35, apps are drawn edge to edge on Android 15 devices: content goes behind the status and navigation bars unless the app handles the system-bar insets [9]. For apps targeting Android 16 (API 36), Google lists these changes among others [6]:
- No more edge-to-edge opt-out. Apps targeting API 35 could still opt out. At API 36 that opt-out is disabled on Android 16 devices.
- Predictive back is on by default. On Android 16+, onBackPressed is no longer called and KEYCODE_BACK is no longer dispatched. Custom back handling must move to the supported back APIs, or use the temporary opt-out.
- Large screens ignore your orientation lock. On displays 600dp wide or more (tablets, foldables), orientation, resizability and aspect-ratio limits no longer apply, except for games. A portrait-only layout will be stretched unless it adapts. A temporary opt-out exists.
- Fixed-rate timers change. If scheduleAtFixedRate missed runs while the app was not in a valid lifecycle state, only one missed run fires when it returns, not all of them.
Is your app affected? A 2-minute check
- Your last Android release targets below API 35. New users on newer phones can't find it now.
- You plan an Android update but target below API 36. Play will reject it (unless you have the extension, which ends 1 Nov 2026).
- You sell through Google Play Billing with a library version below 8. Play won't accept the update (unless you have the extension, which ends 1 Nov 2026).
- Your Play Console home page still lists an app that needs package-name registration.
- You distribute an Android app outside Google Play (your website, other stores, APKs sent to customers or staff).
- APK Analyzer shows .so files in your app's lib folder. Check before 1 Feb 2027. (Kotlin- or Java-only apps are already fine.)
- Your app has a sign-in, and users who move to a new Android phone have to log in again. From April 2027 Play expects the sign-in to be restored automatically.
- Android vitals shows a crash or ANR rate above Google's thresholds, or your release build skips R8 or another shrinker.
- Your iOS builds come from a machine or CI image older than Xcode 26 (Xcode 27 from April 2027).
- Your iOS deployment target is below iOS 13.
- You sell digital goods or subscriptions on EU storefronts and use, or want to use, payments outside Apple In-App Purchase.
If any of these is true, the fix may be a day of work or a small project. It depends on how long the app has gone without updates.
Short on time? The order we'd suggest:
- Can you ship at all? Xcode 26 on the build machine. Target API 36 and, if you sell through Google Play Billing, Billing Library 8 or later (or the extensions, until 1 Nov 2026).
- Can new users still find you? Existing apps at API 35 or above. Package names registered.
- Start anything with a lead time. A D-U-N-S number (up to 28 days). A 16 KB build from any SDK vendor whose library ships native code.
- Rebuild for 16 KB and test on a 16 KB emulator image, well before 1 Feb 2027.
- Then the 2027 quality rules: memory use and code optimisation (February), sign-in restore on a new phone (April).
How we check this for clients
Our free high-level audit starts where this post ends. For an app that is already live, we check which of these store rules your next update has to meet, read what users complain about in your store reviews and, if you give us access, compare your crash and ANR rates with Google's thresholds. Then a 20-minute walkthrough, and a plan you keep.
On release pipelines, our work for MobileVision put automated test runs and quality gates between a code change and a release candidate. That is where a toolchain or target-API change should fail first: in CI, not in store review.
- If a store warning landed in your inbox, start with a free high-level audit.
- Prefer to talk first? Book a 30-min call below.
- Have your own team but no Android engineer free for the migration? We can add one to your team.
- Budgeting a bigger update? Try the app cost calculator.