Every App Store Review Blockers Audit check

Apple App Review Guideline 2.1 (App Completeness) and Google Play's Minimum Viable Product policy both reject submissions containing lorem ipsum, TODO markers, or `Coming soon` placeholders on sight. Reviewers open the app as a real user, navigate to every tab, and flag unfinished copy within minutes. A single rejection costs 1–3 days per review cycle, burns reviewer goodwill on future submissions, and blocks marketing launches already committed to press, paid acquisition, or investor demos.

Why this severity: High because a single placeholder string triggers automatic rejection and delays launch by multiple review cycles.

Visible `Beta`, `Alpha`, `Preview`, or `v0.3.1` labels signal to App Review and Play Console reviewers that the submitter is using the public store as a test environment, which violates Apple Guideline 2.2 (Beta Testing) — TestFlight is the only sanctioned beta channel. Debug overlays, raw JSON error dumps, and ungated developer panels leaking into production builds also trip the same guideline and cause immediate rejection, often with a terse reviewer note that wastes a full resubmission cycle.

Why this severity: High because beta indicators cause immediate rejection under Apple Guideline 2.2 and Play policy.

Dead-end screens are a leading cause of App Store rejection under Apple's guideline 2.1 (completeness). Reviewers systematically navigate every registered tab and screen — a blank render or immediate crash on any reachable route results in an automatic reject. ISO 25010:2011 functional-completeness defines this failure directly: functionality that exists in the navigator but cannot be used provides zero functional value and destroys reviewer trust, putting the entire binary at risk regardless of how polished the rest of the app is.

Why this severity: Critical because a single blank or crashing screen causes immediate rejection — no other metric matters if a reviewer cannot navigate the app.

A crash on launch is the highest-severity rejection — the reviewer cannot evaluate any other part of the app. Apple tests on multiple OS versions and device types; an unhandled exception in root initialization code (unguarded `useEffect`, top-level `JSON.parse`, missing optional chaining) will crash on at least one configuration. CWE-390 (detection of error condition without action) and ISO 25010:2011 fault-tolerance both classify this as a fundamental reliability failure. One uncaught rejection in a startup async chain means the entire binary is rejected.

Why this severity: Critical because a launch crash makes the app completely unreviable — no functionality can be evaluated and rejection is immediate.

Apple's watchdog process kills any app that doesn't become interactive within 20 seconds of launch. Google Play triggers an ANR (Application Not Responding) rejection when the main thread blocks for more than 5 seconds. Synchronous I/O in module initialization, blocking API calls before the first render, or missing `SplashScreen.hideAsync()` calls all cause the app to appear frozen — ISO 25010:2011 time-behaviour failure. A slow launch doesn't just risk rejection; it trains reviewers to view the app as low quality, increasing scrutiny of everything else.

Why this severity: High because exceeding Apple's 20-second watchdog threshold causes an automatic process kill and rejection, reproducible on any network-constrained device.

Reviewers deliberately test on degraded networks and with edge-case data. Empty `catch` blocks (CWE-390) that swallow errors produce blank white screens — a visible failure that signals low quality and triggers rejection under Apple's guideline 2.1. ISO 25010:2011 fault-tolerance requires systems to continue operating under abnormal conditions. Beyond rejection risk, raw error messages (`{error.message}`) leak implementation details and destroy user trust. A screen that shows nothing when the network is bad is indistinguishable from a bug.

Why this severity: High because empty catch blocks and missing error states produce blank screens that reviewers directly observe, causing rejection under guideline 2.1.

Requesting camera, location, and notification permissions simultaneously on first launch is one of Apple's most-cited rejection reasons under guideline 5.1.1 (data collection and storage). Users who see a permission flood immediately deny everything, and reviewers interpret it as a sign the developer hasn't thought about why each permission is actually needed. More practically: a user who denies all permissions on first launch may never see the feature that needs them, making the permission useless. Contextual permission requests — asked at the moment the feature is first triggered — produce dramatically higher grant rates and clearer justification.

Why this severity: Medium because permission floods are a documented rejection trigger under Apple guideline 5.1.1, though the app may still function if users deny.

