Privacy Policy App Screen: How to Add One That Meets Store Rules

Privacy policies are not bedtime reading, which is why a privacy policy app screen needs to make the useful parts easy to find. This guide covers what to put on the screen, where to link it, and how to meet the separate App Store and Google Play requirements. It is about making your policy available and easy to understand, not writing legal advice from scratch.

What a privacy policy screen must do

A privacy policy screen gives people a lasting way to read how your app handles data. It can be a native page, a web page that opens in the app, or a browser link. Whatever you choose, users must be able to reach it easily. The same policy also needs a public web address for the stores.

Apple requires a privacy-policy link in App Store Connect metadata and an easily accessible link in the app. Its App Review Guidelines also say the policy must name collected data, how it is collected and used, third parties with access, retention and deletion practices, and how people can withdraw consent or request deletion.

Google Play requires every app to have a policy linked in Play Console and available in the app. Its User Data policy says the URL must be active, public, non-geofenced, non-editable, and not a PDF. Even an app that does not access personal or sensitive data still needs to submit a privacy policy.

A privacy policy is not decoration for a Settings menu. It is a promise that must match the data behavior in the shipped app.

This means one thing from the start: do not design a beautiful screen, then fill it with a policy you have not checked against your SDKs. Analytics, crash reporting, sign-in, ads, support chat, and payments can all change what the policy needs to say. The tiny package you added for one helpful feature may have opinions about data. Packages often do.

Write the policy before you design the screen

Start with a plain inventory of what the release build and its services do. This is not the moment to trust a vague “we only collect the basics” note from six months ago. Check the project dependencies, dashboard settings, and backend logs or documentation. Then compare each item with the wording in your policy and store declarations.

Your policy will usually need clear answers to these questions:

• What user and device data do you access or collect?
• How does the app get it: user input, a device permission, automatic collection, or a third party?
• Why do you use it?
• Who receives it, including service providers and SDK partners?
• How do you protect it?
• How long do you keep it, and how can a person request deletion or withdraw consent?
• How can someone contact you about privacy?

Google Play names the same broad areas: access, collection, use, and sharing; security procedures; retention and deletion; and clear labeling as a privacy policy. If your app offers account creation, Google also requires an easy-to-find way to start account deletion in the app and from an external web page. Freezing an account is not deletion, no matter how politely the button is labeled.

Do not copy another app’s policy and swap the name. It may describe products, countries, data processors, and rights that do not apply to yours, while omitting your own. If your app operates in places with privacy laws, get legal advice on the policy language that applies to your business and users.

Make the policy easy to scan

Legal text still needs a readable home. Use a page title, a visible “Last updated” date, clear section headings, normal body-sized text, comfortable line spacing, and vertical scrolling. A linked table of contents helps with a long policy, but it is not needed for a short one.

Do not put the policy behind a login. A potential user, a store reviewer, and someone whose account is locked should still be able to read it. If you load the policy from the web, show a useful message when offline and keep the in-app link stable. A blank web view is not a privacy policy screen. It is an avoidable mystery.

Use the exact label Privacy Policy for the link. “Legal stuff” may be charming in a prototype, but it is harder for people and reviewers to spot. Put the link under Settings, Profile, About, or Legal, wherever it is easy to reach in your app. Make it reachable from the first signed-in screen without a treasure hunt.

Clear headings and a stable link do not make the policy shorter. They make it possible to use.

Use one policy in two places

Most teams should publish a canonical policy at a stable URL such as https://example.com/privacy. Link to that page from the app and enter the same URL in the store portal. A native screen may show the same content, but it does not replace the web page Google Play requires.

This setup reduces drift. When the policy changes, update one source, check that the in-app view reflects it, and update store disclosures if the data practice changed. Apple says its App Privacy answers must cover the app and third-party partners whose code you add, and you must keep them current. Google also requires its Data safety section to match the app’s data practices and privacy policy.

Before choosing a hosted page, check four mundane details:

1. Open it without signing in. Test in a private browser window and from a different region if your site uses country rules.
2. Use HTTPS and a durable URL. Do not point the stores to a draft document, a temporary preview, or a page that your site generator may rename.
3. Keep it as a web page, not only a PDF. Google Play explicitly disallows a PDF as the privacy-policy URL.
4. Check the in-app route too. Tap the link on a real device, rotate the device, enlarge system text, and make sure the back action returns people to where they started.

The policy does not need matching pixels on iOS and Android. It needs matching facts. If your Android build includes an analytics SDK that the iOS build does not, the policy and each store’s declarations must reflect the real behavior on that platform.

Meet Apple’s requirements

For iOS and macOS apps, enter the public policy URL in App Store Connect > App Privacy > Privacy Policy. Apple’s Manage app privacy documentation says the URL is required, while the User Privacy Choices URL is optional. The latter can point to a page where users learn how to access data, request deletion, or change privacy choices.

