LaunchLint Academy
The short answer
- When an app allows account creation, Apple and Google expect a discoverable deletion path. Uninstalling the app, signing the user out, or pointing to an ambiguous support request without a traceable outcome does not remove the account.
- This guide connects store requirements with secure product and backend implementation. It covers entry points, identity verification, data inventory, retention, the Google Play web resource, review evidence, and end-to-end testing for Expo and React Native apps.
- Treat deletion as a stateful request rather than one SQL statement. A reliable flow moves through requested, identity verified, access disabled, downstream systems processed, residual records classified, and completed. Users receive a meaningful status while operators can retry one failed dependency safely. Define what is allowed during a legal retention period: the profile must not become active again, residual records must not feed marketing or new product analytics, and access remains limited to authorized roles. Re-run the full lifecycle whenever identity, storage, analytics, billing, backup, or support integrations change. Include observability that reports stuck jobs without exposing the user’s sensitive content, and establish an escalation target before launching the feature.
- A recurring sample test ensures new tables, buckets, and providers do not grow outside the deletion plan. Every architecture change that stores personal data should update both the inventory and deletion workflow. Include this requirement in engineering review and migration templates so privacy behavior evolves with the system rather than through a later manual cleanup.
Define the account and policy scope
First determine whether the product creates a user account. Apple generally requires apps that support account creation to let users initiate deletion inside the app. Google requires an in-app path for covered apps plus a web resource where users can request deletion.
Model the boundary technically: primary user record, identity provider, tenants, linked profiles, and guest data. Without that definition, account can mean different things in the interface, privacy policy, and backend.
Scope decision
- Identify account creation accurately
- Separate guest and registered data
- Map identity provider to internal IDs
- Document Apple and Google obligations
- Name an owner for privacy decisions
Make deletion discoverable in the app
Place the entry where people expect account controls, such as Account, Privacy, or Security. Do not hide it behind a generic FAQ, chat widget, or an obscure chain of navigation.
You may explain consequences and request confirmation before the final action. Avoid manipulative friction such as unnecessary calls, artificial waiting chains, or repeated sign-in steps that do not contribute to identity assurance.
In-app experience
- Entry under Account, Privacy, or Security
- Explain consequences in plain language
- Confirm without a dark pattern
- Show request status
- Verify accessibility and localization
Provide the Google Play web resource
Google Play also asks for a functional URL in Play Console. The page should offer a clear deletion request, visibly identify the app or developer, and explain which data is deleted or retained for legitimate reasons.
This page does not replace the in-app flow. Test it on mobile, without existing marketing cookies, and in all promoted languages. A generic privacy policy is insufficient when it provides no concrete deletion action.
Public resource
- Public HTTPS URL works
- App or developer identity is visible
- A concrete request can be submitted
- Retention is explained
- Mobile and locale variants are tested
Verify identity proportionately
Deletion is security-sensitive: an attacker must not trigger it with only a known email address. Use a current session, re-authentication, or a short-lived verified link according to the risk and authentication model.
Collect only information needed for verification. Support should not request identity documents when an existing authentication method is adequate. Audit important states without logging secrets or complete tokens.
Security controls
- Current session or re-authentication
- Short-lived verification links
- Rate limiting against abuse
- No secrets in audit records
- Support recovery for lost access
Delete, anonymize, or retain data
Build a data inventory before implementing the endpoint. Include files, scans, exports, device tokens, analytics identifiers, support records, backups, and derived profiles in addition to the user table.
Some records may need temporary retention for legal, fraud, or security purposes. Separate them from the active profile, limit access and purpose, and explain the period. Indefinite retention for convenience is not a defensible policy.
Data inventory
- Primary data and files included
- Backup handling and timelines set
- Residual records purpose-limited
- Analytics links removed
- Tokens and sessions revoked
Handle subscriptions and external systems
Account deletion and cancellation of a store subscription are separate operations. Tell users when an active subscription must be managed in store settings, while ensuring deleted accounts are not unnecessarily linked to purchase history.
Plan every external processor: identity, email, analytics, payment, object storage, and support services need deletion or anonymization steps. Make jobs idempotent so retrying a partial failure does not create conflicting states.
System integration
- Separate subscription guidance
- Inventory every processor
- Use idempotent background jobs
- Retry partial failures safely
- Confirm every downstream step
Explain the outcome to reviewers and users
Before confirmation, state the consequences, expected timeline, and any data that remains. After the request, show a clear status and send a completion notice through a verified channel if processing is asynchronous.
Review Notes should provide the precise navigation path, a working test account, and any prerequisites. Reviewers should not need to contact support to find or exercise the feature.
Communication
- Explain effects and timing
- Acknowledge the request
- Send completion confirmation
- Document the review route
- Maintain a working test account
Test and evidence the complete lifecycle
Test the full lifecycle with a purpose-built account: create data, simulate files and subscriptions, initiate deletion, retry failed jobs, and then verify sign-in, API access, downloads, and notifications.
Also test the public web resource, localization, accessibility, and deep links. Record build, backend version, date, and expected residual data. This turns a button into an evidence-backed privacy capability.
Acceptance test
- Sign-in fails after completion
- APIs and downloads are unavailable
- No further push or marketing messages
- Web and app flows pass
- Expected residual records are verified
Frequently asked questions
Is contacting support enough?
Usually not as the only path. Apple expects initiation in the app, while Google requires an in-app route and linked web resource for covered apps.
Must every database row disappear immediately?
Not always. Time-limited legal or security records may remain if they are minimized, protected, and explained.
Does deletion cancel a store subscription?
Do not assume it does. Explain separate store subscription management and handle purchase associations carefully.
Can I require re-authentication?
Yes. Proportionate re-authentication protects against unauthorized deletion but should not become artificial friction.
What belongs in Review Notes?
The exact navigation path, a working test account, and every prerequisite needed to test deletion.