Apple explicitly tests offline behavior during review, and ISO 25010:2011 fault-tolerance requires graceful degradation under abnormal network conditions. An app that shows a blank white screen or a frozen loading spinner when launched without connectivity fails the most basic resilience test. `TypeError: Network request failed` propagating to a blank screen is indistinguishable to the reviewer from a crash. Apps that rely entirely on live API calls with no offline fallback and no timeout fail not just on review but in real-world use — poor connectivity is not an edge case.

Why this severity: High because an app that shows a blank screen offline will fail Apple's explicit offline testing during review, causing rejection under guideline 2.1.

Apple's App Store Review Guideline 1.2 explicitly requires apps with user-generated content to provide a mechanism for users to flag objectionable content. Missing a report button on posts, comments, or messages is one of the most common UGC-related rejection reasons. Without it, reviewers cannot verify that your platform has any safeguard against harassment, hate speech, or illegal content — and they will reject on that basis. A stub report button that calls `console.log` instead of hitting an API has the same outcome: the content has nowhere to go, and your platform has no moderation capability.

Why this severity: High because Apple guideline 1.2 makes a reporting mechanism a mandatory requirement for any app with UGC — its absence is a direct rejection cause.

Apple's guideline 1.2 requires apps with UGC to have "a mechanism to filter objectionable material from being posted." A report button with nowhere to send reports — no database table, no admin routes, no moderation queue — satisfies the UI requirement but fails the policy requirement. Reviewers checking for moderation infrastructure will find nothing, and the app gets rejected. Beyond review risk, an app that accepts user content with no ability to act on reports or ban users becomes a liability the moment objectionable content appears. Even a minimal implementation (reports table + admin screen + ban capability) satisfies Apple's requirement.

Why this severity: High because Apple guideline 1.2 mandates filtering mechanisms for UGC platforms — no backend moderation infrastructure means no compliance, and rejection follows.

Apple's guideline 1.2 explicitly requires apps with user interaction features to offer users the ability to block abusive users. A direct messaging app, a commenting feature, or a following system without a block mechanism leaves users with no recourse against harassment. The reviewer will look for it, not find it, and reject. Beyond review compliance, a missing block feature has real safety consequences: users who cannot escape harassment churn immediately and leave negative reviews. The block relationship must be server-side — client-only blocks that reset on reinstall or across devices are not acceptable.

Why this severity: Medium because Apple guideline 1.2 mandates block/mute capability for any app with user-to-user interaction, with rejection as the direct consequence of omission.

Apple's guideline 1.2 requires apps accepting user-generated text to filter objectionable content before it is stored and shown to others. Storing post or comment text directly to the database with no filtering (CWE-20, OWASP input validation) means a reviewer can post profanity or offensive content in your app and immediately see it appear — a scenario that results in rejection. Client-side filtering alone is insufficient because it is trivially bypassed via direct API calls. The combination of server-side filtering and the reporting mechanism (ab-000498) is the minimum acceptable moderation stack for any UGC platform.

Why this severity: Medium because unfiltered UGC submission directly violates Apple guideline 1.2 and any reviewer can verify the failure in seconds by typing into a post field.

Apple's guideline 1.2 requires UGC platforms to have users agree to community guidelines — implicit agreement through account creation is not sufficient. Failing to record and enforce terms acceptance means you have no legal standing when content violations occur and no proof that users were informed of the rules before posting. Beyond Apple's requirement, `tos_accepted_at` on the user record is the timestamp your legal team needs if a content dispute escalates. The gating must be server-side: a UI checkbox alone can be bypassed, and direct API calls from determined users would bypass it entirely.

Why this severity: Low because this is a compliance hygiene issue that primarily affects legal standing and guidelines conformance rather than causing direct harm on its own.

Apple's automated binary scanner (run before any human reviewer sees the app) uses symbol analysis to detect private API calls. This check is mechanical and highly accurate — a single `_`-prefixed private method call on a system object causes automatic rejection before human review begins, under Apple's guideline 2.5.1. The rejection email cites the specific private symbol. Native modules in the `ios/` and `android/` directories of React Native apps are the most common vector — they often include private API calls that were acceptable in older OS versions but have since been flagged. Apps rejected this way go to the back of the queue, adding weeks of delay.

Why this severity: Critical because Apple's automated scanner detects private API usage before human review — rejection is automatic, fast, and cannot be appealed without a code fix.

