RejectProofRun the free check

Development server references left in the build

Check PB-30 · App Store Review Guideline 2.1 · Likely rejection when present · verified 2026-09-16

Why App Review rejects under Guideline 2.1

2.1 is the single most common rejection because it is a catch-all: crashes, dead links, placeholder content, a demo account that does not work, a feature the description promises but the build does not have. The reviewer runs the app on a real device for a few minutes and reports whatever breaks. The frustrating part is that most 2.1 rejections are mechanical and visible in the build before you upload: a framework that was not embedded (crash on launch), a support URL that returns 404, a leftover localhost address from development. Fix what they named, then look for what they did not name — on the next round they only re-check the diff.

How to fix it

This build still points at a local Metro / Expo dev server. Build a release binary: Expo → `eas build --profile production`; bare RN → Release configuration with a bundled JS file; make sure no exp:// or localhost:8081 URLs remain. Reviewers cannot reach your machine, so the app fails to load and is rejected under 2.1.

How RejectProof detects it

The scan reads your .ipa in the browser (or locally with npx rejectproof): Info.plist, entitlements, the privacy manifest, embedded frameworks and the executable itself. Check PB-30 reports the exact evidence it found — the key, the symbol, the file or the URL — so you can confirm it in your own project before changing anything. Nothing is uploaded; only a small redacted summary is sent to build the report, and you see it first.

Related Guideline 2.1 checks

← All rejection reasons