None.
Likely to be questioned1. Every sensitive permission declared is one the compiled code references Google Play
What we found declared with no reference found in the compiled code: ACCESS_BACKGROUND_LOCATION. Google requires permissions only for current features promoted in the listing and says unused permissions must be removed; a shrinker can hide a library's reference, so confirm before removing
What to do Developer in the app's AndroidManifest.xml (no source was found in this directory): remove android.permission.ACCESS_BACKGROUND_LOCATION unless a bundled library needs it (a shrinker can hide the reference; check the library's documentation first)
The other store 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. Apple requires an on-screen or audible recording indicator; Google requires the disclosure dialog but no live indicator (except for stalkerware under the Malware policy).
How we know: checked the files and pages directly. Rule reference: google.permissions-are-used.
Likely to be questioned2. Background location is used only for a core feature, disclosed, and declared in the console Google Play
What we found background location is requested; no geofencing or background-update code was found in the compiled code (a shrinker can hide it): if nothing uses it, remove the permission; the disclosure dialog cannot be checked until the app's strings are given under okkok/texts/; the Play description cannot be checked until okkok/the listing file is given; the Play declaration form and video need a look in the store console
What to do Developer in the Play Console description (okkok/listing.toml here); the app's disclosure dialog; Play Console, App content, Location permissions; the app's AndroidManifest.xml (no source was found in this directory): In the Play Console description, add a sentence in the app's own words saying which feature uses location in the background or when the app is closed. Add to the disclosure dialog shown before the location prompt: the word 'location', that it is used in the background or when the app is closed, and every feature that uses it. File the Play declaration form naming exactly one background-location feature, with a video that shows the feature, the disclosure and the prompt. Either the permission is unused and should be removed, or the code reference is hidden by the shrinker; confirm which.
The other store 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 mandates the pre-prompt dialog for background location with required wording ("location", background/closed); Apple leaves the screen optional and specifies its button design.
How we know: checked the files and pages directly. Rule reference: google.background-location-is-core.
Not checked yetThe support link opens a real page with a way to contact the developer Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
The other store Apple requires the contact route to be reachable from the app and support page; Google requires verifiable details in the console (plus D-U-N-S and organisation registration for financial, health, VPN and government apps), which are surfaced on the listing rather than required inside the app.
How we know: needs a look in the store console. Rule reference: apple.1.5.support-url-reachable.
Not checked yetNo placeholder or temporary text anywhere in the listing Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
How we know: needs a look in the store console. Rule reference: apple.2.1.no-placeholder-text.
Not checked yetThe store name is short, plain, and free of emoji, shouting and special characters Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
The other store Title length is identical (30 characters). Google additionally bans emoji and repeated special characters in title/icon/developer name, all-caps outside a brand name, unattributed testimonials, misleading icon symbols and claims of ranking, price or a Play programme; Apple additionally requires screenshots that show real use (not splash or login), previews that are app captures only, fictional rather than real-person data, no other platforms' imagery, and a specific "What's New".
How we know: needs a look in the store console. Rule reference: both.listing-name-rules.
Not checked yetListing texts fit the stores' length limits Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
How we know: needs a look in the store console. Rule reference: both.listing-lengths.
Not checked yetNo guarantee or emergency-service claim without a negation next to it Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
The other store 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 prescribes scope tiers, foreground-service lifetime and a console declaration; Apple prescribes relevance, consent and in-app purpose explanation.
How we know: needs a look in the store console. Rule reference: both.no-unqualified-claims.
Not checked yetThe privacy policy link in the listing opens and is a real page Both stores
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in both consoles: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
The other store 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).
How we know: needs a look in the store console. Rule reference: both.privacy-policy-reachable.
Not checked yetTitle, icon and developer name carry no emoji, shouting, ranking, price or programme claims, and no anonymous testimonials Google Play
What we found listing.text: no okkok/the listing file: the listing was not read, and no console was read
What to do Store account owner in Play Console: Read the field named in the evidence and record it, or give the tool console credentials so it reads it itself.
The other store Title length is identical (30 characters). Google additionally bans emoji and repeated special characters in title/icon/developer name, all-caps outside a brand name, unattributed testimonials, misleading icon symbols and claims of ranking, price or a Play programme; Apple additionally requires screenshots that show real use (not splash or login), previews that are app captures only, fictional rather than real-person data, no other platforms' imagery, and a specific "What's New".
How we know: needs a look in the store console. Rule reference: google.listing-metadata-rules.
Not checked yetNo objectionable content, and no fake or joke features such as a fake location tracker Both stores
What we found awaiting judgement, From the listing, the screenshots and the app's own strings: is anything offensive, discriminatory, violent, sexual or inflammatory? Does any feature fake device data or pretend to do something it does not, such as a location tracker that does not track? Name what you looked at.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: apple.1.1.no-objectionable-or-fake-features.
Not checked yetIf users can post content or interact, the app can filter, report, block, and shows contact details Both stores
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: apple.1.2.user-content-moderation.
Not checked yetThe app never tells people to restart the device or change unrelated system settings Both stores
What we found awaiting judgement, From the app's strings and screens: does it ever ask the user to restart the phone, turn off Wi-Fi, disable a security feature, or change a system setting unrelated to its own feature? Asking to allow its own permission is fine. Name the strings you read.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
The other store Google permits setting changes with consent and reversibility; Apple bans instructing unrelated settings changes outright.
How we know: checked the files and pages directly. Rule reference: apple.2.4.no-forced-settings-changes.
Not checked yetCryptocurrency features stay within what Apple allows: no mining on device, licensed exchanges, organisation-enrolled wallets Both stores
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: apple.3.1.5.cryptocurrency.
Not checked yetNothing is locked behind rating, reviewing, or installing other apps Both stores
What we found awaiting judgement, From the app's strings and screens: is any feature, content or use gated on rating the app, writing a review, or installing another app? Asking for a rating without gating anything is fine.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: apple.3.2.2.no-forced-store-actions.
Not checked yetThe name, icon and interface are the developer's own and impersonate nothing Both stores
What we found awaiting judgement, Search the App Store for the app's name and close variants. Does another app or service use this name, icon or look? Does anything in the listing borrow another developer's brand? Record what was searched and what was found.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: apple.4.1.not-a-copycat.
Not checked yetThe app offers real utility beyond a repackaged website and works without another app Both stores
What we found awaiting judgement, Is the app more than a web page in a shell (a web view alone is the warning sign)? Does it work without installing another app? If it downloads a large resource at first launch, is the size disclosed and confirmed? Was it generated from a commercial template by someone other than the content owner?
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: apple.4.2.more-than-a-website.
Not checked yetEverything in the app and its listing is the developer's own or licensed, and nothing suggests Apple's endorsement Both stores
What we found awaiting judgement, Do the name, icon, screenshots, strings or bundled assets use anyone else's trademark, artwork, emoji or product likeness? Does the app pull content from a third-party service whose terms forbid it? Does any text imply Apple supplies or endorses the app? Name what you checked.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: apple.5.2.only-owned-or-licensed-content.
Not checked yetThe privacy policy names what is collected, who processes it, retention, deletion and consent withdrawal Both stores
What we found awaiting judgement, Read the privacy policy text against the facts. Does it name every data type the app and its libraries collect, name the processors, state retention periods, describe in-app deletion, and describe how to withdraw consent?
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
The other store 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). 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.
How we know: checked the files and pages directly. Rule reference: both.privacy-policy-content.
Not checked yetAn app that generates content with AI lets users report offensive output in the app Google Play
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: google.ai-content-reporting.
Not checked yetUnless a licensed gambling operator, nothing lets users stake money for a prize of real value Google Play
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: google.no-real-money-prizes.
Not checked yetNothing in the app imitates a system warning, another app, or a store interface Both stores
What we found awaiting judgement, From the app's strings and screens: does any dialog, banner or notification look like an operating-system warning, a virus alert, a battery warning, or another app's interface? Name the strings you read.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: both.no-fake-system-warnings.
Not checked yetEvery foreground service type has its matching permission, and is declared in Play Console Google Play
What we found foreground service types health, location, mediaPlayback, specialUse each have their permission; whether each is declared in Play Console with a use-case description and a video needs a look in the store console, and whether each is user-initiated, perceptible, stoppable and undeferrable is a judgement
What to do Someone must decide: foreground service types health, location, mediaPlayback, specialUse each have their permission; whether each is declared in Play Console with a use-case description and a video needs a look in the store console, and whether each is user-initiated, perceptible, stoppable and undeferrable is a judgement
The other store Google adds concrete foreground-service rules for Android 14+ (declared type, permission, Play Console use-case description and demo video); Apple states outcomes (battery, heat) rather than mechanisms. Google explicitly permits interpreted code such as JavaScript in a webview; Apple's wording bans any downloaded code that changes the app. Google's foreground-service rules are more prescriptive (type declaration, console description and video).
How we know: checked the files and pages directly. Rule reference: google.foreground-service-types-declared.
Not checked yetThe app updates itself only through Play and downloads no executable code Google Play
What we found awaiting judgement, Does anything in the compiled code load dex, JAR or native libraries from the network or from storage at run time (DexClassLoader, System.load from a downloaded path), or install APKs? Web content in a web view is allowed. Name what you looked for.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: google.no-executable-download.
Not checked yetThe app stays usable when a person refuses a sensitive permission, and no feature is gated on turning one on Both stores
What we found awaiting judgement, Deny each sensitive permission on a device. Does the app keep working with a reasonable alternative, or does it block, loop the prompt, or pressure the user? Name the permissions tried and what happened.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
How we know: checked the files and pages directly. Rule reference: google.usable-when-permission-denied.
Not checked yetAn app that lets one person see another's location or activity is not a monitoring app, or is a lawful one Google Play
What we found awaiting judgement, asked because the app declares or uses location: The app shares location or activity between people. Who installs it, who controls the sharing, and can the person being seen stop it at any time and see that it is happening? If the watched person installs it on their own phone, chooses what to share and is told each time, it is not a monitoring app. If someone else installs it on their phone or the sharing cannot be seen or stopped by them, it is stalkerware unless exclusively for parents over children or employers over employees, marketed only as that, flagged IsMonitoringTool, with a persistent notification, a unique icon and the monitoring disclosed in the description. State which case and why, from the listing and the app's own screens.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
The other store Google requires a persistent notification, unique icon and manifest flag while running, and forbids tracking any other adult even with consent; Apple restricts who may publish MDM, requires Apple's permission for the capability, and bans any third-party data disclosure. Google bans sale outright and bans linking persistent device identifiers to personal data; Apple limits third-party sharing to improving the app or serving ads and separately bans building contact databases from Contacts/Photos and collecting installed-app lists.
How we know: checked the files and pages directly. Rule reference: google.not-stalkerware.
Not checked yetNotifications carry the app's own features, never ads or another app, and look like the app's Both stores
What we found awaiting judgement, asked because the app declares or uses notifications: The app sends notifications. From the app's strings and the server code if available: is every notification about the app's own feature, attributed to the app, never promotional for another app or service, never styled as a system warning, and never required for the app to work?
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
The other store Apple permits promotional notifications with explicit opt-in; Google bars notifications carrying ads for other apps or services regardless of consent.
How we know: checked the files and pages directly. Rule reference: both.notifications-only-for-the-apps-own-features.
Not checked yetDigital purchases use Play billing, nothing steers users elsewhere, and prices match the Play bill Google Play
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: google.play-billing-for-digital-goods.
Not checked yetSubscription screens state cost, frequency, renewal and a way to continue without subscribing Google Play
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: google.subscription-transparency.
Not checked yetThe app never sends a message on the user's behalf without showing content and recipients first Google Play
What we found whether this rule applies is not decidable yet: whether it applies depends on the store listing text (okkok/the listing file), which was not given
What to do Build engineer: Provide the built package so the tool can tell whether the rule applies.
How we know: checked the files and pages directly. Rule reference: google.no-messages-without-confirmation.
Not checked yetThe in-app disclosure names the feature, the data, and that it happens in the background Google Play
What we found awaiting judgement, Only when ACCESS_BACKGROUND_LOCATION is declared: from the app's own screens, is there a prominent disclosure, shown in normal use immediately before the location runtime prompt, that uses the word 'location', says the use happens in the background or when the app is closed, and lists every feature that uses background location? Google requires no separate accept tap; the runtime prompt that follows is the consent. Is the same disclosure in the app description and on the website? Name the screen and quote its text.
What to do A reviewer: Answer the question with what was looked at, quoting the app's own text or screen, then record it with the judge command.
The other store 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 mandates the pre-prompt dialog for background location with required wording ("location", background/closed); Apple leaves the screen optional and specifies its button design.
How we know: checked the files and pages directly. Rule reference: google.background-location-disclosure-wording.
Worth knowingEvery restricted permission declared meets its own condition: default handler, review, declaration, or core purpose Google Play
What we found background location declared; its own rule checks the disclosure and console declaration
What to do Developer in the app's AndroidManifest.xml (no source was found in this directory): For each permission named in the finding: remove it if the feature does not need it; otherwise meet its condition (the default-handler intent filter, the console declaration, the review, or the listing text) named in the finding.
The other store Google prescribes scope tiers, foreground-service lifetime and a console declaration; Apple prescribes relevance, consent and in-app purpose explanation. Apple requires a data-declaration screen before any purchase or use and a no-disclosure promise in the privacy policy; Google requires encryption, listing documentation and no traffic manipulation.
How we know: checked the files and pages directly. Rule reference: google.restricted-permissions.