Blocks submissionApp Store

Each purpose string says what the app does with the access, not just that it wants it

The question Read each purpose string. Does it name the feature that needs the access and what the app does with the data, in words a user would understand? A string that only says the app 'needs' or 'uses' the access does not qualify.

A person or a model answers it from the app's texts and screens; the answer is kept only while the facts it saw are unchanged.

Applies to every app

Checked from built, not yet uploaded, on a test track, submitted and in review, published

The rule, in our words

• Privacy: Supply your privacy practices and collected data types at submission for the product page. Request only data a feature actually needs, ideally when the person first uses that feature; avoid asking at launch unless the app cannot work without it. Aim for a purpose string that is a short, specific, active sentence saying how the app uses the access (sentence case, ends with a period); vague or imperative strings are the counter-examples. If you show a custom screen before a system permission alert (camera, microphone, location, contacts, calendar, tracking), include only one button, titled something like "Continue" or "Next" rather than "Allow", that opens the system alert, with no close or cancel path. Offering incentives, imitating the alert, showing an image of the alert, or annotating the screen behind it will be rejected by App Review. For tracking at launch, the system alert must appear before any tracking data is collected.
• App Review Guidelines: Use location only where it is directly relevant to the app's features, notify the user and obtain consent before collecting, transmitting or using location data, explain the purpose in the app; location APIs should not be used to provide emergency services or autonomous control of vehicles, aircraft or other devices (small devices like toys, lightweight drones and car-alarm remotes excepted).

Okkok never stores the stores' text. Each item above is our paraphrase, and the link is the page it rests on, verified unchanged by fingerprint on every run.

The other store

• Google requires the smallest scope (coarse over fine, location button for one-time uses), makes the location button mandatory for transactional precise uses in apps targeting Android 17 (API 37), requires a Play Console declaration for every ACCESS_FINE_LOCATION request, bans sale of location data, and sets a compliance date of January 27, 2027 with 30-day self-extensions; Apple sets no scope tiers or declaration. google-stricter
• Google requires a Permissions Declaration Form naming exactly one background feature, a video of 30 seconds or less, a prominent in-app disclosure that uses the word "location" and states background use before the runtime prompt, the same disclosure in the description and website, and a non-PDF policy URL linked in-app and on the listing; Apple requires in-app purpose explanation and consent only. Apple alone bans building emergency services or vehicle/aircraft control on location APIs. google-stricter
• Google prescribes scope tiers, foreground-service lifetime and a console declaration; Apple prescribes relevance, consent and in-app purpose explanation. google-stricter
• From January 27, 2027 Google reviews every location request through a declaration; Apple has no declaration or review form for location. google-stricter

Check your app

pip install git+https://github.com/petresandu-cloud/okkok
okkok audit path/to/app

The report names this rule as apple.purpose-strings-say-why and says what to do, who does it, where, and how it knows.