Apple requires all iOS apps to work on IPv6-only networks and tests this during review using an IPv6 NAT64 hotspot. Hardcoded IPv4 addresses (e.g., `192.168.1.100` that leaked from a development config) break immediately on IPv6-only networks because those addresses cannot be reached. This is a direct rejection cause for iOS submissions. ISO 25010:2011 operational-readiness requires software to function in the range of environments it claims to support — IPv6-only networks are widespread in cellular carrier environments and Apple's own review lab.

Why this severity: Medium because IPv6 failures cause rejection only during Apple's specific IPv6 test, but that test reliably catches any hardcoded IPv4 production URL.

App Transport Security (ATS) is Apple's network security framework — disabling it with `NSAllowsArbitraryLoads: true` in `Info.plist` allows all HTTP traffic, exposing users to man-in-the-middle attacks (CWE-319, OWASP A02 Cryptographic Failures). Apple requires a written justification for any ATS exception, and blanket disabling is frequently rejected without a compelling reason. HTTP API calls transmit auth tokens, personal data, and session information in cleartext — on public Wi-Fi, any observer on the network can read them. On Android, `android:usesCleartextTraffic="true"` in `AndroidManifest.xml` has the same effect.

Why this severity: Critical because `NSAllowsArbitraryLoads: true` exposes all network traffic to interception and triggers rejection unless Apple accepts a written justification — which they rarely do.

Apple's guideline 2.5.2 prohibits apps from downloading executable code after approval. Using OTA updates (Expo Updates, CodePush) combined with remote feature flags to silently enable entirely new functionality — gambling, payments, adult content, cryptocurrency — after passing review is treated as deception and results in account termination, not just app rejection. The line Apple draws is between bug fixes and UI changes (permitted) and new features that would require re-review (prohibited). The combination of OTA + remote config is the mechanism most commonly exploited to bypass review — reviewers know what to look for.

Why this severity: Info because most OTA implementations are legitimate; the risk is narrow but the consequence (account termination) is severe enough to warrant inspection.

Apple's guideline 4.2 requires apps to offer functionality beyond what a mobile web browser can provide. A root `<WebView>` loading your website URL — or a tab navigator where every tab is a WebView — provides exactly zero native value and is rejected routinely. Google Play applies the same standard. Beyond rejection: a WebView wrapper offers worse performance than Safari/Chrome, no access to native APIs, broken back-button behavior on Android, and user interfaces that feel foreign on mobile. The rejection is not a technicality — the platforms genuinely won't distribute apps that are just website containers.

Why this severity: High because Apple guideline 4.2 minimum-functionality rejections are applied consistently — any app whose primary content is a WebView loading a URL will be rejected.

Apple's guideline 2.5.4 requires that background modes declared in `UIBackgroundModes` actually be used by the app. An app that declares `location` and `fetch` background modes but contains no corresponding background location or fetch code raises an immediate red flag — reviewers check Info.plist against the source code. Beyond rejection risk, unused background modes claim battery budget Apple allocates to those modes, harming device performance. Overly frequent background tasks (running every 15 minutes for work that could run daily) trigger Apple's background task termination policies and degrade the user's battery life.

Why this severity: Medium because declaring unused background modes triggers rejection under guideline 2.5.4 and Apple's reviewers specifically cross-reference UIBackgroundModes against app functionality.

An embedded `WebView` used for OAuth credential entry violates Apple's guideline 5.1.1 and the OAuth 2.0 security model: the app can read the WebView's DOM content, giving it access to the user's credentials on the OAuth provider's login page. CWE-522 (insufficiently protected credentials) applies directly. Google, Apple, and GitHub explicitly prohibit embedded WebView OAuth because it enables phishing — an app can silently capture the username and password typed into what appears to be Google's login form. The correct implementations (`SFSafariViewController`, `AuthenticationSession`, Chrome Custom Tabs) operate in a separate process the app cannot read.

Why this severity: Low because the pattern requires an OAuth flow to be present and is not an immediate binary rejection in all cases, but Apple has started rejecting it more consistently under guideline 5.1.1.

