# Видалення акаунта в iOS-застосунку: що перевірити до Apple

> Кнопка видалення, пов'язані дані, підписка й повторний вхід: конкретний план, щоб перевірити цей сценарій до відправки в App Review.

Оригінальна сторінка: [Видалення акаунта в iOS-застосунку: що перевірити до Apple](https://devoria.fr/uk/blog/vydalennia-akaunta-ios-zastosunok-perevirka-apple)
Автор: [Mehdi Azizi](https://devoria.fr/uk/mehdi-azizi)
Опубліковано: 2026-10-02
Останнє оновлення змісту: 2026-10-09


## Самої кнопки мало: треба перевірити, що саме зникає

Якщо в твоєму застосунку можна створити акаунт, Apple вимагає, щоб людина могла запустити його видалення прямо із застосунку. Звичайна деактивація цю вимогу не виконує. Сценарій має бути легко знайти, і він має пояснювати наслідки. Якщо частина процесу завершується в вебі, посилання має вести одразу на потрібну сторінку. [Джерело: видалення акаунта за версією Apple](https://developer.apple.com/support/offering-account-deletion-in-your-app).

Тож робота не закінчується червоною кнопкою в налаштуваннях. Треба скласти перелік даних, виконати видалення на сервері, обробити помилки й перевірити, що користувач бачить після цього. Цей гайд пропонує продуктовий і технічний план тестування. Дані, які ти зобов'язаний зберігати, потребують обробки, що відповідає саме твоїй діяльності.

## Почни з карти даних

Візьмімо вигаданий застосунок-щоденник прочитаних книжок. У ньому є акаунт, профіль, приватні нотатки й обкладинки, які додає користувач. Приклад нижче описує план для перевірки, а не видалення, яке вже виконано в застосунку Devoria.

- **Ідентичність для входу:** як зробити акаунт непридатним до використання після видалення?
- **Профіль і нотатки:** які рядки належать цій людині і як їх видаляють?
- **Збережені фото:** яка обробка прибирає файли та посилання на них?
- **Кеш на телефоні:** чи стирає екран локальні дані, коли операція справді завершилася?
- **Сторонні сервіси:** чи потребують дані, пов'язані з цим акаунтом, окремого видалення?
- **Дані, які треба зберегти:** які саме, через яке зобов'язання і як про це повідомлено користувача?

Ця карта вбереже тебе від ситуації, коли вже потім з'ясовується, що фото досі доступне, хоча запис користувача зник. А ще вона дає тобі список об'єктів, які треба шукати під час тестів.

## Зрозумілий сценарій у чотирьох станах

Ось варіант для вигаданого застосунку. Адаптуй його до реальних наслідків у своєму продукті:

1. **Налаштування акаунта.** Пункт «Видалити акаунт» завжди доступний.
2. **Підтвердження.** Екран описує, яких даних це стосується, і пропонує дію скасування, таку ж зрозумілу, як і дія видалення.
3. **Обробка.** Кнопка не дає надіслати запит двічі, а інтерфейс показує, що операція триває.
4. **Результат.** Підтверджений успіх відкриває стан «не в акаунті». Помилка залишає корисне повідомлення й можливість спробувати знову, не вдаючи, що акаунт зник.

Якщо обробка займає час, Apple приймає відкладений сценарій за умови, що людину поінформовано і їй підтверджують завершення. Застосунок не має створювати враження, що видалення завершено, коли лише зареєстровано запит. Та сама [документація Apple](https://developer.apple.com/support/offering-account-deletion-in-your-app) також описує випадки повторної автентифікації та винятки для жорстко регульованих сфер.

## Що варто передбачити із Supabase

Видалення користувача в Auth саме по собі не доводить, що всі об'єкти твого продукту оброблено. Supabase, зокрема, пояснює, що користувача, якому належать об'єкти в Storage, не можна видалити, доки цю ситуацію не розв'язано. Документація також попереджає, що видалення користувача не розлогінює миттєво всі вже видані JWT: їхній строк дії треба врахувати в архітектурі. [Джерело: керування користувачами в Supabase](https://supabase.com/docs/guides/auth/managing-user-data).

Тож зроби серверну обробку, яка перевіряє особу того, хто надсилає запит, і ресурси, що йому належать. Не покладайся на ідентифікатор, який телефон довільно надсилає, щоб вибрати акаунт для видалення. Адміністративні права залишаються на сервері, як описано в [документації про ключі Supabase](https://supabase.com/docs/guides/getting-started/api-keys).

Якщо обробка має кілька кроків, вирішіть заздалегідь, що має робити повторна спроба, якщо перший крок вдався, а наступний ні. Наприклад, якщо файли вже прибрано, новий запит не повинен падати лише тому, що їх немає. Це сценарій, який треба описати до тесту, а не поведінка, яку можна просто припустити.

## Акаунт і підписка: дві окремі перевірки

Людина може видалити акаунт, а підписка Apple продовжиться. Apple вимагає пояснити, що буде з оплатою, і дати доступ до керування підпискою. Також передбач належне відкликання токенів, якщо використовуєш Sign in with Apple. Ці моменти детально описано в [рекомендаціях Apple щодо видалення](https://developer.apple.com/support/offering-account-deletion-in-your-app).

Тож у плані тестування розділи зникнення акаунта, стан платного доступу й керування підпискою. Гайд [підписка чи разова покупка](https://devoria.fr/uk/blog/pidpyska-chy-razova-pokupka-ios-zastosunok) допоможе вписати цей сценарій у твою бізнес-модель.

## План перевірки на тестовій збірці

Використовуй лише тестовий акаунт і вигадані дані. Записуй збірку, пристрій, отриманий результат і обмеження кожної перевірки.

1. **Скасувати.** Акаунт і дані залишаються доступними.
2. **Видалити заповнений акаунт.** Кінцевий стан відповідає заявленій обробці, відповідні дані справді прибрано.
3. **Вимкнути мережу.** Застосунок не показує фальшивий успіх.
4. **Повторити після часткової помилки.** Запит може завершитися, не зачепивши інших даних.
5. **Відкрити другу сесію.** Старі доступи обробляються відповідно до передбаченого механізму.
6. **Створити акаунт з тією ж адресою знову, якщо це дозволено.** Старі приватні дані не з'являються.

Додай ці випадки до [чекліста тестування Devoria](https://devoria.fr/uk/resources). Щоб роздати їх тестувальникам, скористайся гайдом про [TestFlight](https://devoria.fr/uk/blog/testflight-testuvannya-zastosunku-iphone). Відсутність помилок у консолі не замінює перевірки даних і сценарію.

## Підготовка до відправки в App Review

У нотатках для рев'ю поясни, де знаходиться ця дія і як її протестувати. Якщо якийсь крок залежить від сервісу, переконайся, що він доступний під час рев'ю. Не використовуй нотатки, щоб обіцяти функцію, якої ще немає у відправленій збірці.

Сторінка [застосунок відхилено Apple](https://devoria.fr/uk/expertise/app-rejected-by-apple) допоможе структурувати відповідь, коли проблему вже виявлено. Щоб її підготувати, [Apple Review Kit](https://devoria.fr/uk/kits/review-apple) допоможе знайти згадане правило, зрозуміти, чого воно вимагає, і дасть приклад виправлення та відповіді.

Якщо готуєш першу відправку, [безкоштовна діагностика](https://devoria.fr/uk/diagnostic) покаже, що ще залишилося зробити, і надішле тобі мій чекліст проти відхилень Apple, включно з видаленням акаунта. Якщо Apple уже відхилила твій застосунок, [забронюй годину зі мною](https://devoria.fr/uk/coaching): разом розберемо повідомлення по відеозв'язку.

## Поширені запитання

### Чи обов'язкове видалення акаунта в iOS-застосунку?

Так, якщо в застосунку можна створити акаунт: Apple вимагає, щоб людина могла запустити його видалення прямо із застосунку. Звичайна деактивація цю вимогу не виконує. Сценарій має бути легко знайти, і він має пояснювати наслідки. Якщо частина процесу завершується в вебі, посилання має вести одразу на потрібну сторінку.

### Що треба видалити, коли користувач видаляє акаунт?

Усе, що належить людині, а не лише її запис користувача. Склади список: ідентичність для входу, профіль і створений контент, збережені файли й посилання на них, кеш на телефоні, дані в сторонніх сервісах. Також запиши, які дані треба зберегти й через яке зобов'язання, і повідом про це людину. Без такого переліку фото може залишитися доступним, хоча запис користувача зник.

### Чи приймає Apple видалення акаунта, яке відбувається не одразу?

Так. Якщо обробка займає час, Apple приймає відкладений сценарій за умови, що людину поінформовано і їй підтверджують завершення. Застосунок не має створювати враження, що видалення завершено, коли лише зареєстровано запит. У разі помилки залиш корисне повідомлення й можливість спробувати знову, не вдаючи, що акаунт зник.

### Що відбувається з підпискою, коли користувач видаляє акаунт?

Підписка Apple може продовжуватися після видалення акаунта. Apple вимагає пояснити, що буде з оплатою, і дати доступ до керування підпискою. Якщо використовуєш Sign in with Apple, також передбач належне відкликання токенів. У плані тестування розділи зникнення акаунта, стан платного доступу й керування підпискою.

### Чи достатньо видалити користувача в Supabase Auth?

Ні, видалення користувача в Auth не доводить, що всі об'єкти твого продукту оброблено. За документацією Supabase, користувача, якому належать об'єкти в Storage, не можна видалити, доки це не розв'язано. Крім того, видалення користувача не розлогінює миттєво всі вже видані JWT. Передбач серверну обробку, яка перевіряє особу того, хто надсилає запит.

### Як протестувати видалення акаунта перед відправкою в Apple?

Використовуй тестовий акаунт і вигадані дані на тестовій збірці. Пройди шість випадків: скасувати, видалити заповнений акаунт, вимкнути мережу, повторити після часткової помилки, відкрити другу сесію, створити акаунт з тією ж адресою знову, якщо це дозволено. Перевіряй дані й сценарій: відсутності помилок у консолі недостатньо. Щоб роздати збірку, скористайся гайдом про [TestFlight](https://devoria.fr/uk/blog/testflight-testuvannya-zastosunku-iphone).


## Твій проєкт

[Apple Review Kit](https://devoria.fr/uk/kits/review-apple): Чекліст для review App Store, яким я користуюся, мої виправлені відмови Apple, нотатки для тестувальника і два skills Claude Code, що перевіряють твій застосунок. 29 €.

[iOS Kit](https://devoria.fr/uk/kits/ios): Створи застосунок для iPhone з Claude Code: стартовий код моїх застосунків, skills, що перевіряють його роботу, а також Apple Review Kit, App Store Screenshots Kit і ASO Kit. 129,99 €.