GDPR Right to Be Forgotten: A SwiftUI Erasure Flow

The GDPR right to be forgotten is a legal request, not a settings toggle, so your app needs an honest flow that actually erases a user’s data rather than hiding it. In practice that means a clear in-app request, a truthful summary of what will be deleted, and real server-side erasure, with only the narrow data the law lets you keep retained. Apple’s own rules point the same way, so a single well-built flow satisfies both. The screens are fastest to start from a free VP0 design, and they pair naturally with a GDPR-compliant SwiftUI login.

What the right to be forgotten requires

Article 17 of the GDPR gives a person the right to ask you to erase their personal data, and obliges you to do so without undue delay in most circumstances. The UK regulator’s guidance on the right to erasure frames the same duty in practical terms: when a valid request comes in, delete the data unless a specific exception applies. For an app, the takeaway is concrete: the user must be able to make the request easily, and the deletion must be real, not a status flag that leaves the personal data sitting in your database.

That reframes the feature. It is not a UI nicety; it is a request you are legally required to honor, so the flow has to connect to genuine backend erasure.

The App Store rule that aligns with it

You do not have to choose between the law and the platform here, because they agree. Apple’s App Store Review Guidelines require that apps which support account creation also let users delete their account from within the app, not merely deactivate it or be sent to a support email. That requirement maps directly onto the GDPR right to erasure, so building one honest in-app deletion flow satisfies both at once. Burying deletion behind a web form or a support address risks a rejection and a privacy complaint together.

Designing the flow without dark patterns

The erasure flow has a small, honest shape: make deletion easy to find in account settings, state plainly what will be removed and what little must be retained, ask for a clear confirmation, then perform real deletion and confirm completion truthfully. The anti-pattern to avoid is the one covered in account-deletion dark-pattern alternatives: a flow that nudges users toward deactivation while dressing it as deletion, or hides the option three layers deep.

Settings -> Account -> Delete account
  -> "This permanently deletes your profile, posts, and messages."
  -> "We keep [named records] only where the law requires it."
  -> Confirm -> server erases -> honest confirmation screen

Distinguish deactivation from deletion if you offer both, and never let one masquerade as the other.

Make the deletion real on the backend

The screen is the easy half; the deletion is the substance. When the user confirms, your server must erase the personal data across your stores and any processors that hold it, keeping only the narrow, legally required records. A soft delete that flips an is_deleted flag does not satisfy Article 17. The same server-truth discipline that governs a cookie consent banner applies here: the user-facing control has to correspond to a real change in what data you hold.

Key takeaways

For the GDPR right to be forgotten, build an in-app erasure flow that is easy to find, honest about what it deletes, and backed by real server-side deletion rather than a hidden flag. Article 17 makes the request a legal obligation, and Apple’s in-app account-deletion requirement aligns with it, so one well-built flow covers both. Avoid dark patterns: do not disguise deactivation as deletion or bury the option, and confirm completion truthfully. Retain only the narrow data a legal basis requires, and name it. Start the request and confirmation screens from a free, $0 VP0 design, and put your effort into making the backend deletion genuine, because that is the part the law actually cares about.

Frequently asked questions

What is the GDPR right to be forgotten in an app?

It is the user’s right under Article 17 of the GDPR to ask you to erase their personal data, and your obligation to actually do it in most cases. In an app that means a clear request flow, an honest summary of what gets deleted, and real server-side erasure rather than a soft delete that just hides the account. You can keep narrowly defined data the law requires you to retain, but the default is genuine deletion, confirmed truthfully to the user.

Is in-app account deletion required on the App Store?

Yes. Apple requires apps that let users create an account to also let them delete it from within the app, not just deactivate it or email support. That requirement lines up with the GDPR right to erasure, so a single well-built deletion flow satisfies both. Hiding deletion behind a support email or a web-only form risks both an App Store rejection and a GDPR complaint, which is why the in-app flow is the right place to build it.

How is erasure different from deactivating an account?

Deactivation hides the account but keeps the data; erasure removes the personal data itself. The right to be forgotten is about the second one. A flow that quietly deactivates while presenting itself as deletion is a dark pattern and does not satisfy the law. Offer deactivation as a separate, clearly labeled option if you want it, but make true deletion available and honest about what it removes.

What data can I keep after an erasure request?

Only what a legal basis lets you retain, such as records you must keep for tax, fraud, or legal-claim reasons, and you should tell the user what that is. Everything else tied to their identity should go. Designing the flow to delete by default and retain only the narrow, named exceptions is what keeps it compliant, rather than keeping data because deleting it is inconvenient.

Can VP0 give me a free template for the deletion screen?

Yes. VP0 is a free iOS design library where each screen has an AI-readable source page, so you copy a link and Claude Code or Cursor builds the erasure request and confirmation screens in SwiftUI. You own the code and wire the real deletion to your backend. The design gives you an honest, easy-to-find flow to start from at no cost.