WebView App Rejected Under Guideline 2.1: Fix Blank Screens

Q: Which Info.plist keys does a WebView app with file uploads need?

At least NSCameraUsageDescription if the file chooser offers the camera, and NSMicrophoneUsageDescription if users can record video with sound. Add the photo library keys if your app reads from or saves to the library itself. Each needs a specific explanation of why the app uses the resource; vague texts invite privacy questions under Guideline 5.1.1.

Q: Why don't target="_blank" links work in my WKWebView app?

WebKit hands new-window requests to your WKUIDelegate, and if webView(_:createWebViewWith:for:windowFeatures:) isn't implemented, the navigation is cancelled. Implement it and load the URL in the same view, an in-app browser or Safari. JavaScript confirm() has a similar trap: without the matching delegate method it behaves as if the user tapped Cancel.

Key takeaways

For App Review, your website is part of the app: a slow server, a staging URL or a dead link on the site makes the app incomplete.
WKWebView silently drops target="_blank" links, window.open calls and JavaScript confirm dialogs unless your native code handles them.
Blank screens usually come from slow first loads, single-page apps that fail to start, HTTP URLs blocked by App Transport Security or a terminated web content process.
WebViewGold, made by our team, covers offline fallback, splash and loading states, downloads, uploads and link handling – the website itself still has to be complete.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 2.1 - Performance - App Completeness

The app exhibited one or more bugs that would negatively impact users.

Bug description: After launch, the app displayed a blank white screen and no content loaded.

Review device details:
- Device type: iPad
- OS version: iPadOS [version]

Next Steps: Test the app on supported devices to identify and resolve bugs before resubmitting.

Paraphrased example – the exact wording in your message may differ.

What "complete" means when a WebView app is rejected under Guideline 2.1

If your WebView app was rejected under Guideline 2.1, the reviewer hit something broken or unfinished – and in a wrapper app, most of those problems live on the website rather than in the binary. A blank start screen, a dead link, a button that does nothing or a login nobody can pass all make the app incomplete. The guideline is explicit about the web side:

Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission.

"Empty websites" is no accident: Apple treats your web content as part of the submission. The same paragraph ends with "We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." And this is no niche issue – Apple's App Review page says that on average over 40% of unresolved issues relate to Guideline 2.1.

Crash logs, symbolication, IPv6 testing and in-app purchase problems are covered in our Guideline 2.1 App Completeness guide. This article focuses on the failure modes specific to apps built around WKWebView.

What App Review's setup means for a WebView app

Apple doesn't publish a test protocol, and guesses about review devices and networks are everywhere. These points are documented – plus one safe assumption:

The review device is named. 2.1 messages list review device details such as device type and OS version, and the device can be an iPad even if you designed for iPhone. Apple's App Review page asks you to test on devices running the latest software. For iPad layouts, see Guideline 2.4.1 for WebView apps.
The network allows IPv6-only connections. Guideline 2.5.5 requires apps to work on IPv6-only networks, and Apple's networking documentation notes that the network used during App Review allows direct IPv6-to-IPv6 connections. A server that publishes an IPv6 address without really serving over IPv6 can fail in review while working in your office.
The reviewer only knows what you tell them. Demo accounts, test steps and special configurations belong in App Review Information; without them, everything behind a login stays untested.
Assume a clean install. A fresh install carries none of your cookies, cached pages or saved logins, so everything the website needs must load the first time.

Apple doesn't document where reviewers are located either. Don't rely on IP allowlists, and check geo-blocking, bot protection and rate limits on your site.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Blank screens, dead links, dead buttons: the WebView failure map

What the reviewer reports	Typical WebView cause	Fix
Blank white screen after launch	A slow first response, a single-page app whose JavaScript fails on the review device's iOS version, a redirect chain, or an `http://` URL blocked by App Transport Security	Native splash or loader until the first page finishes, a timeout with a native error screen, HTTPS everywhere
Blank screen after switching back to the app	iOS terminated the web content process in the background	Reload in `webViewWebContentProcessDidTerminate(_:)`
An error page from your host or CDN	Server down, expired certificate, a preview or builder subdomain	Production domain, monitoring during review, native error screen for HTTP errors
A link does nothing	`target="_blank"` or `window.open` without a `WKUIDelegate` handler – WebKit cancels the navigation	Handle new-window requests natively
"Delete" or "Confirm" does nothing	Without the delegate method, `confirm()` behaves as if the user tapped Cancel, and `alert()` messages never appear	Implement the JavaScript panel methods with native alerts
The app crashes on upload	The camera was chosen in a file input without `NSCameraUsageDescription`; inputs that accept video also access the microphone, which needs `NSMicrophoneUsageDescription`	Add specific purpose strings
A download does nothing	A file type `WKWebView` can't display	Handle downloads natively with `WKDownload` (iOS 14.5 and later)
Sign-in fails or loops	Google's OAuth policies don't allow sign-in requests from embedded web views; third-party cookies can be blocked, because Intelligent Tracking Prevention has been on by default in `WKWebView` apps since iOS 14	Sign in via `ASWebAuthenticationSession` or the native Google Sign-In SDK; keep your own login on your own domain
A page says "please use a desktop browser"	Hover menus, drag-and-drop-only uploads, wide admin tables	A touch-friendly version of every feature in the app
Test or dummy content	Sample products, filler text, "coming soon" sections, staging banners	Remove it before you submit

