App Store Compliance 2026: The Data Deletion Requirement Every Australian Developer Needs to Know

We have written twice recently about account deletion from the engineering side: building the public deletion page Google Play requires, and then discovering our own deletion endpoint returned a 500 error for anyone who had actually used the app.

This is the version for the person who has to make the decision rather than write the code — what the obligation actually is in Australia, what the stores enforce, and what it costs to get wrong.

There are two separate obligations, and they are not the same

This is the distinction that catches out most businesses with an app in market.

The store requirement is about the path. Apple requires that if your app lets users create an account, it must let them delete it from inside the app. Google Play requires a publicly reachable web page, declared in the Play Console, where a user can request deletion without installing anything or logging in. Both are about whether a user can ask.

The Privacy Act requirement is about the outcome. Australian Privacy Principle 11.2 requires you to destroy or de-identify personal information once you no longer need it for the purpose you collected it. That is about what actually happens to the data.

An app can fully satisfy both stores and still fail the Privacy Act. The button exists, the page is published, the review passes — and the records are still in the database. That gap is where the real risk sits, because the store checks the path and nobody checks the outcome.

What we found when we checked our own

Worth stating plainly, because it is the most useful thing in this article.

Our deletion endpoint existed. The policy page was correct and published. The store requirement was satisfied.

The endpoint returned a 500 error for any user who had actually used the app — the more history an account had, the more reliably it failed. And for accounts where it did complete, it silently left related records behind.

Two failure modes. Only one of them was visible. A user hitting the error at least knew something had gone wrong; the silent orphaning produced a success message and left the data in place.

If you have a deletion feature you have never tested with a real, heavily-used account, you do not yet know which of those two you have.

What “deletion” has to actually cover

The word does more work than people expect. A compliant erasure path has to deal with:

The account record itself. The obvious one, and usually the only one implemented.

Everything attached to it. Content the user created, uploads, messages, activity history, preferences, device tokens, session records. This is where silent orphaning happens — the parent row goes, the children remain, and nothing errors.

Copies you have made. Analytics events, error-tracking payloads, email marketing lists, CRM records, support tickets, data warehouses. If you have pushed personal information to a third party, deleting your own copy is not the end of the obligation.

Backups. You do not have to shred your backups, but you do need a defensible position — typically that backups are retained for a defined period, are not used to repopulate live systems, and expire on a schedule. Say what you do and then do it.

What you keep, and why. Some retention is legitimate — transaction records for tax, fraud-prevention signals, aggregate and genuinely de-identified analytics. Each one needs a stated reason. “We might want it later” is not one.

What the stores actually enforce

Realistically, here is what happens.

At review, the checks are procedural. Is the deletion path present and reachable? Is the URL declared in the Play Console? Does the Data safety form match what the app appears to do? Failing these gets you rejected, and rejection costs you a review cycle — days, sometimes a week, and any launch date attached to it.

After review, enforcement is complaint-driven. A user asks for deletion, nothing happens or it errors, they complain to the store or to the OAIC. That is when the gap between the path and the outcome becomes someone else’s business.

The store rejection is the cheap failure. It is annoying, it is visible, and you fix it. The expensive failure is passing review with a deletion path that does not work, and finding out when a user is already unhappy.

What it costs to get wrong

A rejected submission costs a review cycle. Budget a week of slippage and whatever that does to your launch.

A privacy complaint goes to the OAIC. Most are resolved through the complaints process rather than penalties, but it consumes real management attention and creates a documented record. Under the Privacy Act the maximum civil penalties for serious or repeated interference with privacy are substantial — for a small business the realistic risk is not the maximum penalty, it is the cost of responding, remediating and disclosing.

A breach involving data you should have deleted is the worst version, because it is entirely self-inflicted. Records you were required to destroy, still sitting in a database, exposed in an incident. Every one of those is a record you had no business holding.

The check to run this week

Not a policy review. An actual test.

1. Create an account in your production app, or use a real test account with genuine history — content, uploads, a few weeks of activity. An empty account will pass a deletion test that a real one fails.
2. Request deletion through the in-app path.
3. Confirm it completes without an error.
4. Look in the database. The account, and everything attached to it.
5. Check your third parties — analytics, email platform, CRM, error tracking.
6. Compare what remains against what your published policy says you keep.

If steps 4 to 6 have never been done, do them before your next submission rather than after.

Getting the paperwork right

Two documents have to agree with the code.

Your privacy policy should state what you collect, why, what survives deletion and for how long. Write the retention period you can actually enforce, not the cautious-sounding one. We publicly stated five years for something we only needed for three, which committed us to failing our own policy for two extra years.

Your Data safety declaration in the Play Console has to match what the app does, including what your SDKs collect on your behalf. An analytics or advertising SDK collecting device identifiers is your disclosure, not theirs.

The published document is the standard you will be measured against. Make it the truth and it costs nothing; make it aspirational and it is a liability you wrote yourself.

The short version

• The stores check that a deletion path exists. The Privacy Act cares about the outcome.
• Passing review is not evidence that deletion works.
• Test it with an account that has real history, then look in the database.
• Publish a retention period you enforce, not one that sounds careful.
• Every record you were supposed to delete is a record that can be breached.

---

Frequently asked questions

Does my app need account deletion if it has no accounts? No. The requirement applies to apps that let users create an account. Check whether any SDK you have added creates a persistent identifier on your behalf, since that affects your Data safety declaration separately.

What is the difference between the Apple and Google requirements? Apple requires deletion to be initiated from inside the app. Google requires a publicly reachable web page declared in the Play Console. Most apps need to satisfy both.

How long can we keep data after an account is deleted? Only as long as you have a genuine reason — commonly tax and transaction records. APP 11.2 requires destruction or de-identification once the original purpose is served, and your published policy is the standard you will be held to.

What happens if we fail the Data safety review? Your submission is rejected and you resubmit, typically costing a review cycle. It is the cheap failure. The expensive one is passing review with a deletion path that does not actually work.

Do we have to delete data from backups? Generally no, provided you have a defensible retention position: backups expire on a defined schedule and are not used to repopulate live systems. State it in your policy and follow it.

---

Awesome Apps builds iOS and Android apps for Australian businesses, including store submission and privacy compliance. Websites and SEO sit with Cosmos Web Tech; cloud, security and managed IT with CloudGeeks. All divisions of GTS.

This article is general information, not legal advice. For obligations specific to your business, seek advice from a qualified Australian privacy practitioner.