Чому перевірка застосунку триває так довго?

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

Ви завантажили збірку, перевірили скріншоти та спланували запуск. А потім нічого не відбувається. App Store Connect досі показує «Очікує на перевірку», або Play Console тримає ваші зміни на перевірці. Тим часом кожен день невизначеності ускладнює координацію маркетингу, підтримки клієнтів та анонсу релізу.

Найбільш неприємно те, що затримка може мати кілька можливих пояснень. Ваша заявка може просто чекати своєї черги. Рецензенту може знадобитися інформація. Ваша збірка могла взагалі не потрапити на розгляд. Або розгляд уже завершено, а публікація чекає на вас. Цей посібник пояснює, як розрізнити ці ситуації. Він зосереджений на Apple App Review, з окремим порівнянням з Google Play. Джерела перевірено 3 жовтня 2026 року.

Скільки часу має тривати перевірка застосунку?

Apple каже, що в середньому 90% подань розглядаються менш ніж за 24 години. Це корисний контекст, але це не гарантований час виконання для вашого окремого додатка. Деякі подання виходять за межі цього вікна, і статистика не дає вам часу завершення для цих винятків. Apple також попереджає, що неповні подання можуть затримати рев'ю. [1]

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

По-перше, визначте, де саме затримка

Читайте точний статус, а не перекладайте кожен жовтий індикатор як «Apple перевіряє мій застосунок». Waiting for Review означає, що подання в черзі; In Review означає, що перевірка почалася. Pending Developer Release означає, що застосунок прийнято, але все ще потребує вашої дії з випуску. Waiting for Export Compliance — це інший процес. Прийнятий елемент також може залишатися неопублікованим, якщо інший елемент у його поданні було відхилено. [2]

Перевірте версію додатка та подання разом, а не лише завантажену збірку. Скріншот списку збірок може розповісти іншу історію, ніж сторінка подання. Запишіть версію, номер збірки, час подання та поточний статус. Цей невеликий запис запобігає усуненню несправностей у старішій збірці або плутанині між поданням у TestFlight та випуском в App Store.

Рецензентам потрібно випробувати весь застосунок

Рев'юер не може оцінити функцію, до якої не може дістатися. Контрольний список Apple для подання вимагає повного доступу, активного демо-акаунта або відповідного демо-режиму, необхідного обладнання або зразкових ресурсів, а також живих серверних служб. Він також просить розробників пояснювати неочевидні функції та покупки в примітках до рев'ю. Ці вимоги роблять доступ розумним першим місцем для дослідження. [3]

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

Короткий, відтворюваний покроковий опис корисніший за рекламний текст. Наприклад: увійдіть з наданим акаунтом, відкрийте Бібліотеку, виберіть зразковий проєкт і натисніть Експорт. Включіть будь-яке очікуване обмеження та поясніть, чому воно існує. Це не купує пріоритет; це зменшує уникнуту двозначність, коли хтось дістанеться до вашого подання.

Відмова потребує відповіді, а не більшого очікування

Коли Apple відхиляє застосунок, у повідомленні пояснюється проблема та відповідна настанова. App Store Connect дозволяє відповісти та прикріпити допоміжні матеріали. Apple також зазначає, що відхилення метаданих можна вирішити та повторно подати, використовуючи ту саму збірку. Тому свіжий бінарний файл не завжди потрібен. [4]

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

Ведіть простий журнал проблем: питання рецензента, ваша відповідь, змінений ресурс або збірка та наступна необхідна дія. Це полегшує подальше листування. Це також заважає команді незалежно надсилати різні пояснення. Комунікація з перевіркою — це розмова про налагодження, а не змагання, хто надішле довшу відповідь.

Обробка збірки та TestFlight — це окремі контрольні точки

Завантажена збірка не обов'язково готова до подання. Довідник Apple щодо статусу збірки розрізняє обробку, відсутність інформації про відповідність і готовність до подання. Він також розрізняє стани TestFlight «Очікує на рев'ю» та «На бета-рев'ю» від доступності для внутрішніх тестувальників. Зовнішнє бета-тестування може вимагати рев'ю додатка TestFlight. [5]

Якщо ваша бета-версія застрягла, перевірте статус збірки, перш ніж шукати проблему в черзі перевірки App Store. Для Missing Compliance Apple наказує розробникам відповісти на питання шифрування або надати відповідну документацію. Деякі збірки можуть заявити застосовне звільнення через свою конфігурацію, але ви повинні відповідати точно, а не змінювати налаштування лише для обходу підказки. [6]

Схвалено не завжди означає негайно доступно

Робочий процес публікації Apple розділяє вибір збірки, встановлення доступності, подання, вирішення проблем рев'ю та розповсюдження. Він каже, що схвалений додаток може зайняти до 24 годин, щоб стати доступним. Ви також вибираєте, чи реліз ручний, автоматичний або поетапний. Перевірте ці налаштування, перш ніж описувати схвалену версію як «все ще на рев'ю». [7]

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

Google Play має інше вікно перевірки

Не застосовуйте часові рамки Apple до Google Play. Google каже, що відгуки можуть зайняти від кількох годин до семи днів, а у виняткових випадках довше. Огляд публікації також попереджає, що подання іншої зміни, поки зміни на розгляді, може відсунути додаток назад у чергу перевірки. Повторні дрібні правки можуть, отже, завадити передбачуваному випуску. [9]

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

Практичний приклад: діагностика перед повторною подачею

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

Якщо застосунок просто чекає і доступ працює, заміна збірки не пропонує доведеного рішення. Якщо рецензент повідомляє про помилку входу, виправлення доступу усуває реальну перешкоду. Якщо статус — Pending Developer Release, правильна дія — випуск, а не повторне подання. Один і той самий проміжок часу може вимагати трьох абсолютно різних відповідей. Ось чому діагностика стану передує вибору засобу.

Коли слід звертатися до Apple?

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

Прискорений розгляд — це окремий запит. Apple наводить приклади, як-от критичне виправлення помилки або випуск, пов'язаний із подією, з якою ви безпосередньо пов'язані. Поясніть фактичні обставини та вплив; звичайне маркетингове нетерпіння — це не те саме. Запит на прискорення не слід подавати як гарантований ярлик. [1]

Плануйте запуск з урахуванням невизначеності

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

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

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

Нарешті, відрізняйте докази від історій. Довгі очікування інших розробників можуть бути реальними, але вони не доводять, чому ваш додаток затримується. Ні цитовані рекомендації Apple, ні Google не встановлюють універсального пояснення, як-от затримка через додатки, створені ШІ. Корисне питання не «яка чутка це пояснює?», а «в якому стані моє подання, і чи є дія, яку я можу реально вжити?»

Пов'язане

Блог · Кейси · Free ASO tools · Продукти · Конфіденційність та умови · AsoTheory