WebView App Rejected Under Guideline 5.1.1: Privacy Fixes for Website-Based Apps

Why was my WebView app rejected under Guideline 5.1.1?

Your WebView app was rejected under Guideline 5.1.1 because App Review found a problem with how the app asks for, collects or explains personal data. In a website-based app, that problem usually sits in your web content, not in Swift code: a camera or location prompt with a vague text, a privacy link the reviewer couldn't find, or a sign-up wall on the start page.

Guideline 5.1.1 has ten sub-clauses, and two of them matter most for WebView apps. The privacy policy rule, 5.1.1(i):

All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.

And the last sentence of the permission rule, 5.1.1(ii):

Ensure your purpose strings clearly and completely describe your use of the data.

For a wrapper, this means iOS treats your website like any other part of the app: a page that calls the camera triggers the system alert with your Info.plist text, and App Review judges text, timing and data use as it would for native code. Apple rejected over 443,000 submissions for privacy violations in 2025 (Apple Newsroom). Our complete Guideline 5.1.1 guide covers every sub-clause; this article covers what changes when a website runs inside your app.

Which website features trigger iOS permission prompts?

Browser APIs that reach protected hardware end up at a native iOS check when they run in WKWebView. Each needs a key in your app's Info.plist, and each fails in its own way.

One detail saves you a permission: WebKit's upload menu offers Photo Library, a camera option and Choose File, and its Photo Library option opens the system's out-of-process picker – no library access needed. That matches 5.1.1(iii): "use the out-of-process picker or a share sheet rather than requesting full access".

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 →

Purpose strings that describe the web feature, not the app shell

Reviewers read your purpose string while looking at your web page. Name the feature as your interface does, say why the resource is needed and give an example:

• Coaching or telehealth platform. Camera: "Your camera shows you to your coach in video sessions you start from the Sessions tab." Microphone: "Your microphone lets your coach hear you during video sessions."
• Restaurant or retail chain. Location: "Your location is used to list the nearest branches and their opening hours when you tap Find a branch."
• Marketplace. Camera: "The camera lets you photograph an item and add the pictures to your listing."

Only write what is true, and watch for three wrapper-specific traps:

• Inherited keys. Starter projects and plugins can declare keys for features your site never uses. Remove each such key together with the module behind it; if code still references the API, App Store Connect flags the upload with ITMS-90683.
• Language mismatch. Localize the strings like the site – a Spanish page with an English alert looks unfinished.
• Third-party embeds. A video-call widget or an identity check in an iframe uses the same camera your pages do. Your string has to cover it, and your policy has to name the provider.

Ask when the feature is used – and plan for "Don't Allow"

Timing is where web code and iOS disagree most: a getUserMedia() call on page load shows the system alert before the user knows why. Guideline 5.1.1(iv) says apps must not "manipulate, trick, or force people to consent to unnecessary data access" and adds: "Where possible, provide alternative solutions for users who don’t grant consent."

1. Tie every request to a tap – the camera to "Start video session", location to "Use my location", never to page load.
2. Handle a refusal in JavaScript. getUserMedia() rejects with a NotAllowedError; the geolocation error callback reports PERMISSION_DENIED. Show a postcode field, an upload from files or a phone number instead of an empty screen.
3. Avoid the double prompt. Since iOS 15, the WKUIDelegate method webView(_:requestMediaCapturePermissionFor:initiatedByFrame:type:decisionHandler:) decides whether WebKit adds its own per-site question to the iOS alert. If you don't implement it, the system returns .prompt, so users can see two dialogs. Grant your own origin there – never third-party frames blindly.
4. Treat push the same way: ask after a booking or order, not on the first screen.

Privacy policy and App Privacy details: your website counts too

Keep the policy one tap away in app mode

Most WebView apps hide the website's footer for a native look – and the privacy link usually lives there. Give the policy a place the app shows, such as a Privacy entry in your menu or settings page. Enter the same URL in App Store Connect under App Privacy and make sure it opens without a login.

Check the content, too. 5.1.1(i) requires the policy to identify what is collected and how, to confirm that third parties such as "analytics tools, advertising networks and third-party SDKs" protect the data equally, and to explain retention, deletion and revoking consent. If one policy covers website and app, say so.

Declare what your web scripts collect

Apple's App Privacy documentation is explicit: "Data collected via web traffic must be declared, unless you are enabling the user to navigate the open web." Analytics tags, live chat, newsletter forms and payment iframes all count. List every third-party request your pages make in app mode, map it to Apple's data types and purposes, and update the answers whenever your site changes – no app update needed.