Then complete the App Privacy questions. Apple asks whether you or third-party partners collect data, which data types are involved, and how the data is used. Its product-page privacy details help people understand data practices before downloading the app. Treat the answers as release work, alongside the binary and store screenshots.

Inside the app, use the accessible Privacy Policy link described earlier. If you collect user or usage data, Apple also requires consent where it applies and an understandable way to withdraw it. A policy page can explain the choice, but it cannot silently make the choice for someone. This distinction prevents awkward work after release.

Apple check before submission

• The App Store Connect URL opens publicly.
• The in-app link is visible and works in the release build.
• The policy names data collection, use, sharing partners, retention, deletion, and consent choices that apply to the app.
• App Privacy answers include your integrated third-party code and match the policy.
• The policy, App Privacy answers, and current app behavior describe the same version of reality.

For the wider release pass, use our App Review Guidelines checklist and the guide to submitting an app to the App Store. A policy link is one review item, not a force field around the rest of the submission.

Meet Google Play’s requirements

In Play Console, go to Policy and programs > App content. Under Privacy Policy, select Start or Manage, enter the public URL, and save it. Google’s prepare-for-review instructions describe that route.

The same policy must be accessible in the app. Google’s User Data policy asks for a policy that accurately covers all user and device data your app accesses, collects, uses, or shares. The developer or company named in the store listing must also appear in the policy.

Complete the Data safety section too. It is not a shorter version of the policy, and it does not replace the policy. Google says its information must be accurate and match your privacy disclosures, including data behavior from SDKs. Keep a small data inventory so you can update all three places when a release changes a service.

Your policy, Data safety answers, and code should tell one story. If they disagree, the code is the most persuasive witness.

Do not confuse the policy with consent

Google Play has another screen people often call a privacy screen: a prominent disclosure and consent screen. A prominent disclosure is a clear in-app explanation shown just before an unexpected sensitive-data action. It is separate from your permanent policy page.

When access to personal or sensitive data would not be reasonably expected for a feature, Google requires a prominent in-app disclosure before the permission request or consent. The prominent disclosure guidance says it should explain why the capability is needed, what data is involved, and how it is used. It also needs a clear affirmative choice and a way to decline.

That disclosure cannot live only in Settings, an app description, a website, the privacy policy, or terms of service. Show it in the flow just before the sensitive action. If a person declines, let the rest of the app continue where possible, with that feature unavailable. “Agree” and “Not now” are much clearer than a lone “Got it” button pretending to be consent.

Google Play check before release

• The URL is a public, active, non-geofenced web page, not a PDF.
• The in-app policy is clearly labeled and works without a fragile login route.
• The policy identifies the listed developer or company and accurately covers your data practices.
• Data safety declarations match the policy and the SDKs in the release build.
• Account-creation apps have an in-app and external route for account-deletion requests.
• Sensitive or unexpected data access has a separate just-in-time disclosure and affirmative consent when required.

For the rest of the Android release flow, see our Google Play publishing guide. It covers the other Play Console tasks that can hold up a release.

Test the privacy path before release

Test this like a feature, because it is one. Run the policy path from a fresh install, an established account, and a logged-out state if the app permits it. Check it with large text, a screen reader, slow network conditions, and the release build. Then have someone who did not add the link try to find it. They will either find it quickly or give you the most honest navigation review you will get all week.

FAQ

Does my app need a separate privacy policy screen?

Not necessarily a separate native screen. Apple and Google require accessible in-app access to the policy, and Google permits a policy link or text within the app. A clearly labeled Settings link that opens a stable policy page can meet that need when it is easy to reach. You still need the public URL for store metadata.

Can I use the same privacy policy for iOS and Android?

Usually, yes. One policy can cover both platforms when it accurately describes each platform’s data handling. Check for differences in SDKs, permissions, account flows, or regional behavior, then make the policy and each store declaration match those differences.

Is a privacy policy the same as a permission prompt?

No. The policy is a lasting explanation of data practices. A system permission prompt asks the operating system for access. Google Play may also require your own prominent disclosure and affirmative consent before unexpected sensitive-data access. Each screen has a different job.

Where should I put the Privacy Policy link?

Use a normal, easily accessible location such as Settings, Profile, About, or Legal. Use the exact label “Privacy Policy.” Also make the policy reachable without login where possible and publish it at the public URL you submit to Apple and Google.

Do I need a policy if my app does not collect data?

Yes for App Store distribution, because Apple requires a privacy-policy link for all apps. Google Play also requires every app to submit a privacy policy, including apps that do not access personal or sensitive user data. Make the statement accurate rather than filling the policy with collection practices you do not have.

Conclusion

Add a clear in-app Privacy Policy link, publish the same policy at a public URL, and make every version of your privacy story agree: the app, the policy, App Store privacy answers, and Google Play Data safety section. Keep just-in-time disclosures separate for sensitive data access. That makes the policy screen useful to people and much less surprising during store review.