Privacy and deletion for an AI-built app (2026)

Who this is for

You shipped from Lovable, Bolt, Cursor, or another AI builder. People who are not you can create an account. The host is Supabase, Firebase, or a similar shop. You want App Store and Play review, or you already have a live URL and no delete path.

You are not this page if the app still lives only on a laptop, if only the founder can log in, or if you cannot take the live URL down tonight. Open the backup page if you have no restore file. Open the Supabase page if a stranger can still read another person’s row.

What the words mean

A privacy policy is a public page that names what you collect, why, who else sees it, how long you keep it, and how a person asks you to stop. Retention is how long a copy stays after the person leaves. An auth user is the sign-in record the login shop keeps — email, user id, sessions. A storage bucket is the file drawer for uploads: photos, invoices, voice notes. A processor is a shop that handles user data for you: analytics, mail, crash reports, ads. A webhook is a server ping another shop sends when something happens, such as a user deleted event.

App Review Guideline 5.1.1 is Apple’s data-collection rule. Clause (v) is the account-deletion sentence. Google Play’s Data safety form is the questionnaire on the App content page that becomes the Data safety section on your listing. Neither store treats a freeze or an “email support” loop as a delete unless you are in a highly regulated field Apple already carves out.

Apple: policy URL and in-app delete

App Review Guideline 5.1.1(i) is blunt. Every app must put a privacy policy link in the App Store Connect metadata field and inside the app where a person can find it. The policy must say what the app collects, how it collects it, and every use. It must confirm that third parties who see the data — analytics tools, ad networks, third-party SDKs, parent or related companies — give the same or equal protection. It must explain retention and deletion, and describe how a person revokes consent or asks you to delete.

App Store Connect lists Privacy Policy URL as required for iOS and macOS. Manage app privacy repeats that a privacy policy URL is required for all apps. A user privacy choices URL is optional. You enter both under App privacy. Changes to those URLs ship with the next app version. You also answer the app privacy questions that become the product-page labels. App privacy details says those answers are required to submit new apps and updates, and they must include third-party partners whose code you added.

Guideline 5.1.1(v) is the account sentence. If the app supports account creation, you must also offer account deletion within the app. Offering account deletion fills that in. Apps submitted to the App Store that support account creation must let people start deletion inside the app. Deleting an account removes it from your records, plus data tied to it that you are not legally required to keep. Put the control where people look, usually account settings. Offer to delete the entire record and the personal data with it. Extra options are fine. Only offering to deactivate or disable is not enough.

Apple is specific about friction. Apps not in highly regulated industries — the fields in Guideline 5.1.1(ix) — must not force a phone call, email, chat, or other support flow to finish the delete. You may confirm identity and intent. Making it unnecessarily hard fails review. If they must finish on a website, link straight to that page. Automatically created guest accounts still need a delete. A flow you built for one country is not enough unless everyone can use a path that meets 5.1.1(v).

Deletion does not have to be instant. If the work is manual, tell the person how long it will take and confirm when it is done. User-generated content other people can see is in scope unless a law says you must keep it. If the app uses Sign in with Apple, revoke those tokens with the Sign in with Apple REST API. If the person has an auto-renewable subscription, tell them billing continues through Apple until they cancel.

Google Play: policy, Data safety, and two delete doors

Prepare your app for review puts the privacy policy on the App content page. For apps that ask for sensitive permissions or data, you must link a privacy policy on the store listing and inside the app. Apps that target children need that pair even if they collect nothing sensitive. The URL must be live, apply to the app, and cover user privacy. You add it under Policy and programs, App content, Privacy Policy.

Provide information for the Data safety section is the form every published app fills in, including closed, open, or production testing tracks. Apps only on an internal testing track are exempt. Even an app that collects no user data must complete the form and give a privacy policy URL. The form must cover data your third-party libraries and SDKs collect. A privacy policy is required to finish the form and show Data safety on the listing. You answer whether people can request deletion of their data. The User Data policy says the Data safety section must stay accurate and, where relevant, match the privacy policy.

