Демо-акаунт для перевірки App Store: як налаштувати вхід для рецензента, щоб пройти перевірку (2026)

Якщо будь-яка частина вашого застосунку доступна лише після входу, ваш демо-акаунт для перевірки App Store має спрацювати з першої спроби Apple. Правила App Review вимагають надати дані демо-акаунта або повнофункціональний демо-режим, а також щоб ваш бекенд працював під час перевірки. На практиці це означає окремий акаунт, термін дії якого не спливає, що вже містить реалістичні дані, відкриває всі платні й рольові функції та не потребує коду входу, який бачите лише ви. У цьому посібнику розповідаємо, як створити такий акаунт, як написати до нього нотатки і з чим стикалися інші розробники, коли вхід не спрацьовував.

Що Apple вимагає від демо-акаунта для перевірки App Store?

Apple вимагає робочі ім’я користувача й пароль демо-акаунта щоразу, коли застосунок потребує входу. Їх вказують у розділі App Review Information в App Store Connect, і термін дії акаунта не повинен спливати. Пункт 2.1(a) також вимагає, щоб ваш бекенд працював під час перевірки.

Пункт 2.1(a) звучить так: «надайте дані демо-акаунта (і увімкніть свій бекенд!), якщо ваш застосунок має вхід». Довідник з інформації про версію платформи в App Store Connect додає, що «демо-акаунт використовується під час процесу App Review, і термін його дії не повинен спливати», що «дані додаткових акаунтів слід вказати в полі Notes» і що Notes «може містити до 4000 байтів». Поля Sign-in required застосовуються, «якщо для використання вашого застосунку потрібен вхід».

Довідкова сторінка Apple про повну перевірку конкретніша: «Облікові дані, які втратили чинність або змінилися до початку перевірки, можуть призвести до відхилення подання». Якщо у вашому застосунку кілька типів акаунтів, наприклад адміністратор і звичайний користувач, додайте дані для кожного з них у Notes. Якщо ви продаєте автоматично поновлювані підписки, «надайте демо-акаунт із простроченою підпискою, щоб можна було перевірити весь процес покупки».

Як налаштувати демо-акаунт для App Review?

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

1. Створіть окремий продакшн-акаунт, наприклад appreview@yourdomain.com. Не використовуйте особистий чи QA-акаунт, який хтось може змінити.
2. Виключіть його з усіх завдань очищення: ротації паролів, видалення неактивних акаунтів, завершення пробних періодів і антифрод-правил.
3. Наповніть його реалістичним контентом, щоб жоден екран не був порожнім. Рецензенти оцінюють повноту за тим, що бачать.
4. Налаштуйте стан підписки відповідно до вказівок Apple. Якщо ви продаєте підписки, в акаунта має бути прострочена підписка, щоб відображалися пейвол і процес покупки.
5. Призначте йому регіон, де працюють усі ваші функції, або опишіть регіональні відмінності в Notes.
6. Увійдіть на чистому пристрої саме в тій релізній збірці, яку подаєте, і пройдіть кожну функцію, згадану в Notes.
7. Більше не чіпайте пароль, доки перевірка не завершиться.

Що робити, якщо застосунок використовує коди входу, SMS OTP, magic links або SSO?

Якщо для входу потрібен одноразовий код, перед поданням напишіть у Notes фіксований код для акаунта перевірки. Apple попереджає, що без нього «для продовження перевірки може знадобитися дзвінок», а такі дзвінки «зазвичай відбуваються протягом трьох–п’яти робочих днів».

Для magic links, що надходять електронною поштою, або одноразових кодів через SMS налаштуйте акаунт перевірки так, щоб він приймав фіксований код або пароль, і вкажіть цей код у Notes. Якщо ви використовуєте сторонній сервіс єдиного входу (SSO), App Store Connect просить також «вказати дані демо-акаунта для нього».

Якщо ви не можете надати демо-акаунт із юридичних міркувань або з міркувань безпеки, що типово для банківських, медичних та інших регульованих застосунків, пункт 2.1(a) дозволяє використати «вбудований демо-режим замість демо-акаунта за попереднього схвалення Apple». Такий демо-режим має показувати «всі функції та можливості вашого застосунку» на демонстраційних даних, а не урізану екскурсію.

Які акаунти варто надати App Review?

Надайте App Review по одному акаунту без терміну дії для кожного типу акаунта у вашому застосунку, а також усе, що потрібно, щоб пройти коди, пейволи та вимоги до обладнання. У таблиці показано, що і куди вказувати в кожному випадку.

Що написати в нотатках для App Review до демо-акаунта?

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

CONCEPT: Team habit tracker. Coaches create groups; members log daily habits.
Pro subscription (monthly/annual) unlocks progress reports.

ACCOUNTS (non-expiring, pre-filled with 30 days of data):
- Member: review-member@example.com (in the username/password fields)
- Coach: review-coach@example.com / password: [shared here]
- Deletion test: review-delete@example.com / password: [shared here]

