App Store rejection: Guideline 5.1.1(v), account deletion

What Apple requires

The deletion must be initiated and completed from within the app. It must delete the account and the associated personal data — not disable it, not mark it inactive, not queue a support ticket.

It must be reasonably discoverable. Buried six levels deep behind an unlabelled menu gets rejected. Settings, then Account, then a clearly labelled destructive action is the pattern reviewers expect.

Google Play has a related but distinct requirement: deletion must be available in-app and also from a publicly reachable web URL. If you ship to both stores, you need both.

The part people get wrong

Deletion has to cascade. If your users table row is gone but their content, memberships and uploaded files remain, you have not deleted their data and you are also likely in breach of your own privacy policy.

Do it in a transaction, ordered by foreign key dependency, and keep the list current as your schema grows. This is the single most common source of orphaned rows in a young product.

await db.transaction(async (tx) => {
  await tx.delete(sessions).where(eq(sessions.userId, userId));
  await tx.delete(entitlements).where(eq(entitlements.userId, userId));
  await tx.delete(memberships).where(eq(memberships.userId, userId));
  await tx.delete(items).where(eq(items.ownerId, userId));
  await tx.delete(users).where(eq(users.id, userId));
});

Subscriptions do not cancel themselves

Deleting an account does not cancel an active App Store or Play subscription — Apple and Google own that relationship, and you cannot cancel it on the user's behalf.

Tell the user this during the deletion flow, with a link to manage their subscription. Otherwise they will be billed for an account that no longer exists, and that becomes a one-star review and a chargeback.