Apple's guideline 2.5.2 prohibits downloading and executing code after approval. Remote configuration that can enable gambling mechanics, cryptocurrency payments, adult content, or affiliate link injection after a binary passes review is treated as deliberate deception — the consequence is not just rejection but developer account termination, which affects every app in the account. The pattern is detectable: reviewers who see LaunchDarkly or Statsig in a binary will check what flags control and whether any could enable policy-violating behavior. Dynamic code construction from remote strings — eval-equivalent patterns — is a hard rejection regardless of what the code does.

Why this severity: High because enabling policy-violating features via remote config post-approval is treated by Apple as deception, with account termination (not just app removal) as the consequence.

Apple's guideline 1.1.7 and Google Play Developer Policy both explicitly prohibit incentivized reviews and review gating. Offering in-app currency for a review (`if (userLeftReview) grantCoins(50)`) is a direct policy violation detectable in source code. Review gating — asking "Do you like our app?" and only showing the store prompt if the answer is "Yes" — is equally prohibited because it systematically filters out negative reviewers. Both practices result in App Store rating manipulation, which Apple takes seriously. Reviewers actively look for both patterns, and discovery results in immediate rejection plus potential listing removal.

Why this severity: High because both incentivized reviews and review gating are explicitly prohibited by Apple guideline 1.1.7 and can result in rejection plus listing consequences.

A rating prompt shown on first launch — before the user has used the app — or during a high-stakes task like checkout produces dismissals and one-star reviews from irritated users. Apple's guideline 1.1.7 discourages disruptive or poorly-timed prompts, and a pattern of low ratings from premature prompts signals the platform that your app has quality issues. More practically: users who dismiss an early prompt are less likely to rate the app later. A timer-based prompt (`setTimeout(requestReview, 30000)` from app start) is a common form of this failure that appears in code review as a clear sign of a copy-paste implementation.

Why this severity: Low because poor timing causes rating quality degradation rather than direct rejection, though repeated user complaints about intrusive prompts can attract guideline scrutiny.

Apple's guideline 5.1.1 states that apps may not require users to register or log in before using features that don't require identity. An app that redirects everyone to a login screen on first launch gives the reviewer no way to evaluate the core functionality — which itself can cause rejection. Beyond compliance, requiring signup before showing any value is the single highest-conversion-killing pattern in mobile onboarding: users uninstall rather than create accounts for apps they haven't seen yet. A meaningful guest mode isn't optional polish — it's required by policy and critical for growth.

Why this severity: Low because reviewers may grant an exception for apps where all features are genuinely identity-bound, but unwarranted auth gates are a documented rejection trigger under guideline 5.1.1.

Requesting notification permission before showing the user any app content is one of the top patterns Apple's guideline 5.1.1 calls out — and one of the highest rates of user denial. Users who see a permission request before understanding the app's value default to "Don't Allow," permanently locking the app out of push on that device. An app that blocks core functionality when notification permission is denied compounds the problem. The correct model — a pre-permission screen explaining specific notification value, followed by a contextual request when the user first enables a notification-powered feature — produces higher grant rates and cleaner review outcomes.

Why this severity: Info because Apple doesn't automatically reject premature notification requests, but the pattern degrades grant rates and can attract guideline scrutiny if combined with other permission issues.

Brand-new Apple Developer and Google Play accounts receive 100% manual review on their first submission and are subject to tighter scrutiny on guideline adherence, metadata claims, and demo-account completeness. Rejections are common on first submission even for clean apps — reviewers probe harder for Guideline 5.1.1 (privacy) and 4.0 (design) issues. Knowing the account is new lets the submitter pre-empt common new-developer failure modes and avoid a 1–2 week delay.

Why this severity: Info because it is a risk signal, not a violation, and cannot block submission on its own.

Apple's guideline 4.3 (spam) targets apps that are "simply a generic interface without any realistic functionality" — which includes template-generated apps with the default Expo blue-circle icon, placeholder names like "MyApp" or "React Native App," and screens with no purposeful content beyond boilerplate. Apps that look like templates attract heightened review scrutiny on all other guidelines. The ISO 25010:2011 functional-completeness classification applies: an app that hasn't been customized beyond a starter template provides no functional value beyond what the template itself provides.

Why this severity: Info because this is a risk-indicator rather than a hard failure — template appearance attracts scrutiny but is not a standalone rejection cause by itself.