Privacy decision guide · reviewed July 21, 2026
Protected-app choices, reflection text, usage signals, purchases, and optional analytics are different data. A trustworthy privacy story says what happens to each one.
This guide is published by GrateGuard and describes GrateGuard’s own approach alongside independent first-party privacy and platform sources. It is not legal advice.
Quick answer
Ask separately about reflection text, selected apps, the signal that an app opened, optional diagnostics, purchase processing, reminders, backups, and support. One local data type does not make every optional service local.
Lower-data default
An account can support sync and recovery, but it should have a clear purpose. If the core habit can work locally, no-account onboarding reduces the identity data required before value appears.
Honest optional services
Store payments, customer support, crash reporting, and optional analytics can involve providers even when core habit data stays local. The product should name those boundaries plainly.
Privacy ledger
Read the product’s privacy policy and the current store disclosure together. Store labels summarize categories; the policy should explain purpose and optionality.
| Data or permission | Question to ask | GrateGuard’s stated approach |
|---|---|---|
| Account identity | Can the core app-blocking flow start without email, phone number, social login, or a profile? | GrateGuard says no account is required for the core app experience. |
| Reflection text | Does personal journal or gratitude text leave the device, enter backups, or appear in analytics? | GrateGuard says gratitude entries stay on-device and are not included in optional analytics. |
| Protected apps | Are selected app names or per-app usage histories uploaded, sold, or used for advertising? | GrateGuard says protected-app choices stay on-device and it does not use advertising IDs for the optional coarse milestone flow. |
| System permission | Why is Screen Time or Accessibility access needed, and does the app explain the platform-specific difference? | GrateGuard documents Apple Screen Time controls on iPhone and local Accessibility-based app-open detection on Android. Apple Platform Security |
| Optional analytics | Is analytics off until consent, limited to coarse milestones, and reversible from settings? | GrateGuard describes optional consent for coarse lifecycle and feature-state signals and says consent can be withdrawn. |
| Purchases and deletion | Which store or subscription provider processes purchases, and can locally stored data be reset without contacting support? | GrateGuard separates store-managed purchase services from local habit data and provides an in-app local data reset. |
Method and sources
This checklist uses the GrateGuard privacy disclosure, Apple and Google platform documentation, and privacy pages from another intervention app as independent references for the questions users should ask. It does not infer that every app with the same system permission handles data the same way. Last reviewed on .
Questions
A strong privacy design minimizes identity data, keeps sensitive habit content local where possible, explains every system permission, makes optional analytics genuinely optional, and separates purchase or support services from core data.
Not automatically. A no-account app may still use optional analytics, crash reporting, purchases, support, or backups. Read the policy for each data flow instead of treating account creation as the only test.
The operating system needs a controlled way to identify or respond when selected apps are used. The exact mechanism differs by platform, and the app should disclose why it is needed before asking.
GrateGuard says its core experience starts without an account. Its privacy disclosure separately explains local habit data, optional analytics, store-managed purchases, and data-reset controls.
Read, then try
Review GrateGuard’s privacy disclosure, then open the current store listing for the permissions and terms that apply to your device.
