Getting your app compliant

Go to Settings › Privacy center, Permissions tab.

There you'll find the list of permissions your app may request from your users' devices, and, for each one, a Usage column naming the feature or features that trigger it.

That's what makes this screen valuable: it doesn't ask you to guess, it tells you where each permission comes from.

The list isn't the same length on every app, because it follows what your app carries. A shop shows twenty permissions; a content app carrying media playback and geolocated notifications shows more.

A few lines, to give you the flavor:

Read that column as an inventory. If a permission surprises you, look for the feature named next to it: that feature asked for it, not the platform.

Every permission that interrupts the user carries a Message field. This is the text the system displays at the moment your app asks for access, and a default text is suggested.

That field deserves better than its default value, for a simple reason: it's the only place where you can explain why you're asking. A user who understands accepts, a user who doesn't refuses, and a refusal is paid for in degraded features. So write what the permission is for in your app, not what it is.

The Use default message link puts the original text back if you want to undo.

The screen says so itself: any change to permissions only reaches your users once your app has been recompiled and resubmitted to the stores. That's true of all three outputs, iOS, Android and the Progressive Web App.

This isn't a scheduling detail. It means this chapter is dealt with before your submission, not during it.

The Privacy center files its settings under tabs, and they don't all speak to every app.

The screen separates two mechanisms, because they don't apply in the same place.

For your native apps, the alert goes through Funding Choices, and it's switched on platform by platform, iOS, Android and Progressive Web App each having their own toggle, with your advertising account identifier to fill in. The screen leaves no doubt about what's at stake: without it, your ads stop being served to your European visitors.

For your Progressive Web App, it's the cookie alert. You choose between a quick consent and a detailed consent, you write its title and its text, you choose the page its link leads to, and you dress it in your logo, your main color and your font.

This chapter overlaps with "Making money with your content app", which covers the same screen from the advertising angle.

This screen switches on age verification for native apps. Once it's on, your app adapts its features to the declared age and closes off the parts that aren't meant for minors.

It's the only one of these tabs that changes what your users see, rather than what you declare.

Two contact blocks, each with a name, an address, a phone number and an email: your data protection officer, and your representative in the European Union. Fill in the ones that apply to you.

The same screen asks you to download and sign the data processing addendum, which is an integral part of the terms of service.

This is the point where the two product lines diverge, and the confusion is common. A content app handles its terms and its privacy policy from a fifth tab of the Privacy center, and the guide "Charging for access to your content" describes that path. A shop doesn't have that tab: it has its own screen, Settings › Terms and Conditions, where the shop's terms of sale and privacy policy are set.

Apple and Google both ask you to declare what your app collects, each in its own form. Our help center gives the step-by-step, screen by screen, including how to enter the address of your privacy policy on each side.

What matters here is where the answers come from.

Both forms ask their questions by data category: location, identifiers, in-app activity, photos and videos, personal information. And for almost every one of them, the answer depends on what you switched on. Location is only declared if the matching permission is active. A user identifier is only declared if you have authentication or in-app purchases. Advertising data is only declared if the advertising identifier is.

In other words, chapter 1 of this guide is the answer to the form. Take inventory first, fill in second, and you'll tick neither too much nor too little.

One point our help center states in black and white, and it bears repeating: you are responsible for the accuracy of what you declare. The platform tells you what it collects to make your app work, it doesn't know about the uses you add on top.

This whole guide comes down to a question of timing.

All four screens are set before submission. A change to permissions means recompiling and submitting again. A missing consent alert doesn't show up while you're building, it shows up when your ads stop being served in Europe, or when a reviewer rejects your app.

The cost of a rejection isn't the rejection itself, it's when it lands: once everything is built, announced, and often dated. A quarter of an hour on these four screens before you press the submit button saves you a round trip of several days.

And if a rejection comes anyway, our help center has a whole category for dealing with them, on Apple's side as well as Google's.