# Guideline 5.1.1: як виправити відмову App Store

> Guideline 5.1.1 Data Collection and Storage: політика конфіденційності, дозволи, акаунт. Що вимагає правило і 3 реальні відмови моїх застосунків.

Оригінальна сторінка: [Guideline 5.1.1: як виправити відмову App Store](https://devoria.fr/uk/blog/guideline-5-1-1-app-store-rejection-fix)
Автор: [Mehdi Azizi](https://devoria.fr/uk/mehdi-azizi)
Опубліковано: 2026-10-06
Останнє оновлення змісту: 2026-10-06


Guideline 5.1.1 це правило Apple про збір і зберігання даних. У всіх трьох моїх відмовах із цієї групи причина зводилася до одного з двох розходжень: **те, що застосунок робив із даними, не збігалося з тим, що було задекларовано**, або запит дозволу підштовхував користувача сказати «так».

Ця стаття лише про це правило: його пункти, що я перевіряю перед відправкою і що виправляти, на прикладі трьох відмов, які я отримав на власних застосунках. Загальну картину всіх причин дивись у статті [чому Apple відхиляє застосунок](https://devoria.fr/uk/blog/vidmova-apple-app-store-prychyny).

## Що таке guideline 5.1.1?

Guideline 5.1.1, «Data Collection and Storage», визначає, що має виконувати застосунок, щойно він торкається персональних даних: повна політика конфіденційності, згода до початку збору, чесні запити дозволів і акаунт, який можна видалити. Вона стосується всіх застосунків, навіть тих, що майже нічого не збирають.

Офіційний текст є в [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#data-collection-and-storage), розділ 5 «Legal», частина 5.1 «Privacy». Повідомлення Apple часто називає конкретний пункт у дужках: 5.1.1(i), 5.1.1(iv), 5.1.1(v). **Саме цей пункт підказує, де шукати.**

## П'ять пунктів 5.1.1, які варто знати насамперед

| Пункт                        | Що вимагає Apple            | Типова відмова           |
| ---------------------------- | --------------------------- | ------------------------ |
| 5.1.1(i) Privacy Policies    | Повна політика з посиланням | Відсутня або неповна     |
| 5.1.1(ii) Permission         | Згода до збору              | Розмитий текст дозволу   |
| 5.1.1(iii) Data Minimization | Лише потрібні дані          | Повний доступ до фото    |
| 5.1.1(iv) Access             | Не підштовхувати погодитися | Екран, що тисне на згоду |
| 5.1.1(v) Account Sign-In     | Без нав'язаного акаунта     | Обов'язковий вхід        |

Три уточнення. Посилання на політику конфіденційності має бути і в App Store Connect, і в застосунку. Вона пояснює, які дані збираються, як і навіщо, підтверджує, що треті сторони, які їх отримують, забезпечують такий самий захист, і розповідає, як відкликати згоду або видалити свої дані. Платна функція не може залежати від доступу до даних, у якому користувач має право відмовити. І акаунт, створений у застосунку, має видалятися з самого застосунку.

У правилі є й інші пункти, від (vi) до (x), про окремі випадки, як-от регульовані галузі чи збирання баз персональних даних.

## Три речі, які я звіряю перед відправкою

Інструкції рев'юера в мене немає. Ось що я сам звіряю перед кожною відправкою, бо мої відмови виникали саме через розбіжність між цими елементами:

- **що каже політика онлайн**, за URL, вказаним в App Store Connect;
- **що застосунок робить насправді**, екран за екраном, включно з кожним запитом дозволу;
- **що задекларовано на сторінці застосунку**, у розділі про конфіденційність ([App Privacy Details](https://developer.apple.com/app-store/app-privacy-details/)).

Ще я тестую кожен екран дозволу, закриваючи застосунок і запускаючи його знову. Саме цю причину я знайшов у своїй другій відмові для Nolera.

## Три відмови 5.1.1, які я отримав, і їхня справжня причина

### Clic: онлайн висіла стара версія політики

Clic перетворює продукт на готові до публікації слайди за допомогою ШІ. 16 вересня 2026 року Apple відхиляє застосунок, посилаючись на 5.1.1(i) і 5.1.2(i). Екран згоди на ШІ в застосунку був. Проблема була поза ним: політика конфіденційності на сайті була старою версією. Нова існувала, але її не опублікували.

**Виправлення**: опублікував повну політику, додав короткий підсумок англійською для рев'юера, оновив нотатки для рев'ю. Нового білду я не робив: відправив ту саму заявку повторно.

**Висновок**: Apple читає те, що опубліковано, а не те, що лежить у твоєму репозиторії. У день відправки відкрий URL своєї політики й пошукай назву кожного стороннього сервісу, яким користується застосунок.

### Nolera: кнопка «Allow» перед системним запитом

Nolera це мій застосунок-гардероб. 17 вересня 2026 року після рев'ю на iPad Air Apple посилається на 5.1.1(iv). Перед запитом доступу до камери застосунок показував пояснювальний екран із кнопкою «Allow the camera».

Правила дизайну Apple тут чіткі. Власний екран перед системним запитом має мати [лише одну кнопку](https://developer.apple.com/design/human-interface-guidelines/privacy), яка відкриває цей запит. Apple радить слово на кшталт «Continue» або «Next», а не «Allow»: кнопка, схожа на системну, підштовхує потім натиснути справжню «Allow», навіть якщо людина цього не хотіла.

Це правило стосується екранів перед системним запитом: камера, мікрофон, геолокація, контакти, календар, відстеження. Виняток один: згода, якої вимагає закон.

**Виправлення**: кнопка тепер називається «Continue», у всіх 8 мовах застосунку.

**Висновок**: екран, що готує до дозволу, пояснює. Він не вирішує за користувача.

### Nolera, друга відмова: екран «камеру заборонено» з'являвся до запиту

Після повторної відправки Nolera відхиляють удруге 22 вересня 2026 року, знову за 5.1.1(iv), цього разу на iPad Pro 11 дюймів. Apple вказує на дві речі: перехід у Settings до запиту доступу та екран, з якого можна було вийти, так і не побачивши запиту.

Причина, яку я знайшов: сценарій, який я не протестував. Екран зйомки показував панель «камеру заборонено» з посиланням на Settings і запасним варіантом щоразу, коли доступу не було. Навіть якщо його ще ніколи не запитували. У звичайному сценарії пояснювальний екран ішов першим, і все було гаразд. Але якщо закрити застосунок посередині й запустити знову, ти потрапляв просто на зйомку, не побачивши системного запиту.

**Виправлення**: поки iOS ще може поставити питання, екран сам викликає системний запит. Панель «камеру заборонено» з'являється лише після справжньої відмови. Для цього знадобився новий білд, бо рев'юер тестує вбудований код.

**Висновок**: «ніколи не запитували» і «відмовлено» це два різні стани. Тестуй кожен екран дозволу, повертаючись на нього після закриття застосунку, а не лише в порядку сценарію.

## 5.1.1 і ШІ: що додає 5.1.2(i)

Для Clic Apple, крім 5.1.1, послалася на [5.1.2(i)](https://devoria.fr/uk/blog/guideline-5-1-2-third-party-ai-att-data-sharing). Це правило вимагає чітко вказувати, де персональні дані передаються третім сторонам, і прямо згадує сторонній ШІ («third-party AI»). Також воно вимагає явного дозволу до передачі.

Моя практика після цієї відмови: три узгоджені між собою речі.

- Екран згоди в застосунку перед першою відправкою даних, який каже, якому сервісу і які дані йдуть.
- Та сама інформація в онлайн-політиці конфіденційності.
- Та сама інформація в деклараціях конфіденційності на сторінці застосунку.

Що саме має містити політика, я розписав у статті [політика конфіденційності застосунку](https://devoria.fr/uk/blog/privacy-policy-ios-app-guide).

## Що відповісти Apple після відмови 5.1.1

Листування ведеться в розділі App Review твого застосунку в App Store Connect. Офіційна процедура, як [відповісти App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/), така сама, як і для інших правил. Пиши англійською, стримано: що було не так, що змінилося, як це перевірити. Ось шаблон, яким я користуюся (заміни номер білду й виправлення на свої):

```text
Hello,

Thank you for your review.

Issue: the custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,
```

Буває два випадки:

- **Причина онлайн** (політика, сторінка підтримки, декларації на сторінці застосунку): виправляєш, відповідаєш, і та сама заявка може піти знову без нового білду.
- **Причина в застосунку** (екран, кнопка, порядок запитів): потрібен новий білд. Віддаленого оновлення недостатньо, як я пояснюю в гайді про [guideline 2.1](https://devoria.fr/uk/blog/guideline-2-1-app-store-vidmova).

## Чекліст 5.1.1 перед відправкою

- URL твоєї політики конфіденційності відкривається, і онлайн висить остання версія.
- Політика називає кожен сторонній сервіс, що отримує дані, включно з ШІ. Це моє правило, суворіше за текст Apple.
- Декларації конфіденційності на сторінці застосунку кажуть те саме, що й політика та [privacy manifest](https://devoria.fr/uk/blog/itms-91053-missing-api-declaration-expo) білду.
- Кожен текст дозволу пояснює використання одним точним реченням.
- Жоден дозвіл не запитується під час запуску, якщо застосунок може працювати без нього. Та сама логіка для фонових режимів: жодного задекларованого режиму без функції, яка ним користується.
- Власний екран перед запитом має лише одну кнопку, «Continue», що відкриває системний запит.
- Той, хто відмовляє в дозволі, може продовжити іншим способом або розуміє, що втрачає.
- Екран «доступ заборонено» з'являється лише після справжньої відмови. Ти протестував це, закривши й знову запустивши застосунок.
- Застосунком можна користуватися без акаунта, коли акаунт не є необхідним.
- Акаунт, створений у застосунку, можна видалити з застосунку: рецепт у статті [видалення акаунта в iOS](https://devoria.fr/uk/blog/vydalennia-akaunta-ios-zastosunok-perevirka-apple).
- Усе протестовано й на iPad: обидві мої відмови 5.1.1 для Nolera виявили саме на iPad.

## Виправ відмову з тим, хто вже її отримував

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

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

Ніхто не може гарантувати, що Apple прийме твій застосунок. Що я можу, так це допомогти тобі уникнути відмов 5.1.1, за які я вже заплатив цілим циклом рев'ю.

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

### Що означає «Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage»?

Це повна назва правила в повідомленні Apple. Вона вказує на проблему з персональними даними: неповна політика конфіденційності, надто наполегливий запит дозволу або акаунт, який неможливо видалити. Пункт у дужках, наприклад 5.1.1(iv), уточнює, яка саме.

### Чи потрібен новий білд після відмови 5.1.1?

Не завжди. Якщо причина онлайн, як-от неоновлена політика конфіденційності, ти виправляєш сторінку, відповідаєш Apple, і заявка йде знову без нового білду. Якщо причина в екрані чи кнопці застосунку, потрібен новий білд.

### Чи можна показати пояснювальний екран перед запитом дозволу?

Так, Apple це дозволяє, коли це справді корисно. Тоді на екрані лише одна кнопка, що відкриває системний запит, зі словом на кшталт «Continue» або «Next». Без кнопки «Allow», без кнопки закрити чи пропустити, крім випадку згоди, якої вимагає закон.

### Мій застосунок використовує зовнішній ШІ: що треба декларувати?

Guideline 5.1.2(i) вимагає вказати, де дані передаються третім сторонам, включно з ШІ, і заздалегідь отримати явний дозвіл. Я застосовую це в трьох місцях: екран згоди в застосунку, онлайн-політика конфіденційності та декларації конфіденційності на сторінці застосунку. Для Clic Apple послалася на це правило разом із 5.1.1.

### Чи обов'язковий акаунт, щоб відповідати 5.1.1?

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


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

[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 €.