AppReactors | Store Compliance for React Native in 2026: Privacy Manifests, 16 KB Pages, and Target API Levels

Most React Native release delays we get called into have nothing to do with the app. The build works, QA signed off, and then the submission bounces — a missing privacy manifest in a transitive dependency, an .so file that is not 16 KB aligned, a target API level that expired last month, or a data safety form that no longer matches what the SDKs actually collect.

This is the least glamorous part of shipping mobile, and it is the part most React Native teams discover a week before a deadline. Below is the compliance surface as it stands in 2026, what specifically bites React Native apps, and how to move each check left into CI.

1. Apple privacy manifests and required-reason APIs

Apple requires a PrivacyInfo.xcprivacy file that declares:

Collected data types — what your app collects, whether it is linked to identity, and whether it is used for tracking.
Required-reason API usage — a declared reason code for a set of APIs that were historically used for fingerprinting: file timestamps, disk space, system boot time, active keyboards, and UserDefaults.
Tracking domains — domains contacted for tracking purposes, which get blocked when the user denies App Tracking Transparency.

The React Native angle: you are responsible for your app's manifest, and each third-party SDK is responsible for its own. A dependency that ships a binary framework without a manifest will trigger a submission warning or rejection even though you never wrote the offending line.

What this looks like in practice:

UserDefaults is used by AsyncStorage and by most analytics SDKs — nearly every app needs the CA92.1 reason declared.
File timestamp and disk space APIs show up through file system, image caching, and crash reporting libraries.
Ad and attribution SDKs are the usual source of tracking domains.

In an Expo project you can express this declaratively rather than hand-editing native files:

{
  "expo": {
    "ios": {
      "privacyManifests": {
        "NSPrivacyAccessedAPITypes": [
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
            "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
          },
          {
            "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryFileTimestamp",
            "NSPrivacyAccessedAPITypeReasons": ["C617.1"]
          }
        ]
      }
    }
  }
}

In a bare project, add PrivacyInfo.xcprivacy to the Xcode project and make sure it is part of the app target's Copy Bundle Resources phase — a manifest that is in the repo but not in the bundle is the single most common false sense of security here.

Audit trick: after a release build, search the built .app and its frameworks for manifest files and for the required-reason symbols. Anything that uses the APIs but ships no manifest is a dependency to upgrade, replace, or raise with the maintainer.

2. Android 16 KB page size support

Google Play requires apps targeting recent Android versions to support 16 KB memory page sizes on 64-bit devices. Devices with 16 KB pages cannot load native libraries that were built assuming 4 KB alignment; the app crashes on launch.

React Native apps are full of native libraries. Hermes, Reanimated, MMKV, SQLite bindings, image codecs, ML runtimes, payment and mapping SDKs — each ships .so binaries.

What to do:

Move to current toolchains. Recent React Native and Expo SDK releases build 16 KB-aligned binaries by default with an up-to-date NDK and AGP. Most of the work is upgrading, not patching.

Audit prebuilt .so files. Any dependency shipping precompiled binaries built on an old NDK is a risk. Check alignment on the release AAB/APK:

unzip -o app-release.apk -d /tmp/apk >/dev/null
for so in $(find /tmp/apk/lib/arm64-v8a -name '*.so'); do
  printf '%s ' "$so"
  llvm-objdump -p "$so" | awk '/LOAD/ {print $NF; exit}'
done

Alignment should be 2**14 (16 KB), not 2**12.

Test on a 16 KB emulator image. Android Studio ships 16 KB system images; a launch smoke test on one belongs in your release checklist.

An app that passes the Play Console upload check can still crash on real 16 KB hardware if a dynamically loaded library is misaligned, so do not skip the emulator run.

3. Target API levels and the annual deadline

Both stores enforce moving targets:

Google Play requires new and updated apps to target a recent Android API level, with the bar rising every year around August–November. Apps that miss it cannot ship updates; older apps eventually stop being discoverable to new devices.
Apple requires builds compiled with a recent Xcode/SDK for App Store submission, which in turn constrains your minimum macOS and CI image.

For React Native this means your upgrade cadence is a compliance requirement, not a nice-to-have. targetSdkVersion bumps regularly bring behaviour changes that break apps: notification permission, scoped storage, background restrictions, foreground service types, edge-to-edge enforcement, and stricter intent and broadcast receiver rules.

