← All privacy impact assessments
PIA: Asking for an App Store or Google Play rating
Status: Built on 9 October 2026, not yet released. Written alongside the code, before it reached anyone. Written: 9 October 2026 · Last revised: 9 October 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).
1. Purpose and scope
To ask members who are getting on well with GroupApp whether they'd rate it, because today only people who go looking for the store listing leave a rating.
After a member ticks off one of their own tasks, the app may ask the phone's operating system to show its standard rating request. It does that once the member has finished five of their own tasks on that phone, at least a week after the app was installed, and at most once per app version. Apple or Google then decide whether anything appears. The app never shows its own rating screen and never puts the request behind a button.
Out of scope: anything Apple or Google do with a rating or review a member chooses to give, which is between the member and the store.
2. Data involved
| Kind | Whose | Children's? | Sensitive? | Free text? |
|---|---|---|---|---|
| A count of the member's own finished tasks on this phone, which stops at five, and the app version last asked about, kept on the phone only | The member's own | Not for a child account, which never reaches this code. Yes for a 16- or 17-year-old | No | No |
| When the app was installed, read from the phone and not stored | The member's own | As above | No | No |
| Whether a rating request appeared, and any rating or review | Not collected. Neither Apple nor Google tells the app | — | — | Typed into the store's own screen, never ours |
Nothing about the tasks themselves is read: not their names, the group they belong to, or when they were done. The count is the only thing kept.
3. Flows and locations
| Data | Device | Supabase (Sydney, ap-southeast-2) | GCP (australia-southeast1) | Model provider | Region |
|---|---|---|---|---|---|
| The count and version | Yes, in the phone's keychain, not backed up or moved to another phone | No | No | No | — |
| A rating or review, if the member gives one | Apple's or Google's own screen | No | No | No | Apple or Google, under the member's own store account |
4. Legal basis and consents
None of our consent purposes is involved: nothing leaves the phone for us, and nothing reaches a model. Whether to rate is the member's choice at the moment the store asks, and dismissing the request costs nothing. A rating or review is given to Apple or Google under their terms.
5. Risks and mitigations
| Risk | Who is harmed | Mitigation | Structural or conventional? | Residual |
|---|---|---|---|---|
| A child is asked to rate the app | A child with a child account | The request follows only a tick by someone the phone has confirmed is not a child account. While the answer is unknown, it isn't sent | Conventional, test-pinned | Low |
| Someone passing a shared display in the house, perhaps a child, sees a rating request | Whoever is at the wall | Only a person's own tick on their own phone counts. The wall's account, a profile without a phone, and a phone set up as a shared display never ask | Conventional, test-pinned | Low |
| A member is asked again and again | Any adult member | Once per app version, at most, on our side. iOS shows the request at most three times in 365 days. Google limits how often its dialog appears | Ours conventional, test-pinned. The stores' limits are enforced by the operating system | Low |
| The count says something about how much someone does around the house | The member | It never leaves the phone, stops at five, and isn't shown to anyone | Structural: there is no server copy to read | Negligible |
6. Structural versus conventional
- Structural: no table, column or request carries any of this. The count exists only in the phone's keychain, which isn't backed up and doesn't move to another phone. The operating system decides whether the request appears and how often.
- Conventional, test-pinned: who is asked (a known adult's own tick, a person, not a shared display), the five-task and one-week thresholds, once per version, and never behind a button. Each is held by an automated test that fails if the line enforcing it changes.
7. Best interests of the child
Not shown to child accounts, so a child isn't asked to rate or review anything. 16- and 17-year-olds can be asked, the same as by any other app on their phone, and whether to answer is theirs. A child with no phone of their own, using the wall, is never asked, because the wall never asks.
8. Residual risk we accept
- A 16- or 17-year-old can be asked. We treat them like an adult here. A rating or a written review on the store is their own, under their own store account and the store's rules, not ours.
- The request comes at a moment of having done something. That's the point: it asks people who are getting on well with the app. It's never shown during a task or before the task saves, and dismissing it costs nothing.
- On an iPhone the count can outlast removing the app. The keychain survives an uninstall. It's still only a number up to five and a version.
9. Review trigger
- The app starts showing its own rating screen, or a button that asks for a rating.
- The count starts leaving the phone, or the request starts following anything other than a member's own finished task.
- Child accounts or the shared display start being asked.
10. Checklist against exposure draft s 38(2) (verified 2026-09-08)
| s 38(2) | Requires | Answered in |
|---|---|---|
| (a) | nature, scope, context, flow and purposes | §§1–3 |
| (b) | why collecting children's personal information is strictly necessary | §2: none is collected from child accounts. For 16- and 17-year-olds, a count up to five on their own phone, which the request needs |
| (c) | lawful and fair means | §4 |
| (d) | best interests of the child | §7 |
| (e) | how we comply with the Code and the Act | §4 and §6 |
| (f) | risk of harm to children | §5 |
11. Sources
lib/storeReview.ts: the count, the thresholds and the request.store/slices/createTasksSlice.ts(toggleGroupTask): who is asked, decided before the tick is saved, and asked only after it is.lib/__tests__/storeReview.test.tsandlib/__tests__/childAgeGates.test.ts: the tests named in §6.- Apple,
SKStoreReviewController.requestReview(in:)(developer.apple.com, StoreKit documentation): at most three times in 365 days, App Store policy governs whether it is shown, no effect in TestFlight, never in response to a button. Read 9 October 2026. - Google, "Google Play In-App Reviews API" (developer.android.com/guide/playcore/in-app-review): needs the Google Play Store, a time-bound quota, no call-to-action button. Read 9 October 2026.