The annual OS release: what actually changes for a React Native app

The hard gates

Apple's SDK requirement. Apple publishes, in advance, the SDK version that new submissions and updates must be built with. It is announced with lead time and it is absolute on the date. Check the upcoming-requirements page rather than relying on a memory of last year's date.

Play's target API level. Two separate floors: one for new apps, one for updates to existing apps, each with published deadlines. Below the update floor, your app stays in the store and can no longer be updated, which means you cannot ship a fix. Target API level, in detail.

Play's other periodic requirements. Data safety obligations and testing requirements have changed on their own schedules and are worth checking annually rather than assumed stable. Data safety. · Closed testing.

The soft breaks worth checking first

Ordered by how often they actually cause user-visible problems in RN apps:

Permissions. Prompt wording, timing, what a partial grant means, and whether a previously granted permission behaves the same. Test every prompt on a genuinely fresh install, because a device that already granted everything will show you nothing.

Background execution. Background tasks, location updates and long-running work get progressively more restricted. Anything that depends on running while backgrounded deserves an explicit test rather than an assumption. Guideline 2.5.4, background modes.

Notifications. Presentation, grouping, permission behaviour and delivery timing.

Layout and safe areas. New device shapes, new inset behaviour, changed system font metrics. The visible one, and the least serious.

Privacy and identifiers. The direction is always tighter. This is also where a dependency's behaviour can change without your code changing. App privacy labels. · Privacy manifests.

Deprecated APIs used by dependencies. An old native module reaching for something removed is a crash on the new OS and a silent pass on the old one. Guideline 2.5.1, private APIs.

Testing against a beta

An afternoon, once, on a spare device:

1. Install the OS beta on a device you do not need.
2. Install your current production build. Not a dev build.
3. Fresh account. Every permission prompt. Read what each one says.
4. Airplane mode on, use the app, off.
5. Background it for ten minutes, come back, see what state it is in.
6. Push notification, from cold.
7. Every screen with a system component: pickers, sheets, camera, maps.

Steps 3 and 5 find most of it. They are also the two nobody does, because they are tedious and the app "obviously works."

The Expo SDK question

Upgrade annually. Not because new is better, but because the store floors move and the SDK is how a managed project gets a compatible native layer without hand-maintaining it.

The cost of deferring compounds in a specific way: each skipped version adds breaking changes, and they interact. One upgrade is a day. Three at once, in October, with a Play deadline in the way, is a fortnight.

Do it early in the year, not in the month the deadline lands. The EAS submission checklist.

The annual checklist

# what the stores currently require
open https://developer.apple.com/news/upcoming-requirements/
# and the Play target API level page, and your Console's own warnings

# where you actually are
grep -E '"expo"|"react-native"' package.json
grep -n 'targetSdkVersion\|compileSdkVersion' android/build.gradle app.json app.config.js 2>/dev/null

# native packages that have not moved in a while
npm outdated 2>/dev/null | head -30

Then do the hard gates, then the behaviour tests, then the layout. In that order, every year, and the September panic stops being annual.

shipcheck reports your current target levels and SDK versions against the stores' published requirements, and flags native dependencies that have not been updated across an OS boundary. What it checks. · The first-submission checklist.

Questions and answers