Practical rhythm we recommend to clients: one planned React Native / Expo SDK upgrade per quarter, and treat the yearly target API bump as a scheduled project with QA time attached — not a patch release.

4. Data safety and privacy nutrition labels

Apple's privacy nutrition labels and Google Play's Data safety form are declarations of what your app actually collects. They drift constantly, because SDKs change what they collect between versions and nobody re-reads the form.

Make the declaration derived, not remembered:

Keep a docs/data-collection.md table: SDK → data collected → purpose → linked to user → used for tracking.
Update that table in the same PR that adds or upgrades an analytics, ads, attribution, crash, or support SDK. Make it a checklist item in your PR template.
Re-generate the store answers from the table before each submission.

If you use OTA updates, remember the second rule that applies here: JavaScript-only updates must stay within the behaviour and purpose your review and declarations describe. Shipping a new data-collecting feature over the air, with no store review, is exactly the scenario the OTA policies exist to catch.

5. Permissions, entitlements, and the strings that go with them

Rejections cluster around permissions that are requested but unexplained, or declared but unused.

iOS: every NS*UsageDescription must be specific about what the app does with the data. "This app requires camera access" is a boilerplate rejection; "Used to scan the barcode on your membership card" is not.
Android: sensitive permissions (background location, all-files access, exact alarms, SMS/call log) require a declaration form and often a demo video.
Dead permissions are a liability. A library you removed six months ago may still be merging a permission into your manifest. Inspect the merged manifest, not your source one:
```
./gradlew :app:processReleaseManifest
# then read app/build/intermediates/merged_manifests/release/AndroidManifest.xml
```
On iOS, diff the built Info.plist against your template for the same reason.
Remove what you do not need with an explicit tools:node="remove" entry rather than hoping the dependency drops it.

6. Account deletion, ATT, and the policy rules that need product work

Three items that are not code-only and therefore need lead time:

In-app account deletion. If your app creates accounts, users must be able to initiate deletion from inside the app. This needs a backend endpoint and a support policy, not a screen.
App Tracking Transparency. If you use IDFA or share data for cross-app tracking, you need the ATT prompt, correct manifest tracking domains, and matching nutrition labels. All three have to agree.
Payments. Digital goods generally have to go through in-app purchase; physical goods and services generally must not. React Native apps that mix a marketplace and a subscription need this mapped out before the review, because it is a business decision as much as an engineering one.

7. A CI gate that catches this before submission

Compliance failures are cheap to catch and expensive to discover. A release job that runs on every build to your production channel should:

Fail if PrivacyInfo.xcprivacy is missing from the built app bundle.
Fail if any bundled .so is not 16 KB aligned.
Diff the merged Android manifest and built Info.plist against a checked-in expected snapshot and fail on unexpected permissions or usage-description changes.
Assert targetSdkVersion and the iOS deployment/build SDK match the values your release policy pins.
Print the SDK inventory from docs/data-collection.md alongside the current dependency list and fail if a new networking SDK appears that is not in the table.

All five are shell checks over build artefacts. They cost minutes to run and routinely save a release cycle.

A pre-submission checklist

Privacy manifest present in the built bundle, with reason codes for every required-reason API in use
Every third-party framework ships its own manifest and signature where required
All bundled native libraries 16 KB aligned; launch smoke test on a 16 KB emulator image passes
targetSdkVersion and iOS build SDK meet current store minimums, with behaviour changes QA'd
Data safety form and privacy labels regenerated from the SDK inventory this release
Merged manifest and Info.plist reviewed; no orphan permissions; usage strings are specific
Account deletion path reachable in-app and working end to end
ATT prompt, tracking domains, and labels consistent with each other
OTA channel state verified: production points at the reviewed build's runtime version

Where this usually goes wrong

The pattern is almost always the same: compliance is treated as a submission-day task owned by whoever happens to be pushing the build. It should be owned like any other non-functional requirement — an inventory that is updated in PRs, a set of CI assertions over build artefacts, and a scheduled upgrade cadence that keeps you ahead of the annual deadlines.

If you are staring down a target API deadline, a 16 KB crash on new hardware, or a dependency that has no privacy manifest and no maintainer, get in touch — unblocking React Native releases is routine work for our consultants.