You uploaded the build, the metadata in App Store Connect is filled in with a working https URL, and the Resolution Center reply still names Guideline 5.1.1 with a line about the privacy policy not being linked. The link Apple is checking does not live in the listing; it lives inside the running app, on a screen a reviewer can reach in one or two taps from the home view.
Short answer
The short answer is that Guideline 5.1.1(i) treats the privacy policy URL as a two-location requirement, not one. The App Store Connect metadata field covers the listing on the store page. A clickable in-app link covers the requirement that, in Apple's own wording, the privacy policy is reachable "within the app in an easily accessible manner," per the App Review Guidelines. When the in-app link is missing, hidden behind a registration wall, or points to an unreachable URL, the review fails even when the listing field is correct.
What you should know
- 5.1.1(i) names two places, not one. The metadata field handles the store listing; the in-app link handles the runtime. A clean metadata field on its own does not satisfy the requirement.
- Reviewers test the link by tapping it. A placeholder string, a 404, a dead
about:blank, or a popup that closes itself before loading content reads as missing during review. - Accessible means reachable without an account. A privacy policy buried behind a login or a paid subscription gate is treated as inaccessible because the reviewer cannot reach it from a fresh install.
- Settings is the default home for the link. A labeled row in Settings, About, or Legal is the placement most often accepted on the first pass.
- Subscription apps need it on the paywall. When the app sells auto-renewable subscriptions, the paywall is the placement most often verified during review, separate from the Settings row.
- Localization is allowed and sometimes required. The privacy policy URL field can be localized in App Store Connect for every language the app supports, per Apple's official help page.
Where exactly does Apple expect the in-app privacy policy link?
The short answer is anywhere a reviewer with no account can reach within one or two taps from the first screen. Apple does not name a single screen in the guidelines. The phrasing is "within the app in an easily accessible manner," which leaves the screen choice to the developer and the verification to the reviewer.
In practice, the screens that pass review without follow-up share three properties. The link is labeled clearly, usually as "Privacy Policy" rather than a generic word like "Legal." The link sits behind a navigation path that does not require account creation. The destination loads a live HTML page that matches the document submitted in App Store Connect.
The placements that fail review tend to break one of those three. A link behind a sign-up wall fails the accessibility check. A link with the label "More" or "Info" without "Privacy Policy" written explicitly can fail because the reviewer cannot find it during the time budget allotted to the build. A link to a Notion page or a Google Doc that requires a sign-in to view fails because the destination is not a public webpage.
What does the Resolution Center message usually say?
The pattern of the message is identifiable. The header names Guideline 5.1.1, Legal, Privacy, Data Collection and Storage. The body cites a missing or non-functional privacy policy link, and asks the developer to add one in the next build. The message does not name which screen the reviewer expected the link on, which is the friction point. The fix is not to argue the placement; the fix is to add the link to a screen the reviewer can reach without creating an account.
A second pattern, less common, names the URL in the listing field as broken or pointing to a domain that does not resolve. This is the listing-side failure and is fixed by updating the URL in App Store Connect, per the App Store Connect privacy help. A change to the URL ships with the next app version submission, not as an immediate update to the live listing.
How do I confirm the link is clickable the way Apple defines it?
The honest answer is to run the link through three checks before resubmitting.
First, the label test. A reviewer scanning a settings screen for "Privacy Policy" should see those exact two words within one or two screens of the first launch. Generic labels like "More," "Info," "Legal stuff," or icons without text fail this test on screens where the reviewer is in a hurry.
Second, the no-account test. Open the app from a fresh install on a clean device or simulator. Without creating an account, signing in, or completing onboarding, walk to the screen with the link. If the path requires authentication, the link does not satisfy the accessibility requirement.
Third, the live-URL test. Tap the link. The destination should open in either an in-app SFSafariViewController or the system browser, and the page should render real privacy policy content within two seconds. A Notion or Google Doc that prompts for sign-in, a Substack post requiring a subscription, a Webflow page set to "Coming soon," or a localhost reference left in the build all fail. A URL pointing to a generic privacy generator template that has not been customized for the app also fails because the policy content does not match what the App Privacy questionnaire declares.
| Placement | Strength | Typical risk |
|---|---|---|
| Settings or About screen | Always reachable, no account needed | Risk when label is "More" or "Info" instead of "Privacy Policy" |
| Onboarding screen footer | Visible on first launch | Risk when the link is below a Continue button users can dismiss before reading |
| Login or signup screen | Reachable before account creation | Risk when the link is grey-on-grey and small enough to miss |
| Subscription paywall | Required for auto-renew apps | Risk when EULA link is present but privacy policy is missing |
| In-app web modal only | Direct in-app render | Risk when no system browser fallback is offered for offline cases |
What goes on the paywall when the app sells subscriptions?
The short answer is that auto-renewable subscription apps carry an additional verification on the paywall itself. Apple's User Privacy and Data Use page reinforces the wider 5.1.1 rule, and Apple's subscription guidance asks for functional links to both the End User License Agreement and the privacy policy accessible from inside the app. The paywall is the screen most often verified during review because the purchase decision happens there.
In practice, the paywall layout that clears review on the first pass shows a small footer with two tappable strings: "Terms of Use (EULA)" and "Privacy Policy," each linking to a public URL. The Apple-hosted standard EULA URL works for the first; the privacy policy URL points to the same domain referenced in App Store Connect. Both links open in SFSafariViewController or the system browser, and both render real content rather than a sign-in prompt.
A paywall with a working EULA link and a missing privacy policy link is a frequent rejection pattern. The reviewer sees the EULA wired up correctly and reads the absent privacy policy as an oversight rather than a deliberate choice. Adding the second link to the same footer fixes the gap.
How do I handle localization without breaking the link?
The honest answer is that App Store Connect supports a privacy policy URL per locale, and an app shipping in multiple languages can ship a different URL per locale. The mechanism is documented inside the App Privacy section of the listing; the field accepts a localized URL for every language the app supports, per the App Store Connect manage app privacy help.
The in-app link follows the same principle, but the implementation is on the developer side. A common pattern is a localized Privacy Policy string in Localizable.strings, paired with a localized URL constant per locale. When the app launches in French, the link opens the French privacy policy; when it launches in Japanese, the Japanese version loads. The destination matches the locale set by the device.
The trap is keeping the metadata URL and the in-app URL in sync per locale. Apple's listing URL and the in-app link should resolve to versions of the same document. A mismatch where the French listing points to one URL and the in-app French screen points to a different URL is technically not a 5.1.1 trigger on its own, but it raises questions during App Privacy form review and slows down localization updates later.
What to watch out for
The most common false fix is adding the privacy policy URL only to the App Store Connect field after the rejection. The reviewer who flagged the build had already confirmed the metadata field; what failed was the in-app link. Re-uploading the same binary with a metadata-only change does not address the rejection. The fix needs to ship in a new build with the in-app link added and the build number incremented.
A second trap is using a privacy generator template that does not match the App Privacy questionnaire. The reviewer can read the privacy policy text and check it against the App Privacy declarations on the listing, per Apple's App Privacy details page. When the policy says the app collects no data, and the App Privacy form declares analytics or third-party SDK data collection, the inconsistency triggers a separate 5.1.1 follow-up. The remedy is to align the document text with the questionnaire before resubmitting.
A third trap is a privacy policy hosted on a service that blocks Apple's review IP ranges or that has intermittent uptime. Reviews are conducted from specific data centers, and a URL behind a geoblock or a hosting service with occasional downtime can return errors during review even when the page loads from the developer's own network. A static HTML page served from a stable hosting provider is safer than a complex CMS that requires JavaScript to render the content.
For builders who want an external automated read of their build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS for no-code and AI-coded mobile apps. The scan flags missing privacy manifest entries, undisclosed SDKs, and patterns reviewers commonly catch, ahead of the App Store Connect ingestion check.
Key takeaways
- Treat 5.1.1(i) as a two-location requirement: the App Store Connect field and a clickable, labeled, account-free link inside the running app.
- Add the in-app link to a screen reachable from a fresh install without authentication, label it "Privacy Policy" in plain text, and verify the destination renders public content.
- For subscription apps, place the privacy policy link on the paywall next to the EULA link, not only in Settings; reviewers verify the purchase screen first.
- A new build number is required to ship the fix; the metadata field alone does not resolve a rejection that flagged the in-app link.
- Some teams running mobile builds through pre-submission audits use platforms like PTKD.com (https://ptkd.com) to catch 5.1.1 patterns and other privacy gaps before uploading to App Store Connect.
