# iOS account deletion: the flow to test before App Review > Delete button, linked data, subscription and sign-in again: a concrete test plan to check your account deletion flow before you submit to App Review. Original page: [iOS account deletion: the flow to test before App Review](https://devoria.fr/en/blog/ios-account-deletion-flow-test-app-review) Author: [Mehdi Azizi](https://devoria.fr/en/mehdi-azizi) Published: 2026-10-02 Content last revised: 2026-10-09 ## A button isn't enough: you have to check what actually disappears If your app lets people create an account, Apple requires that they can start deleting it from inside the app. Simply deactivating the account doesn't meet this requirement. The flow has to be easy to find and explain what happens next. If part of it finishes on the web, the link must go straight to the relevant page. [Source: Apple on account deletion](https://developer.apple.com/support/offering-account-deletion-in-your-app). So the work doesn't stop at a red button in the settings. You need to list the data, run the deletion on the server, handle errors and check what the user sees afterward. This guide gives you a product and technical test plan. Data you're legally required to keep needs handling that fits your own business. ## Start with a data map Let's take a fictional reading journal app. It has an account, a profile, private notes and cover photos added by the user. The example below describes a plan to check, not a deletion already run on a Devoria app. - **Login identity:** how do you make the account unusable after deletion? - **Profile and notes:** which rows belong to this person, and how are they deleted? - **Stored photos:** what process removes the files and their references? - **Phone cache:** does the screen clear local data once the operation has actually succeeded? - **Third-party services:** does data linked to this account need a separate deletion? - **Data to keep:** which data, for what obligation, and how is the user told? This map keeps you from finding out later that a photo is still reachable while the user record is gone. It also gives you the objects to look for during testing. ## A clear flow in four states Here's a proposal for the fictional app, to adapt to your product's real consequences: 1. **Account settings.** A "Delete my account" entry stays accessible. 2. **Confirmation.** The screen describes the data involved and offers a cancel action that's as easy to understand as the delete action. 3. **Processing.** The button prevents duplicate requests and the interface shows the operation is in progress. 4. **Result.** A confirmed success leads to the signed-out state. A failure keeps a helpful message and a way to retry, without claiming the account is gone. If processing takes time, Apple accepts a delayed flow as long as you inform the person and confirm when it's done. The app must not suggest a deletion is complete when only the request has been recorded. The same [Apple documentation](https://developer.apple.com/support/offering-account-deletion-in-your-app) also covers reauthentication cases and exceptions for highly regulated industries. ## What to plan for with Supabase Deleting an Auth user doesn't, on its own, prove that every object in your product has been handled. Supabase notably explains that a user who owns Storage objects can't be deleted until that's resolved. The docs also note that deleting a user doesn't instantly sign out every JWT already issued: you have to account for their validity in your design. [Source: Supabase user management](https://supabase.com/docs/guides/auth/managing-user-data). So define a server-side process that verifies the requester's identity and the resources they own. Don't rely on an ID freely sent by the phone to pick which account to delete. Admin rights stay on the server, as described in the [Supabase API keys documentation](https://supabase.com/docs/guides/getting-started/api-keys). For a multi-step process, decide what a retry should do if the first step succeeded and the next one failed. For example, if the files are already removed, a new request shouldn't fail just because they're missing. That's a scenario to write before testing, not a behavior to assume. ## Account and subscription: two separate checks Someone can delete their account while an Apple subscription keeps running. Apple asks you to explain what happens to billing and to give access to subscription management. Also plan proper token revocation if you use Sign in with Apple. These points are detailed in [Apple's account deletion guidelines](https://developer.apple.com/support/offering-account-deletion-in-your-app). In your test plan, keep the account disappearing, the paid access state and subscription management separate. The [subscription or one-time purchase](https://devoria.fr/en/blog/subscription-vs-one-time-purchase-ios-app) guide helps you place this flow in your business model. ## The test plan to run on a test build Only use a test account and fake data. Write down the build, the device, the observed result and the limits of each check. 1. **Cancel.** The account and data stay accessible. 2. **Delete an account full of data.** The final state matches the announced process; the relevant data is actually removed. 3. **Cut the network.** The app doesn't show a fake success. 4. **Retry after a partial failure.** The request can succeed without touching other data. 5. **Open a second session.** Old access is handled according to the planned mechanism. 6. **Create a new account with the same email, if allowed.** Old private data doesn't come back. Add these cases to the [Devoria test checklist](https://devoria.fr/en/resources). To send builds to testers, follow the [TestFlight](https://devoria.fr/en/blog/testflight-test-iphone-app-before-submitting) guide. No error in the console doesn't replace checking the data and the flow. ## Preparing your App Review submission In your review notes, explain where the action is and how to test it. If a step depends on a service, make sure it's available during review. Don't use the notes to promise a feature that isn't in the submitted build yet. The [app rejected by Apple](https://devoria.fr/en/expertise/app-rejected-by-apple) page helps you organize a reply when an issue has already been flagged. To prepare it, the [Apple Review Kit](https://devoria.fr/en/kits/review-apple) helps you find the cited rule, what it requires, and an example fix and reply. If you're preparing your first submission, the free [diagnostic](https://devoria.fr/en/diagnostic) tells you what's left to do and sends you my Apple anti-rejection checklist, account deletion included. If Apple has already rejected your app, [book an hour with me](https://devoria.fr/en/coaching): we'll read the message together over video. ## Frequently asked questions ### Is account deletion required in an iOS app? Yes, if your app lets people create an account: Apple requires that they can start deleting it from inside the app. Simply deactivating the account doesn't meet this requirement. The flow has to be easy to find and explain what happens next. If part of it finishes on the web, the link must go straight to the relevant page. ### What should be deleted when a user deletes their account? Everything that belongs to that person, not just their user record. Make a list: login identity, profile and created content, stored files and their references, phone cache, data held by third-party services. Also note the data you must keep, for what obligation, and inform the person. Without this inventory, a photo can stay reachable while the user record is gone. ### Does Apple accept account deletion that isn't immediate? Yes. If processing takes time, Apple accepts a delayed flow as long as you inform the person and confirm when it's done. The app must not suggest the deletion is complete when only the request has been recorded. If it fails, keep a helpful message and a way to retry, without claiming the account is gone. ### What happens to the subscription when a user deletes their account? The Apple subscription can keep running after the account is deleted. Apple asks you to explain what happens to billing and to give access to subscription management. If you use Sign in with Apple, also plan proper token revocation. In your test plan, keep the account disappearing, the paid access state and subscription management separate. ### Is deleting the user in Supabase Auth enough? No, deleting an Auth user doesn't prove that every object in your product has been handled. According to the Supabase docs, a user who owns Storage objects can't be deleted until that's resolved. Deleting a user also doesn't instantly sign out every JWT already issued. Plan a server-side process that verifies the requester's identity. ### How do you test account deletion before submitting to Apple? Use a test account and fake data on a test build. Run six cases: cancel, delete an account full of data, cut the network, retry after a partial failure, open a second session, create a new account with the same email if allowed. Check the data and the flow: no error in the console isn't enough. To distribute your build, follow the [TestFlight](https://devoria.fr/en/blog/testflight-test-iphone-app-before-submitting) guide. ## Your project [Apple Review Kit](https://devoria.fr/en/kits/review-apple): The App Store review checklist I use, my Apple rejections and fixes, notes for the reviewer and two Claude Code skills that review your app. 29 €. [iOS Kit](https://devoria.fr/en/kits/ios): Build your iPhone app with Claude Code: the starter code behind my apps, skills that check its work, and the Apple Review, Screenshots and ASO kits. 129,99 €.