Відхилення в App Store: 9 перевірок перед поданням

Типові відхилення в App Store спричиняють речі, які можна перевірити самостійно до подання на перевірку: збої чи шаблонний контент (Guideline 2.1), відсутність робочого демо-акаунта, метадані, що не відповідають застосунку (2.3), прогалини в приватності (5.1), немає видалення акаунта в застосунку, соцлогін без рівноцінної альтернативи (4.8), цифрові товари поза In-App Purchase (3.1.1), а також «порожні» чи дубльовані застосунки (4.2, 4.3).

Кожен пункт прив’язаний до свого номера в App Review Guidelines і звірений із версією, яку Apple позначає як оновлену 16 жовтня 2026 року. Правила змінюються — перш ніж на щось покладатися, перечитайте актуальний текст.

Чек-лист коротко

Чому відхилили мій застосунок? Почніть із Guideline 2.1

Найімовірніше, через щось із розділу App Completeness. На сторінці App Review Apple пише, що в середньому понад 40% невирішених проблем стосуються Guideline 2.1 — збої, шаблонний контент, неповна інформація. Тож перші два пункти перевіряйте найретельніше.

1. Збої, шаблонний контент і биті посилання (2.1)

Apple чекає фінальну версію, перевірену на пристрої, без шаблонного тексту й тимчасового контенту, і відхиляє білди, які падають або мають очевидні технічні проблеми.

• Встановіть саме той білд, який подаєте, на фізичний iPhone з актуальною iOS і пройдіть усі основні сценарії: реєстрацію, покупку, ключову функцію. Якщо застосунок працює на iPad — перевірте й там.
• Пошукайте в застосунку й лістингу (сторінці застосунку в сторі) lorem, TODO, test та екрани «скоро буде».
• Натисніть кожне посилання. Робоче посилання на підтримку й на політику приватності Apple вимагає від усіх застосунків.

2. Демо-акаунт, живий бекенд і нотатки для перевірки (2.1)

Якщо в застосунку є вхід, рецензенту потрібен робочий акаунт. Інструкція Apple про повну інформацію для перевірки тут конкретна:

• Логін і пароль мають працювати на момент подання; якщо до початку перевірки вони перестануть діяти, застосунок можуть відхилити.
• Якщо ви продаєте автоподовжувані підписки, дайте акаунт із простроченою підпискою, щоб рецензент побачив увесь шлях покупки.
• Якщо для входу потрібен одноразовий код, заздалегідь вкажіть його в нотатках.
• Тримайте бекенд увімкненим під час перевірки. Перелік Before You Submit в App Review Guidelines вимагає, щоб бекенд-сервіси були робочими й доступними під час перевірки. Тестового сервера, вимкненого на вихідні, може вистачити для відхилення.

За 2.1(b) кожна налаштована вбудована покупка має бути видимою й робочою; якщо якоїсь у застосунку не знайти, поясніть причину в нотатках.

3. Метадані й скриншоти, що відповідають застосунку (2.3)

Опис, скриншоти й прев’ю мають відображати основний досвід застосунку. Найчастіше спотикаються на двох підпунктах:

• 2.3.3 — скриншоти показують застосунок у роботі, а не лише титульну картинку, екран входу чи заставку.
• 2.3.10 — жодних назв, іконок чи зображень інших мобільних платформ. Одного бейджа «Get it on Google Play» на скриншоті достатньо.

Другий підпункт, разом із десятихвилинною перевіркою всіх локалізацій, ми розбирали у статті відхилення через Guideline 2.3.10.

Приватність: пункти, що потребують найбільше підготовки

4. Політика приватності й тексти дозволів (5.1.1)

За 5.1.1(i) посилання на політику приватності має бути і в App Store Connect, і в самому застосунку, на видному місці. Політика має пояснювати, які дані ви збираєте і як використовуєте, підтверджувати, що треті сторони, з якими ви ними ділитеся, захищають їх так само, і описувати зберігання, видалення та відкликання згоди.

За 5.1.1(ii) кожен запит дозволу — камера, геолокація, контакти, фото — потребує purpose string, що чітко пояснює навіщо. На сторінці App Review Apple радить додати приклад того, як використовуватимуться дані. Також перевірте, що відповіді в розділі App Privacy в App Store Connect збігаються з тим, що збирають застосунок і його SDK.

5. Трекінг і App Tracking Transparency (5.1.2)

Поєднання даних вашого застосунку з даними інших компаній для реклами чи вимірювання реклами, а також передача їх брокерам даних — це трекінг. Guideline 5.1.2(i) вимагає спершу отримати дозвіл через запит App Tracking Transparency.

• З’ясуйте, які SDK (реклама, атрибуція, аналітика) трекають. Apple вважає вас відповідальними за них так само, як за ваш власний код.
• Показуйте запит ATT із purpose string до того, як почнеться будь-який трекінг.
• Нічого не блокуйте й не винагороджуйте залежно від відповіді. У FAQ Apple прямо сказано: обмежувати функціональність через відмову від трекінгу не можна.

6. Видалення акаунта в застосунку (5.1.1(v))

Якщо в застосунку можна створити акаунт, Guideline 5.1.1(v) вимагає, щоб його можна було й видалити, не виходячи із застосунку. Роз’яснення Apple щодо видалення акаунта додають те, на чому зазвичай відхиляють:

• Деактивації недостатньо — має видалятися акаунт разом з особистими даними.
• Опцію має бути легко знайти, зазвичай у налаштуваннях акаунта.
• Поза жорстко регульованими галузями не можна змушувати людей телефонувати, писати листа чи в чат підтримки, щоб завершити видалення.
• Автоматично створені «гостьові» акаунти теж рахуються.
• Вебсторінка підходить, якщо посилання веде прямо туди, де видалення завершується.