LOGIN CODE: The app emails a 6-digit code. For these review
accounts, enter 246810.

SUBSCRIPTION: The member account's subscription has expired.
Tap Reports > Upgrade to see the full purchase flow.

WHERE TO LOOK: Groups tab (coach) > Create group. Today tab (member)
> Log habit. Settings > Account > Delete account.

REGIONS: All features work the same in every storefront.
TESTED ON: iPhone 15 (iOS 26), iPad Air (iPadOS 26).
SERVICES: Supabase (auth/data), RevenueCat (subscriptions).

Пишіть коротко й по суті. Для оновлень довідкова сторінка Apple радить «описати, що змінилося і де рецензенти можуть знайти значний новий контент або функції». Пункт 2.3.1(a) вимагає, щоб нові функції були «описані конкретно», і попереджає, що «загальні описи буде відхилено». Формулювання правил змінюються кілька разів на рік, тож перед поданням прочитайте наш огляд змін у правилах App Review за жовтень 2026 року.

Чому вхід у демо-акаунт не спрацьовує під час перевірки? Реальні випадки

У публічних звітах вхід у демо-акаунт зазвичай не спрацьовує з однієї з двох причин: другий фактор, який рецензент не може отримати, або акаунт, що працює в розробника, але видає помилку на пристрої Apple. Дві теми на форумах Apple Developer ілюструють обидва випадки.

Двофакторна автентифікація через SMS для ключової функції. Розробник на форумах Apple Developer написав, що їхній застосунок «постійно відхиляють», бо редагування профілю вимагало коду, надісланого SMS на американський мобільний номер. Вони пояснили: «оскільки ми не маємо номера мобільного телефону рецензента... рецензент не отримує код підтвердження». Інші розробники в темі описали рішення: один змінив бекенд, «щоб тестовий акаунт завжди отримував той самий код 2FA», і вказав його в нотатках, інший прив’язав продакшн-акаунт до віртуального номера телефону й надав Apple доступ до нього.

Облікові дані, які працюють скрізь, крім перевірки. Розробник на React Native і Expo, що використовує автентифікацію Supabase через email і пароль, повідомив про повторні відхилення. На скриншоті Apple був правильний email і помилка «Invalid login credentials», хоча вхід працював з пристроїв розробника, у Postman і в клієнті Supabase, без MFA, обмеження частоти запитів чи геоблокування. Підтвердженої причини в темі немає. Розробник думав додати демо-режим, але згідно з пунктом 2.1(a) цей шлях потребує попереднього схвалення Apple.

Що об’єднує ці випадки: значення має лише досвід рецензента. Фіксований код у Notes вирішує проблему з другим фактором. Для проблеми «у мене все працює» потрібно увійти в релізній збірці, на чистому пристрої, з продакшн-бекендом, а потім не чіпати акаунт.

Що перевірити перед поданням із демо-акаунтом?

Перед поданням переконайтеся, що вхід у демо-акаунт працює в релізній збірці, усі ролі й коди вказано в Notes і ніщо не призведе до завершення терміну дії, ротації пароля чи видалення акаунта під час перевірки.

• Вхід у релізну збірку на чистому пристрої виконано протягом останньої години
• Бекенд, провайдер автентифікації та сервіс email або SMS працюють і не обмежують частоту запитів для акаунта
• Акаунт виключено із завдань, що встановлюють термін дії, очищають дані та змінюють паролі
• Для кожної ролі є окремий вхід у Notes
• Стан підписки дає змогу побачити процес покупки
• Підготовлено окремий акаунт для тесту видалення
• Код входу або спосіб його обійти вказано в Notes
• Контактний номер телефону вказано в міжнародному форматі зі знаком плюс (+), і на дзвінок хтось відповість

За даними сторінки App Review від Apple, «у середньому понад 40% невирішених проблем пов’язані з пунктом 2.1: App Completeness», який охоплює й неповну інформацію. Непрацюючий вхід у демо-акаунт — одна з найпростіших таких проблем, яку можна запобігти. Щоб перевірити решту збірки, скористайтеся нашим планом тестування релізної збірки для відхилень за пунктом 2.1.

Що робити, якщо App Review однаково не може увійти?

Якщо App Review не може увійти, виправте акаунт, знову протестуйте його в релізній збірці, оновіть App Review Information і відповідайте в App Store Connect, точно вказавши, що ви змінили. App Review Information «можна редагувати будь-коли».

Уважно прочитайте повідомлення про відхилення. Часто причина — проста невідповідність: змінився пароль, завершилася сесія або рецензент перебував у регіоні, який блокує ваш бекенд. Наш посібник про те, як перетворити повідомлення перевірки на виправлення, допоможе з відповіддю. Якщо хочете передати налаштування перевірки іншим, наш сервіс подання в App Store підготує перевірку й опрацює з вами відгуки про відхилення за $599 для обох магазинів (внески за акаунти розробника сплачуються окремо).