WebView App Rejected Under Guideline 5.1.1(v): Account Deletion for Website Accounts

Guideline 5.1.1(v): does a WebView app need in-app account deletion?

Yes. If people can create an account in your WebView app, Guideline 5.1.1(v) requires that they can also start deleting it in the app. It doesn't matter that the account technically lives on your website, in Supabase or in Firebase: once the sign-up page appears inside your web view, the app supports account creation.

The rule is one sentence of 5.1.1(v):

If your app supports account creation, you must also offer account deletion within the app.

Apple's support page Offering account deletion in your app closes the usual loophole: apps that send people to the default browser to register still need in-app deletion, and Apple adds that linking out for registration is a poor experience under Guideline 4. The page also asks you to delete the entire account record with its personal data – offering only deactivation is "insufficient" – and to keep people informed about timelines, purchases and data you must retain.

This article covers the WebView-specific part: where the option goes in a web-based account area, how the request reaches your backend and how you show it to App Review. For the full rule set, including regulated industries, see our Guideline 5.1.1(v) account deletion guide. If your rejection also mentions login walls or purpose strings, start with the 5.1.1 privacy basics for WebView apps.

Five ways website-based apps fail the deletion check

• "Email us to delete your account." The website has offered this for years, and the app inherits it. Outside highly regulated industries, Apple doesn't accept support flows as the deletion method.
• The option exists on the web but not in app mode. App detection hides the website's navigation – and with it the account menu that contained Delete Account.
• A link that opens Safari. Your app's web view keeps its own cookies, and Safari doesn't share them. The reviewer lands on a login screen instead of the deletion page.
• A button that doesn't delete. A generated "Delete account" button that only signs the user out, or removes a profile row while the login survives, fails the "entire account record" requirement.
• A flow that breaks for the review account. A password re-entry the reviewer can't complete, a code sent to your own inbox or a server function that only works in staging.

AI-generated apps are prone to the last two whenever nobody has tested what the button does on the server – see our pillar article on AI-built apps and App Review.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Where to put Delete Account in a web-based account area

Apple wants the option "easy to find" and notes that it is typically "included in the app's account settings". In a WebView app, the account settings are usually a web page – which is fine, as long as the app shows it.

Label it plainly – "Delete account", not "Manage data" – and style it as a destructive action. Check the iPad layout too, where collapsed or hover-only menus can hide it.

What the Delete Account button has to trigger

1. Delete, don't deactivate. Remove the login, the user record and personal content such as uploads and posts. If the law requires you to keep invoices, say what you keep.
2. Explain timing. If deletion runs as a background job, say how long it takes and confirm when it is complete.
3. Handle subscriptions. For App Store subscriptions, Apple's instruction is to notify subscribers that "billing will continue through Apple" and to ask them to cancel before they go on. Subscriptions from your own web checkout, such as Stripe, are yours to cancel as part of the deletion – see our Guideline 3.1.2 guide for the subscription rules.
4. Revoke Sign in with Apple. Apple says apps that support it "should use the Sign in with Apple REST API to revoke user tokens". If your app runs Sign in with Apple on the website, that sign-in uses a Services ID. Send https://appleid.apple.com/auth/revoke the same client_id the sign-in used – the Services ID for web sign-in, the App ID for native sign-in. Our article on Guideline 4.8 for WebView apps explains when Sign in with Apple is required in the first place.
5. End the session in the app. Clear the session cookie and local storage in the web view, so the next screen is a clean start rather than a half-signed-in dashboard.

Building the delete endpoint on Supabase, Firebase or your own API

Deletion runs on your server, never with admin credentials in the browser. Here is how that looks on common backends.

Supabase

Deleting an auth user takes supabase.auth.admin.deleteUser() with the service_role key, and the Supabase docs are clear: "This function should only be called on a server. Never expose your service_role key in the browser." A typical setup is an Edge Function that verifies the caller's JWT, deletes the user's rows (or relies on ON DELETE CASCADE foreign keys), removes their Storage files and then deletes the auth user. The order matters, because Supabase won't delete a user who still owns objects in Storage. Deletion also doesn't sign anyone out – an issued JWT stays valid until it expires – so end the session in the app immediately.

Firebase

The client SDK's deleteUser() comes with a condition: "To delete a user, the user must have signed in recently." Otherwise you reauthenticate first with reauthenticateWithCredential(). Deleting the Auth user leaves your Firestore, Realtime Database and Cloud Storage data in place; the official Delete User Data extension removes data keyed on the user ID, or you write a function with the Admin SDK that cleans up first and deletes the user last.