Account deletion requirements add a second door. If the app lets people create an account from inside the app, you must give an in-app path to delete the account and the data with it, and a web link where they can request the same delete. The web link is not optional once accounts exist. People who already uninstalled still need a way to ask. The link must load, show a clear delete path, and name the app or developer as it appears on Play. A form, a support mail, or an anchored section of the privacy policy can be that path if the delete step is prominent. If they must cancel a subscription first, say so and give a support flow.

Play’s in-app path can be a link that opens that web resource. The web resource still has to work without reinstalling the app. When you delete the account, you also delete the user data tied to it. Data you declared in Data safety is in scope. You may keep some data for security, fraud prevention, or regulatory reasons if you tell people in the retention policy. Finish requests in a reasonably quick time and check the laws that apply.

What delete must actually remove

A Delete account button that only flips a status column is a costume. Apple wants the account record and associated personal data gone, except what the law says you keep. Play wants the account and the data you said you collect gone, with the same legal carve-out. For an AI-built app the work usually sits in five places.

The auth user

Supabase’s user-management guide says you can delete users in Authentication, Users, or with the admin delete call. Deleting the sign-in row does not automatically sign the person out. The shop uses JSON Web Tokens: a signed session ticket. That ticket stays valid until it expires. A ban is not a delete. Marking the person deleted only in your own tables leaves the sign-in row intact, so they can still sign in and refresh.

The admin delete-user call needs the service-role key and must run on a server. Never put that key in the browser. The default is a hard delete. A soft-delete option removes the person from normal use but keeps a hashed id; it is not reversible. After a hard delete, sessions cascade away and refresh tokens die, so the account cannot mint new access tickets. An access ticket already in the person’s hands still works until its expiry. Keep that window short, or check the session id against the sessions table on sensitive work, because that session row is gone after delete.

Firebase Admin Auth has a matching delete user call. It returns empty on success and errors if the id is missing. Batch delete of many users at once does not fire the per-user delete handlers. If your cleanup lives in those handlers — row deletes, file deletes, processor pushes — delete one user at a time, or run the cleanup yourself. A builder that only removed the Firebase sign-in user left the database rows and file objects behind.

Rows, files, backups, and other shops

Supabase tells you to keep profile data in your own tables and point those tables at the sign-in users table with a cascade rule, so child rows die with the user. That is the row rule. If the builder created orders, messages, or uploads with a user-id column and no cascade, the admin delete leaves orphans. Search every table for that id after a test delete. The harden page is where you prove a stranger cannot read another person’s row. This page asks whether the row is gone after they leave.

Files are a separate shop. Supabase’s caution is one line: you cannot delete a user who owns objects in Storage. Delete or reassign those files first. Then delete the auth user. If the builder stored photos under a user folder, list that folder in the delete job. A file that still answers a public URL after “account deleted” is a failed test.

Backups are copies the host keeps so you can restore after a break. Apple and Play both let you keep what the law or fraud work requires, if you tell the person. They do not let you silently restore a deleted account from last night’s snapshot and call the delete done. Write the window. Write what a restore must skip.

Processors already have a copy. Apple’s policy clause names analytics tools, advertising networks, and third-party SDKs. Play’s Data safety form includes data those SDKs collect. App privacy details defines third-party partners the same way: analytics, ads, SDKs, or other vendors whose code you added. A delete that never reaches those shops is a half delete. Use each shop’s delete path, or a webhook from your delete job. Name the shops in the privacy policy. If you cannot name them, you cannot claim the policy matches the binary.

A practical checklist

Do this before the first store build, then again after every SDK you add.

