Your App Is Not Loading During Testing: Expert Diagnosis

When Meta App Review returns Your app is not loading during testing — for Web, Android, or iOS — the review never reached your use case. Reviewers could not open the binary or URL you submitted, so permission proof never got a fair test. This article covers Meta’s Rejection Guide for all three platform variants, why geo-blocking and firewall rules that block Meta reviewer US/EU IPs kill submissions, how this differs from test credentials do not work, unable to verify permissions, Unable to Verify Use Case, and Inadequate Demonstration, and why flipping a CDN toggle without diagnosis often burns a 7-day cooldown.

This Meta App Review diagnosis starts with a cold external load test. Treat every Meta App Review loading failure as a reachability problem first, then document the fix before resubmitting.

What this rejection actually means

Meta’s App Review Rejection Guide splits the same failure into three platform-specific labels. The shared outcome is identical: the reviewer never entered a loadable product surface.

Web: Reviewers use the app URL in App Verification Details; if that field is empty, they fall back to the Website URL under App Dashboard → Settings → Basic. If neither URL loads, the submission fails.

Android: Reviewers download the submitted APK and attempt to install and log in. If the APK will not load, the label is “Your app is not loading during testing (Android)”.

iOS: Reviewers download the Simulator Build and attempt to launch it. If they cannot load the app from that build, the submission fails.

From Meta’s side this is not a soft preference. An inaccessible app is an incomplete verification — the same family as accessibility failures in Meta’s App Review FAQ.

Meta App Review psychology: no load, no review

Every Meta App Review diagnostic should start with evidence, not a blind infrastructure change; a careful Meta App Review audit protects the review window; this Meta App Review checklist keeps evidence reviewable.

App Review is not a white-glove VPN onboarding call. Reviewers will not join your corporate Zero Trust portal, accept a regional CAPTCHA loop, or wait for an allowlist ticket. Timeout, SSL interstitial, geo block page, expired APK link, or Simulator Build that will not open ends the submission.

That is why a use case can “work in HQ” and still fail on loading — testing never starts. Ambiguity defaults to rejection. Pasting “VPN details on request” into notes is fragile; Meta expects external reachability you verified yourself.

Technical nuances: geo-blocks, firewalls, and platform artifacts

Across hundreds of Meta apps, the same loading failure modes appear under this label:

• Geo-blocking / WAF rules blocking US and EU reviewer IPs — Cloudflare “Under Attack,” country deny lists, or regional firewall policies that serve a challenge page to Meta’s review locations. The app “works at home” and fails in review.
• Internal-only staging — localhost, private VPC, VPN-gated hostname, or IP allowlists that exclude Meta. The Rejection Guide repeatedly stresses verifying access externally.
• Wrong or missing Web URL — Verification Details empty and Basic Settings Website pointing at a marketing site, 404, or expired staging URL.
• Android APK not installable — corrupted upload, Play-internal share link that expires, minSdk below Android 6.0 (Marshmallow), or a link that requires Google account auth reviewers do not have.
• iOS Simulator Build format failures — not a .ipa / zipped .ipa / .app compatible with Xcode 8.0+, device-only build instead of Simulator Build, or a link that cannot be fetched externally.
• TLS / certificate friction — expired certs, hostname mismatches, or corporate MITM proxies that only work on company devices.

Official remediation (platform-aware): finish development; verify external access with a Test User; put the correct Web URL or mobile artifact in App Verification Details; include non-Facebook test credentials when your product login is required; resubmit once.

Meta App Review policy grounding: trustworthy access before permission proof

Under Meta Developer Policies section 1. Build a trustworthy product, developers must follow Developer Docs instructions, including Platform allowed usage. Loading failures sit upstream: reviewers cannot evaluate trustworthy Platform use if they cannot open the app.

Meta’s submission guidance is blunt: if reviewers cannot access your app for any reason, the entire submission is rejected. Accessibility is a prerequisite. Geo-blocks and firewalls that drop US/EU traffic are review-path defects — not “security features” Meta will work around.

Official references worth reading before you flip another CDN rule:

• Meta App Review Rejection Guide — Web / Android / iOS “not loading during testing”
• Meta Developer Policies — Build a trustworthy product

Expert Diagnosis framework (not a DIY paste template)

Every app’s delivery stack is unique: public web SPA, enterprise APK behind MDM, or both Web and mobile artifacts. A full copy-paste “open this URL” block would mislead your team or leak infrastructure. Specialists diagnose first:

If the app loads but login fails, see test credentials do not work. If login works but permissions fail, see unable to verify permissions. Managed help: Facebook App Review service and case studies.

What not to do after this rejection

• Do not resubmit the same VPN-only staging hostname and hope reviewers somehow join your network.
• Do not leave country deny lists or “Under Attack” modes on the review URL while you “fix login later.”
• Do not upload a device-only iOS build when Meta asks for a Simulator Build, or an APK that requires a private Play track login.
• Do not assume a working screencast substitutes for a loadable live URL or installable binary in App Verification Details.

Make the surface loadable outside your firewall. Verify it from a cold US/EU path. Document the artifact. Then submit once. Anything else gambles with cooldown risk.