Social sign-in has its own guideline as well – see Guideline 4.8 for WebView apps.

Build a native safety net around the web content

Most rows in the table come down to one principle: the native shell must handle every situation the website can't. In a custom WKWebView implementation, that means:

Track loading. Observe isLoading and estimatedProgress and show a native indicator. If the first page hasn't finished after a reasonable time, switch to a native error screen with a retry button instead of leaving the reviewer staring at white.
Catch failed loads. Implement webView(_:didFailProvisionalNavigation:withError:) and webView(_:didFail:withError:) in your WKNavigationDelegate. Connection errors get the offline screen, everything else a friendly message and a retry.
Check HTTP status codes. When deciding the policy for a navigation response, treat a 404 or 5xx on the main frame as an error and show your native screen rather than the server's raw page.
Recover from terminations. When the web content process ends, WebKit calls webViewWebContentProcessDidTerminate(_:); reload the last URL there.
Handle new windows and dialogs. In your WKUIDelegate, implement webView(_:createWebViewWith:for:windowFeatures:) for new-window requests, plus the alert, confirm and prompt panel methods.
Handle downloads. When canShowMIMEType is false or the server sends an attachment, answer with the .download policy, save the file through a WKDownloadDelegate and offer the share sheet.
Keep App Transport Security strict. Serve every page and asset over HTTPS. Apple's documentation says you must supply a justification during App Store review if you set NSAllowsArbitraryLoadsInWebContent to YES.
Add every purpose string the web content can trigger – camera, microphone, location – plus the photo library keys if the app saves images or reads the library natively. Apple warns that without the right key, access fails and might crash the app.

What WebViewGold already handles for Guideline 2.1

If you'd rather not build that safety net yourself, WebViewGold – the website-to-app solution made by our own team – ships most of it as configuration in Config.swift:

Completeness risk	WebViewGold setting or module	What remains your job
White screen at launch	A splash screen that can stay until the homepage has loaded, followed by a native loading sign	A fast first page
No connection	Offline fallback with a bundled local page, a reconnect button and optional automatic retries	Useful content on the offline page
Dead `target="_blank"` and external links	URL handling: open in the app, in an in-app browser tab or in Safari, with per-domain lists	Decide where each kind of link should go
Uploads	File chooser with camera and photo library, plus an optional VisionKit "Scan Document" entry	Specific purpose strings; delete the ones you don't use
Downloads	File downloader for configurable file types and `Content-Disposition` attachments	Correct headers on your server
Google or Facebook sign-in	An authentication sheet (`ASWebAuthenticationSession`) or the native Google Sign-In SDK instead of the WebView, plus Sign in with Apple	A password-based demo account for review
HTTP content	Permitted by default; the docs explain how to restrict traffic to HTTPS	Serve everything over HTTPS and tighten the setting

No tool can promise an approval, and none can repair a website that is slow, unfinished or full of test data. WebViewGold makes the native side fail gracefully; the completeness of your web content stays your responsibility. You own the Xcode project and publish in your own account; without a Mac you can build through the separately sold Cloud Builder, and appsubmitter.io can take over signing and submission.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

Scrub the website before you submit

Because the reviewer tests your live site, your pre-submission check has to cover the web side too:

Production URL. The start URL points to your production domain – not a staging server, a preview deployment or a builder subdomain that may sleep or change.
No barriers on the first load. No basic-auth prompt, maintenance page, region block or bot challenge. A protection service that shows a "checking your browser" interstitial can stop a reviewer before your app even appears.
Nothing unfinished. Remove filler text, sample products, "coming soon" menu entries, beta labels and test banners.
Every link resolves. Footer links, help pages, privacy policy and support page – Apple's App Review page states that all links in an app must be functional.
Every feature works on a phone. Hover-only menus, drag-and-drop uploads and wide tables need touch-friendly alternatives, and no page should send users to a desktop.
Stability during review. Avoid deployments, migrations and certificate changes while the build is in review. A broken deploy is a broken app.

When the message says "2.1 – Information Needed"

Not every 2.1 message reports a bug. "Information Needed" means the reviewer stopped because something was missing – most often a working login. For WebView apps the login traps are specific:

Magic links and one-time codes sent by email or SMS, which the reviewer can't receive. Give the review account a password login.
Sessions that only work in a browser, for example because the identity provider runs in a third-party iframe or relies on third-party cookies. Test the review account inside the app.
Accounts without data. An empty dashboard looks unfinished; fill the review account with realistic sample content.
Features that need hardware or a place – a QR code at a venue, an NFC tag, a delivery area. Provide a sample code or a demo video recorded on a physical device.