If one of those scripts is an ad pixel that links your users with other companies' data, the question moves to Guideline 5.1.2 – see tracking scripts in WebView apps.

Login walls, sign-up forms and data minimization

The first sentence of 5.1.1(v) is short and strict:

If your app doesn’t include significant account-based features, let people use it without a login.

Web apps break this rule by accident: many dashboards and AI-built apps send every signed-out visitor to /login, which turns the start URL into a login wall. If you have public content – a catalog, articles, a branch finder – start there and ask for an account when someone saves, books or buys. If the app is genuinely account-based, explain that in the review notes and provide a working demo account; our article on completeness issues in WebView apps covers reviewer access.

Sign-up forms deserve a second look. 5.1.1(v) states: "Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law." Mandatory phone, birthday or address fields "for later" fail that test – make them optional or drop them.

Accounts bring one more duty: if people can create one in your app, including on your website inside the web view, you need in-app account deletion. That half of 5.1.1(v) has its own playbook: account deletion for WebView apps.

Where WebViewGold takes care of the native side

WebViewGold is the website-to-app product built by our own team. It turns your site into a native Xcode project in Swift with the native parts of 5.1.1 already wired up:

• Hardware for web features. Camera and microphone for WebRTC and media capture, HTML5 geolocation and camera uploads from web forms work in the app. The Info.plist is in your own project, so you write the strings.
• Permission timing from your web code. Skip the push prompt at first launch (askforpushpermissionatfirstrun) and request it later with a registerpush:// link; send people who declined a permission to your app's Settings page with settingsapp://.
• App detection. A custom user agent lets your site show an app-only menu with the privacy link.
• Tracking. App Tracking Transparency support for sites that do track.

WebViewGold is a one-time purchase; you own the project and publish in your own developer account, or build in the browser with the separately sold Cloud Builder. No tool can promise an approval – your strings, policy and App Privacy answers remain your responsibility. Many teams split the work: WebViewGold for the native shell, appsubmitter.io for signing, the App Privacy form and the submission.

What needs a new build – and how to answer App Review

Use Reply to App Review in App Store Connect: quote new purpose strings word for word, list the taps that show each prompt and attach a screen recording including the "Don't Allow" path. If the reviewer misread your app, explain that first. You can still appeal to the App Review Board (one appeal per rejected submission) or request a 30-minute App Review appointment through Meet with Apple.

Prefer to hand it off? The App Specialists at appsubmitter.io compare your prompts, policy and App Privacy answers with what your site actually loads, prepare the reply and resubmit in your developer account. Start with a free consultation call or book the iOS service; code changes aren't included and are quoted upfront if needed.

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], build [build number]). We have addressed the Guideline 5.1.1 issues in the app and in the web content it displays:

1. Purpose strings: NSCameraUsageDescription now reads "[new text]". NSMicrophoneUsageDescription now reads "[new text]". [We removed NSContactsUsageDescription, which no feature used.]
2. Timing: Camera and microphone access is requested only when the user taps [Start video session]. If access is declined, the user can [book a phone appointment instead].
3. Privacy policy: Available without login at [URL] and linked in the app under [Menu > Privacy].
4. Account: [Browsing the catalog] works without an account. An account is only needed for [account-based features].
5. App Privacy: Our App Privacy details now include the data collected by [analytics / chat] services on our website.

To verify: [steps]. A screen recording of the permission flow, including "Don't Allow", is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Each purpose string names the web feature that uses the resource and gives an example.
• Camera, microphone and location requests run only after a tap on the related feature.
• Declining a permission leaves a working alternative in your web app.
• The upload field works with Photo Library, the camera option and Choose File on a device.
• No Info.plist key remains for a feature your app doesn't offer.
• The privacy link is visible in the app without signing in, even with the web footer hidden.
• Your App Privacy details include what your web scripts collect.
• The start URL shows content without a login unless the app is account-based.
• If you use WebViewGold, push permission is requested at a meaningful moment, not at first launch.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.1.1 Data Collection and Storage
• Apple – App privacy details on the App Store
• Apple Developer Documentation – NSCameraUsageDescription
• Apple Developer Documentation – Requesting authorization to capture and save media
• Apple Developer Documentation – WKUIDelegate media capture permission
• WebKit source – file upload panel on iOS (photo picker and camera options)
• App Store Connect Help – Manage app privacy
• Apple Newsroom – App Store fraud prevention in 2025 (May 20, 2026)

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.