Closure vs. Deletion: Two Different Things
Most people use "delete my account" to mean one thing: I want to stop using this app and I want my data gone. From the user's perspective, these are the same request. From a product and legal perspective, they're two separate operations, and conflating them is one of the more common ways developers create compliance problems for themselves while simultaneously failing users.
Account closure is the soft version: the account is deactivated, the user can no longer log in, the data is retained. This is what many apps actually do when they say "delete account" — they close the account without deleting the underlying data. Sometimes this is deliberate (they're betting users will return). Sometimes it's because building actual deletion is harder than blocking login. Sometimes it's genuine compliance concern: retaining certain data for specific periods is legally required in some jurisdictions, and conflating retention requirements with deletion makes everything murkier than it needs to be.
Account deletion is the real thing: the identifiable personal data associated with the account is erased, promptly and completely, leaving only what legitimate compliance requires. GDPR calls this the right to erasure. The DPDPA 2023 establishes a similar right for Indian users. Google Play's policies require apps that collect personal data to offer account deletion that includes data deletion, not just deactivation.
Both operations should exist. They serve different purposes. Closure handles the "I want to step back" case. Deletion handles the "I want my data gone" case. Presenting only one and calling it the other is how you build something that doesn't do what it says.
The 30-Day vs. 24-Hour Question
When a user requests account deletion, how long should it take? This seems like a simple question with an obvious answer — as fast as possible — and it is that, mostly. But there are legitimate reasons for a grace period between the deletion request and the actual deletion, and understanding those reasons is important for getting the design right.
The most common legitimate reason: accidental deletion. A brief window between "I requested deletion" and "my data is gone" allows users to reverse a decision made in error. For apps with significant personal data — social history, financial records, health data — a 30-day grace period is common practice and is recognised as reasonable by most privacy frameworks. The user is notified that deletion has been requested and that it will proceed unless cancelled within the window.
The illegitimate reason for a long grace period: hoping the user comes back. A 30-day window during which the user is actively emailed with retention messaging is not a grace period — it's a manipulation pattern. The grace period should be designed around the user's benefit (reversibility), not the company's (retention). If you can't honestly say the grace period is there to help the user, it shouldn't be there.
For Twunein, the deletion flow includes a window that gives users time to reverse the decision if it was made accidentally, with clear confirmation of what will happen and when. The messaging during that window is informational, not persuasive. At the end of the window, the deletion proceeds without further friction. The user doesn't need to confirm again, contact support, or navigate a cancellation flow.
What You Actually Have to Keep
Account deletion is complicated by the reality that some data must be retained for reasons beyond user preference. Financial transaction records. Usage records for fraud investigation purposes. Data subject to ongoing legal holds. These retention requirements are real and it's legitimate to keep data that falls within them even when a user requests deletion.
The ethical obligation is to be clear about this. "Deleting your account will remove your personal data, except as required by applicable law" is an honest statement. "Your account and all associated data will be permanently deleted" followed by retaining some data for 7 years under tax compliance requirements is not.
The practical approach: identify, explicitly, which categories of data have legally mandated retention periods. Build the deletion process to delete everything not in those categories, promptly, and to anonymise rather than delete the retained data wherever possible. "Anonymised" means actually anonymised — not "we replaced your name with a random ID but can still link it back to you through billing records." If the anonymisation is reversible, it's not anonymisation; it's pseudonymisation with extra steps.
Why Email-Only Deletion Flows Fail
A pattern that unfortunately persists in mobile apps: to delete your account, you must send an email to the developer's support address, after which someone will manually process the request and confirm deletion. This pattern is particularly common in smaller apps where the deletion flow wasn't built at launch and the workaround was "we'll handle it through support."
This fails users for several reasons. It requires them to have access to the email address they used to register, which they may not. It introduces unpredictable delay between request and execution. It creates human error risk — deletion handled manually is deletion that can be missed, delayed, or partially completed. And it places the burden of a process on the user that the app should handle automatically.
Google Play's account deletion policy, updated in 2023, explicitly requires that apps offering in-app account creation also offer in-app account deletion — not email-only workarounds. The policy applies to apps that have been live long enough to have accumulated real user data, which is most production apps. The correct implementation is a deletion flow within the app that the user can initiate, confirm, and receive confirmation of without external communication.
The Shared Data Problem, Again
For connected apps like Twunein, deletion is more complex than for single-user apps, for the reasons discussed in the privacy piece. When a user deletes their account, what happens to their shared session history? What happens to the connection reference stored in their former partner's account?
The approach in Twunein: on deletion, the deleted user's personal data is erased. Their display identity in shared session records is replaced with an anonymised placeholder. Their former partner's account retains the session history in anonymised form — the activity record is preserved, but the identity of who they were listening with is no longer linked to the deleted account. This threads the needle between the deleting user's right to erasure and the remaining user's interest in their own session history.
The partner is notified that the connection has ended, without details about whether this was user-initiated deletion or account closure, because that's the deleting user's private choice. The notification is functional — it explains what changed — without being dramatic or revealing more than necessary.
The Ethics Beyond Compliance
Compliance with deletion requirements under GDPR, DPDPA, and Play Store policies is a floor, not a ceiling. It describes the minimum. The ethical standard is higher than the legal minimum, and building to the ethical standard rather than just the legal one is both the right thing to do and — practically — better for your app's long-term relationship with its users.
Users who trust that an app will honourably delete their data when they ask are users who are less afraid to engage with the app fully while they're using it. That trust is valuable and it's built through demonstrated behaviour, not just policy statements. The privacy policy that says "we respect your data rights" and the deletion flow that actually deletes your data are two different things. Both matter. Only one of them is in the user's direct experience.
At The VoBot Developers, the commitment is to build deletion that works. Not deletion that satisfies a checkbox in an app review. Not deletion that technically complies with the letter of applicable law while retaining the maximum possible data. Deletion that actually does what it says, promptly, completely, with honest communication about what's happening. That's not a complicated standard. It's just the right one.