Enter the credentials under App Review Information with Sign-in required checked; the demo account must not expire. Our 2.1 Information Needed guide covers 2FA workarounds, region locks and recording requirements in depth.

Replying and resubmitting after a 2.1 rejection

Cause	New build?	What to send
Website only – outage, broken page, test content	Usually not	Fix the site, reply with what happened and how you verified the fix, then resubmit the same build
Native handling – start URL, dead links, missing dialogs, purpose strings, downloads, error states	Yes	Upload a new build, describe the fix in the Notes for Review and reply with test steps
You can't reproduce it	Not yet	Reply with the devices, OS versions and networks you tested, and ask for exact steps or a screen recording

Name concrete test conditions instead of "works for us": device, OS version, build number, fresh install, network. If the conversation stalls, a 30-minute App Review appointment can help; an appeal only makes sense when the app was demonstrably complete.

appsubmitter.io runs AI-powered pre-submission checks with an App Specialist on top – the website side included – and handles the communication with App Review in your own developer account. Book the iOS service or get a second opinion in a free consultation call.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y]) and for describing the issue on [device type] with [OS version].

We reproduced the problem on the same device type with a fresh install. The cause was [e.g. our start page loaded too slowly on first launch and the app showed no loading state / links that open a new window were not handled by the app / a server outage during your review].

What we changed:
- [Website fix, e.g. faster first page, removed test content, fixed broken links]
- [Native fix in build [build number], e.g. native loading and error screens with retry, handling of new-window links and confirmation dialogs, camera purpose string]
- [Verification: fresh install on iPhone and iPad, iOS [version], Wi-Fi and cellular, IPv6-only test network]

To verify:
1. [Step 1]
2. [Step 2]
3. [Expected result]

The demo account in App Review Information is active and contains sample data. If anything still doesn't work as expected, we would appreciate the exact steps so we can investigate immediately.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

The start URL points to the production domain over HTTPS, with no staging, preview or password-protected hosts.
A fresh install of the exact build loads the first page on iPhone and iPad without a blank screen.
The app shows native loading, error and offline states with a retry option.
The web view reloads after its content process was terminated in the background.
target="_blank" links, window.open calls and JavaScript alert and confirm dialogs work in the app.
File uploads work with camera and photo library, and every purpose string the web content can trigger is set.
Downloads of PDFs and other files are handled or opened in a viewer.
Sign-in works inside the app, without magic links, SMS codes or blocked third-party cookies.
No filler text, sample products, coming soon pages, beta labels or test banners remain on the website.
Every link, including support and privacy policy, opens a live page, and no feature requires a desktop browser.
A demo account with sample data is saved under App Review Information and does not expire.

Frequently asked questions

Why was my WebView app rejected under Guideline 2.1?

Because the reviewer hit something broken or unfinished – and in a WebView app that is often on the website: a blank screen while the first page loads, a host error page, a link or button that does nothing, a crashing upload or test content. Find the cause, fix it on the web or in the native shell and resubmit with precise test steps.

Why does my app show a white screen in review but not on my iPhone?

Your phone usually has cached pages, cookies and a saved login; a fresh install has none. Other differences are the device, possibly an iPad, the iOS version and the network, which supports IPv6-only connections. Test a fresh install of the exact build on several devices and OS versions, and make sure your server answers over IPv6 if it advertises it.

Do I need a new build if the problem was on my website?

Usually not. If the cause was purely on the web side – an outage, a broken page, test content – fix the site, explain what happened in your reply and resubmit the same build. If the fix needed native changes, such as new-window handling, purpose strings, a different start URL or a native error screen, upload a new build with a higher build number.

Which Info.plist keys does a WebView app with file uploads need?

At least NSCameraUsageDescription if the file chooser offers the camera, and NSMicrophoneUsageDescription if users can record video with sound. Add the photo library keys if your app reads from or saves to the library itself. Each needs a specific explanation of why the app uses the resource; vague texts invite privacy questions under Guideline 5.1.1.

Why don't target="_blank" links work in my WKWebView app?

WebKit hands new-window requests to your WKUIDelegate, and if webView(_:createWebViewWith:for:windowFeatures:) isn't implemented, the navigation is cancelled. Implement it and load the URL in the same view, an in-app browser or Safari. JavaScript confirm() has a similar trap: without the matching delegate method it behaves as if the user tapped Cancel.

Can WebViewGold prevent 2.1 rejections?

It removes the native weak spots: WebViewGold, built by our team, comes with an offline fallback, splash and loading states, link handling, uploads and a file downloader. It can't make an unfinished or unreliable website complete, and no tool can promise an approval – so test your web content as carefully as the app itself.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

WebView App Rejected Under Guideline 2.1: Blank Screens, Dead Links and Login Walls Fixed