1. Own a public policy URL. Company domain. Not a builder host, not a login wall, not a Google Doc that can flip to restricted. Name collect, use, share, retain, and delete.
2. Put the URL in both stores and in the app. App Store Connect App privacy. Play App content. A settings or legal link in the running app.
3. Answer Apple’s privacy questions and Play’s Data safety form, including third-party SDKs. Publish the answers. Revisit when the binary changes.
4. If the app creates accounts, ship in-app delete in settings. Apple: no support-only maze. Play: also ship a web link that works after uninstall.
5. Delete the auth user on the server with the admin call. Cascade or delete rows. Delete or reassign files first on Supabase.
6. Fan the delete out to processors. Analytics, mail, crash, ads. Confirm a test person disappears there.
7. Write retention. What you keep, why, and for how long. Tell the person in the flow and in the policy.
8. If you use Sign in with Apple, revoke the tokens. If you sell auto-renewable subscriptions, warn that Apple billing continues until they cancel.

How to test it

Create a throwaway account on the production host, not only on a preview. Upload a file. Write a row. Trigger one analytics event and one mail. Then delete from the in-app control. On Play, also delete from the web link in a private window without the app installed.

Search for that email and user id in Authentication, in every table, and in the storage bucket. Try to sign in again. Try the old session ticket if you still have one; it may work until expiry, which is why you keep that window short. Open the processor consoles and confirm the person is gone or queued. Restore last night’s backup onto a spare project and confirm the deleted person does not come back as a live login. If any layer still answers, the path is red.

Then walk the store paperwork. Open the live policy URL in a private window. Confirm it matches the SDKs in the binary. Confirm Apple’s labels and Play’s Data safety list the same data types. Confirm the Play web link loads, names your app, and shows delete without a scavenger hunt.

What to do this week

Keep the week small. You do not need a privacy lawyer to start. You need a live URL, a findable control, and a test person who is actually gone.

If the policy is still a builder page, move it today. If delete is “email us,” replace it unless you are in Apple’s regulated list. If the admin delete is missing, a person who asked to leave is still in your database. Finish the five places before the next submission.

Next steps

Publish the policy. Put the URL in both stores and in the app. Ship in-app delete, plus a Play web link if you create accounts. Delete the auth user, the rows, the files, and the processor copies. Write what you keep. Test with a throwaway account. Customers and reviewers should not be the first people who notice the button does nothing.

CodeCross is a product studio. The week after an AI-built launch is a live host, a policy you own, and a delete you can prove without the builder chat. If the path is still a hidden flag and you want a second pair of eyes, book a conversation.

FAQ

If I only deactivate the account, does that pass App Review?

No. Offering account deletion says only offering to temporarily deactivate or disable an account is insufficient. You must offer to delete the entire account record and the associated personal data you are not legally required to keep. Extra options are fine. A freeze by itself is not.

If I offer in-app delete, do I still need a web link on Google Play?

Yes, if the app creates accounts. Play’s account deletion page wants both an in-app path and a web link. People who already uninstalled still need a way to ask. The link must work without sending them back to re-download the app. Apple will accept a website only as the finish step, and only if you link straight to that page.

Does deleting the auth user in Supabase remove uploaded files?

No. Supabase will error if you try to delete an auth user who still owns Storage objects. Delete or reassign those files first. Cascade on your own tables is a separate setup. The admin delete also does not instantly kill an access ticket the person already holds. That ticket dies at expiry.

Is a privacy policy on a shared doc enough for the stores?

Not if the URL can break or hide. Apple wants a link in App Store Connect and in the app. Play wants an active URL that applies to the app. Data safety will not finish without a privacy policy. A builder host or a doc that later asks for login is a dead link waiting to happen. Put it on a name you own.

If I keep some data for fraud or tax, did I fail the delete?

Not if you say so. Apple tells you to let people know what you will and will not retain when the law requires a keep. Play says you may keep data for security, fraud prevention, or regulatory compliance if you tell people in the retention policy. Keeping everything “just in case,” with no notice, is not that carve-out.

Does a Firebase batch user delete run my cleanup functions?

No. Firebase Admin Auth says batch delete of many users does not trigger per-user delete handlers. Delete one user at a time if those handlers remove rows, files, or processor copies. Or run that cleanup in your own job and prove it on a throwaway account.