Вхід, платежі й чи вважається це застосунком

7. Соцлогіну потрібен рівноцінний варіант (4.8)

Це формулювання часто переказують з пам’яті, а воно змінилося. Guideline 4.8 діє, коли застосунок використовує сторонній чи соціальний вхід (Google, Facebook, X та інші) для основного акаунта користувача. У такому разі застосунок мусить запропонувати ще й інший сервіс входу як рівноцінний варіант («as an equivalent option», за текстом Apple), який:

• обмежує збір даних іменем та email користувача;
• дає змогу приховати свою email-адресу;
• не збирає взаємодії із застосунком для реклами без згоди.

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

8. Цифрові товари — через In-App Purchase (3.1.1)

Платні функції чи контент, якими користуються в застосунку, — підписки, преміум-контент, повна версія, ігрова валюта — мають продаватися через In-App Purchase. Ліцензійні ключі, QR-коди та інші саморобні способи розблокування заборонені, а для покупок, які можна відновити, потрібна кнопка відновлення.

Працює і навпаки: фізичні товари й послуги, які споживають поза застосунком, — доставка, поїздки — мають оплачуватися іншими способами (3.1.3(e)). Посилання на інші способи оплати залежать від країни стору: станом на жовтень 2026 на вітрині США вони дозволені, деінде — лише зі спеціальним entitlement або взагалі ні, тож перевірте 3.1.1(a) для кожного ринку.

9. Достатньо функцій — і лише один застосунок (4.2, 4.3)

Guideline 4.2 очікує функцій, контенту й інтерфейсу, які роблять застосунок чимось більшим за перепакований сайт; веб-в’ю вашого сайту чи добірка посилань навряд чи пройде. За 4.2.6 застосунки, згенеровані з комерційних шаблонів, відхиляють, якщо їх подає не сам власник контенту.

Guideline 4.3 — про спам: жодних окремих bundle ID для по суті того самого застосунку (по одному на місто чи на клієнта) і жодних застосунків, які не відрізняються від уже поширених. Apple називає перенасичені категорії — серед них знайомства, ліхтарики, шпалери, — де новому застосунку потрібен помітно інший досвід.

Перевірка, що відбувається ще до App Review: privacy manifest

Це не правило з Guidelines, але воно зупиняє подання ще раніше. З 1 травня 2024 року App Store Connect не приймає застосунки, які використовують так звані required reason API, не вказавши причину в privacy manifest (PrivacyInfo.xcprivacy). У переліку SDK, які мають містити privacy manifest, Apple називає сам Flutter і плагіни на кшталт shared_preferences_ios, path_provider та url_launcher. У старішому Flutter-застосунку оновіть ці пакети перед завантаженням білда.

Якщо вас відхилили: як відповідати

1. Прочитайте повідомлення в App Store Connect. У ньому вказано номер правила. Багато розробників досі називають це місце Resolution Center; у довідці Apple тепер це відповідь App Review. 2. Якщо рецензент щось не так зрозумів, відповідайте там і конкретно: яка функція, який крок, де її знайти. Можна також попросити дзвінок; за словами Apple, дзвінки зазвичай відбуваються протягом трьох–п’яти робочих днів. 3. Якщо проблема справжня — виправте й подайте знову, описавши в нотатках, що змінилося. 4. Апелюйте, лише якщо впевнені, що застосунок відповідає правилам. Апеляція до App Review Board подається після відповіді на відхилення: одна апеляція на відхилений застосунок, із посиланням на правило й поясненням пункт за пунктом, як застосунок йому відповідає. Не апелюйте щодо того, що вже виправили й подали повторно. 5. Для застосунку, який уже в сторі, оновлення з виправленням багів не затримують через інші порушення, якщо вони не стосуються закону чи безпеки, — прийміть пропозицію Bug Fix Submission в App Store Connect, а решту виправте наступного разу.

Застрягли на перевірці чи починаєте з нуля?

DriveCode розробляє застосунки для iOS та Android, Flutter-first. Якщо застосунок готовий, але раз за разом повертається з відхиленнями — часто тому, що команда, яка його робила, пішла, — ми підхоплюємо застосунок: спершу акаунти й ключі переходять на вас, потім виправлення, яких вимагає Apple. Якщо плануєте новий застосунок, ми створюємо застосунки для iOS та Android на Flutter і подаємо їх із вашого власного акаунта розробника; наші власні застосунки є в обох сторах, тож цей список — частина кожного нашого релізу. Якщо розробник перестав відповідати, почніть зі статті що повернути найперше.

Що часто питають

Скільки триває App Review? Станом на жовтень 2026 Apple пише, що зазвичай перевіряє щонайменше 50% подань менш ніж за 24 години, а 90% — менш ніж за 48 (App Review). Неповні подання й повторні відхилення через те саме правило розглядають довше.

Чи обов’язковий Sign in with Apple? Не за назвою. Якщо ви пропонуєте сторонній вхід для основного акаунта, потрібен рівноцінний варіант, що відповідає трьом умовам із 4.8; Sign in with Apple — звичний спосіб їх виконати.

Чи можна пояснити проблему замість того, щоб виправляти? Якщо рецензент не так зрозумів застосунок — так, відповідайте в App Store Connect конкретно. Якщо проблема справжня, пояснення результату не змінить.

Чи має Apple власний чек-лист? Так: розділ «Before You Submit» на початку App Review Guidelines і «Avoiding common issues» на сторінці App Review. Ця стаття зіставляє найчастіші пункти з правилами, що за ними стоять.