Your own API or a builder's backend

Create one authenticated endpoint, such as DELETE /api/account, that checks the session, removes the account and its content (or anonymizes it beyond recovery), cancels web subscriptions and queues clean-up in connected tools: email marketing, CRM, analytics with user IDs and push providers. If an AI builder generated your backend, read what it produced and check that the auth user is deleted, not only the profile.

How to show App Review where deletion lives

Apple's rejection text tells you what to do if the option already exists: reply in App Store Connect and identify where to find it. Make that effortless:

• Write the exact path in the Notes under App Review Information, for example "Sign in with the demo account → Profile → Account settings → Delete account".
• Attach a screenshot of the account page taken in the app – not in a desktop browser – or a short screen recording of the whole flow.
• Provide a spare account. Reviewers may really delete the demo account. List a second one and recreate the main one before every submission.
• Test the path in the review build on iPhone and iPad, with the demo account's role and permissions.

If App Review still can't find the option, reply with the path again and ask which step failed. If you're sure the flow complies, you can appeal to the App Review Board – one appeal per rejected submission – or book a 30-minute App Review appointment through Meet with Apple.

Making deletion reviewable with WebViewGold and appsubmitter.io

WebViewGold, the website-to-app solution built by our team, helps keep the deletion flow inside your app and sign-in within the rules:

• An optional native navigation footer or sidebar can link straight to your account page, so Delete Account stays reachable even when the website menu is hidden.
• The Reset App API – a reset:// link – clears cookies and cached data, a clean way to end the session after a successful deletion.
• Your external link settings decide which domains open in Safari – keep your account and deletion pages off that list, so users stay signed in.
• Reauthentication that stays compliant. If deletion asks users to sign in again, Sign in with Apple pages (appleid.apple.com) are detected automatically. Google sign-in must not run in an embedded web view – Google's OAuth policy forbids it. Use ASWebAuthenticationSession or Google's native sign-in SDK (custom code in the Xcode project), or let users confirm with email and password or Sign in with Apple. Sending Google login to Safari satisfies Google but can draw a Guideline 4 objection from Apple.

No tool can promise an approval, and the server-side deletion stays your code. appsubmitter.io adds the review side: our App Specialists check the deletion path on the build you submit, write review notes with demo and spare accounts, update your App Privacy details and handle the conversation with App Review. Book a free consultation call to go through your flow, or book the iOS package. Code changes such as a new delete endpoint aren't included; we discuss and quote them upfront.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) regarding Guideline 5.1.1(v).

[App name] now offers account deletion inside the app:

1. Sign in with the demo account: [email] / [password]
2. Tap [Profile] > [Account settings] > "Delete account".
3. The confirmation screen explains what is deleted, what we keep for legal reasons ([e.g. invoices]) and how long deletion takes ([immediately / within X days]).
4. After confirmation, our server deletes the account and associated personal data, and the app returns to the signed-out start screen.

Additional details:
- The deletion page opens inside the app, where the user is already signed in.
- [If applicable] Sign in with Apple tokens are revoked through the Sign in with Apple REST API.
- [If applicable] Users with an active App Store subscription are told that billing continues through Apple and can manage it before continuing.

Because deletion is permanent, a spare demo account is listed in the review notes: [email] / [password]. A screenshot of the account page is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

• Delete Account is visible in the account or settings area while the app hides the website navigation.
• The option deletes the login, the user record and personal content – not only the session or a profile row.
• Deletion runs server-side; no service role or admin key ships in front-end code.
• Supabase: Storage objects go before the auth user. Firebase: recent sign-in is handled and user data cleaned up.
• Subscribers are told that App Store billing continues through Apple; web subscriptions are canceled by you.
• Sign in with Apple tokens are revoked with the client ID used at sign-in.
• After deletion, the app clears cookies and local storage and shows a signed-out screen.
• Review notes contain the exact path, a demo account, a spare account and a screenshot.
• If you use WebViewGold, your account pages are not on the list of domains opened in Safari.

Frequently asked questions

Sources and further reading

• Apple – App Store Review Guidelines, 5.1.1(v) Account Sign-In
• Apple – Offering account deletion in your app
• Apple Developer Documentation – Sign in with Apple REST API: Revoke tokens
• Supabase – JavaScript reference: auth.admin.deleteUser()
• Supabase – User management: deleting users
• Firebase – Manage users on the web: delete a user
• Firebase Extensions – Delete User Data
• Apple – App Review: appeals and appointments

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.