Blocks submissionApp Store

Every capability the code uses has a purpose string in Info.plist

What is checked This rule is decided by code from the built app and the listing: ios.built.info, ios.built.references.

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: A privacy policy link is required in App Store Connect and inside the app; the policy must say what data is collected, how, and every use; confirm that any third party receiving user data (analytics, ad networks, SDKs, parent or related entities) gives equal protection; and explain retention, deletion, and how to withdraw consent or request deletion. Consent must be obtained for any data collection, even anonymous data; paid features may not depend on granting data access; users need an easy way to withdraw consent; purpose strings must fully describe data use. Collect only data the core function needs, prefer pickers and share sheets, never force or trick consent, and offer alternatives when a permission is declined. If the app has no significant account-based features it must work without login; if it supports account creation it must offer in-app account deletion; personal information may not be required except for core function or by law.

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's policy is far more detailed (web resource, Data safety deletion questions, TV/Wear/web exemptions, device-management exemption); Apple's 5.1.1 sentence is a pointer to apple.account-deletion. Apple has no exemption for enterprise device-management apps. partial
• Google requires the policy URL to be public, non-PDF and to name the developer with a contact, and bans selling data; Apple requires consent even for anonymous data, requires the policy to confirm third parties give equal protection, and bans making paid features depend on granting data access. partial
• Google's disclosure is a structured form covering the app and every SDK (collected vs shared, purposes, optional vs required, encryption, deletion path or 90-day auto-delete) that must precede publishing on any track except internal testing; Apple's is a free-form policy (the structured equivalent is apple.hig.privacy / apple.privacy-manifest). partial
• none on principle; Google adds per-permission conditions (SMS, call log, all-files, QUERY_ALL_PACKAGES, accessibility, exact alarms) and console declarations; Apple adds purpose-string content rules. same

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-string-for-every-used-capability and says what to do, who does it, where, and how it knows.