Guides

The six-minute pre-submission pass

# 1. Which dependencies already ship a privacy manifest?
find node_modules -name "PrivacyInfo.xcprivacy" | sed 's|node_modules/||' | cut -d/ -f1 | sort -u

# 2. Every manifest in the tree parses?
find . -name "PrivacyInfo.xcprivacy" -exec plutil -lint {} \;

# 3. What permissions and background modes do you actually ship?
/usr/libexec/PlistBuddy -c "Print" ios/*/Info.plist | grep -i 'UsageDescription' -A1
/usr/libexec/PlistBuddy -c "Print :UIBackgroundModes" ios/*/Info.plist 2>/dev/null

# 4. What did your libraries add to the Android manifest?
find android -path '*intermediates*' -name 'AndroidManifest.xml' | head -1 \
  | xargs grep -E 'uses-permission|foregroundServiceType'

# 5. Does anything in your metadata name another mobile platform?
grep -rniE 'android|google play|play store' fastlane/metadata/ store/ 2>/dev/null

Then answer one question per finding: which user-facing feature stops working if this is removed? Anything you cannot answer is a rejection waiting, because App Review will ask the same question and you will not have a better answer then.

The one that catches Expo teams

With continuous native generation, ios/ and android/ are build artefacts, regenerated on every prebuild. A fix applied there works locally, vanishes on the build server, and produces an identical second rejection — two cycles, several days, and the change was correct both times.

Anything that must survive a build has to live in app.json, app.config.js or a config plugin. Why RN and Expo fail differently.

Everything in this section

• Setting up App Store Connect for the first time — Several things can only be set once, several are checked at submission, and a few are much harder to change later. The order to do them in, and the fo
• Auditing the permissions your config plugins added — Your Info.plist and AndroidManifest contain permission strings nobody on your team wrote. How to find them, decide which are real, and remove the rest
• Submitting an Expo app with EAS: the checklist — The failures specific to EAS Build and EAS Submit, in the order they bite: config that did not reach the binary, credentials, build profiles, environm
• First submission checklist — Everything that is deterministic and findable before you build, in the order it costs you if you miss it. Both stores, with the Expo-specific traps ma
• Launching on Google Play: the checklist — Play blocks releases with forms and automated checks rather than with a reviewer's opinion, so the work is different. Everything that gates a first re
• Removal and suspension: what to do, in order — Removal is not a rejection and it moves faster. What each store does, what you can and cannot recover, the appeal that works, and the preparation that
• Push notifications: the rules and the RN failures — Marketing pushes need consent, health information must not appear in a notification, and the permission prompt at launch is the most common self-infli
• Shipping alone: what to check, what to skip — The compliance surface is the same size for one person as for a team. What actually has to be done, what can be deferred honestly, and the order that
• The first update: what changes after launch — Updates are reviewed too, live users make mistakes expensive, and three mechanisms exist that did not matter before launch. What to use and what to be
• Submitting an AI app: what applies, all at the same time — An AI app can be evaluated under content safety, third-party data sharing, spam, hidden features and age rating in a single review. What each one want
• TestFlight beta review: what it actually checks — External TestFlight testing goes through its own review, and passing it is not a preview of App Review. What each one checks, why passing beta review
• Universal links: the setup that fails without an error — Two files on a website, two entries in app config, and no error message when any of it is wrong. What to check, in what order, and why this is the fea
• The annual OS release: what actually changes for a React Native app — Every September and every Play deadline moves the floor. What is a hard gate with a date, what is a soft break that shows up as a bug report, and the
• Rejected: the order of operations that gets you approved fastest — Read the citation, not the summary. Decide between fix, clarify and appeal. What to write in the resolution centre, when appealing is right, and the m
• When a dependency is blocking your release — An unmaintained package with a missing privacy manifest, a private API call or a permission you cannot remove. The five options, ranked by how long ea
• When a reviewer cannot test your app — Apps that need hardware, a physical service, a real customer, a paid account or a specific location are rejected for being untestable rather than for
• Writing store copy that survives review — Four guidelines apply to your listing text, and the failures are boringly consistent. What to cut, what to keep, and the check that finds most of it i