App review glossary

Apple

App Store Review Guidelines. Apple's published rules for what may ship on the App Store, organised into five sections — Safety, Performance, Business, Design and Legal. Rejections cite a guideline number such as 2.1 or 5.1.1(v).

App Review. The human and automated process a submission passes through before release. Distinct from App Store Connect's upload validation, which happens earlier and produces ITMS- codes.

ITMS code. An error or warning identifier produced at upload time, before review. ITMS-91053 and ITMS-91061 are the privacy-manifest ones. Because they occur at upload, they block you before a reviewer ever sees the build.

Privacy manifest (PrivacyInfo.xcprivacy). A property list describing an app's or SDK's data collection, tracking domains and required-reason API usage. Apple's requirement is per-bundle: each executable or dynamic library using a required reason API needs a manifest in its own bundle.

Required reason API. An API that could be misused for fingerprinting, and whose use must be justified with an approved reason code. There are five categories: file timestamps, system boot time, disk space, active keyboards and user defaults. Full reference.

Approved reason code. A short identifier such as CA92.1 or 35F9.1 declared in NSPrivacyAccessedAPITypeReasons. You may only use the API and derived data for the reason you declared, and several codes carry binding conditions.

Privacy Nutrition Label. The data-collection summary shown on an App Store product page, declared in App Store Connect. Related to but separate from the privacy manifest.

Third-party SDK requirements list. Apple's published list of commonly used SDKs — 86 entries as of September 2026 — that must include a privacy manifest and a signature. Includes hermes, React Native's default JavaScript engine.

UIBackgroundModes. An Info.plist key declaring background capabilities such as location or audio. Guideline 2.5.4 rejects apps declaring the location mode without a genuine persistent-location feature.

Purpose string. An Info.plist key such as NSCameraUsageDescription explaining why the app needs a permission. Shown to the user in the system prompt, and read by App Review. In Expo projects these are frequently injected by config plugins rather than written by the developer.

Guideline 2.1 — App Completeness. Requires a fully functional submission, including working demo account credentials where a login is needed. Broken demo logins are a common and entirely self-inflicted rejection.

Guideline 2.3.10 — Accurate metadata. Prohibits, among other things, references to other mobile platforms in your metadata. Screenshots showing an Android device, or a description mentioning Google Play, get caught here.

Guideline 4.2 — Minimum Functionality. A judgement call about whether the app does enough to justify existing as an app rather than a website. No static tool can predict it.

Guideline 4.3 — Spam. Covers duplicate apps and apps that are one of many near-identical submissions. Also a judgement call.

Guideline 5.1.1 — Data Collection and Storage. The privacy cluster, including (i) privacy policies, (iii) data minimisation, and (v) the requirement that apps supporting account creation also offer in-app account deletion.

Guideline 5.1.5 — Location Services. Requires that location use be relevant to the app's features and that the app remain functional if the user declines. Apps that demand "Always" up front or do not work without location are rejected here.

Resolution Center. The messaging surface in App Store Connect where a rejection is delivered and where you reply. A specific, clause-level reply attached to the submission is materially more effective than a silent resubmission.

App Review Board. The escalation path if you believe a rejection was wrong.

Google Play

Developer Program Policy. Google's equivalent of the Review Guidelines, and the ruleset enforced against apps and developer accounts.

Data safety section. A required Play Console declaration of what data your app collects and shares, its purposes, and whether it is encrypted in transit. Must cover data handled by third-party SDKs. Detail.

Permissions Declaration. An additional form required for sensitive permissions such as ACCESS_BACKGROUND_LOCATION, usually including a demonstration video and a justification that the permission is core functionality.

Target API level. The Android API level your app targets. Google sets an annual deadline after which new apps and updates must target a recent level; missing it blocks publishing rather than triggering a review conversation.

Foreground service type. A declaration of why a foreground service runs — location, data sync, media playback and so on. Types must match actual behaviour and be declared in the manifest.

Closed testing requirement. Google's requirement that certain new personal developer accounts run a closed test with a minimum number of testers over a set period before applying for production access. Check the current thresholds in Play Console — they have changed since introduction.

Merged manifest. The AndroidManifest.xml produced by combining your manifest with every library's. It is the file that actually ships, and where permissions you never declared appear.

React Native and Expo

Continuous Native Generation (CNG). Expo's model in which ios/ and android/ are generated from app config and config plugins rather than committed. Hand edits to those directories are overwritten by the next prebuild — a very common cause of a fix that works locally and fails on the build server.

Prebuild. The step that generates the native projects from app.json / app.config.js and config plugins.

Config plugin. A function that modifies the generated native project — adding an Info.plist key, a manifest permission, or a build setting. The usual reason an Expo app has permission strings nobody wrote.

Podfile.lock. The resolved CocoaPods dependency graph. The authoritative answer to "which version of which transitive pod am I actually shipping," and therefore the file that determines your privacy-manifest exposure.

Transitive dependency. A package pulled in by another package. nanopb and Abseil arrive under Firebase and gRPC; nobody installs them deliberately, and both are on Apple's required-SDK list.

hermes. React Native's default JavaScript engine, and an entry on Apple's third-party SDK requirements list — which is what makes privacy manifests a near-universal React Native concern rather than a Firebase one.

EAS Build / EAS Submit. Expo's hosted build and store-submission services. Relevant here because each build cycle is 20 to 40 minutes, which is what makes a pre-submission static check worth running.