# Прискорена перевірка App Store: як подати запит до Apple

> Apple називає два випадки: критичний баг у вже опублікованій версії або реліз, прив'язаний до події. Як подати запит, що написати і що буде далі.

Оригінальна сторінка: [Прискорена перевірка App Store: як подати запит до Apple](https://devoria.fr/uk/blog/app-store-expedited-review-request)
Автор: [Mehdi Azizi](https://devoria.fr/uk/mehdi-azizi)
Опубліковано: 2026-11-06
Останнє оновлення змісту: 2026-11-06


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

Мої застосунки Solys, TradaZen і Nolera зроблені на Expo. Коли баг сидить у JavaScript-коді, виправлення йде віддаленим оновленням, без App Review. Тож прискорена перевірка потрібна мені лише для нативного білда, і це перше питання, яке варто собі поставити, перш ніж її просити. Цей гайд спирається на [сторінку довідки Apple про прискорену перевірку](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/), яку я перечитав 6 листопада 2026 року.

## Що називає Apple, а що не пройде

Apple говорить про виняткові обставини й просить залишати запити для справжніх термінових випадків. Її [сторінка App Review](https://developer.apple.com/distribute/app-review/) наводить два приклади і те, що потрібно надати для кожного. Три відхилені рядки в таблиці: це моє прочитання цих сторінок, а не список Apple.

| Причина                              | У Apple             | Що надати або що зрозуміти                       |
| ------------------------------------ | ------------------- | ------------------------------------------------ |
| Критичний баг в опублікованій версії | Наведено як приклад | Кроки відтворення, поточна версія                |
| Реліз, прив'язаний до події          | Наведено як приклад | Подія, її дата, зв'язок між застосунком і подією |
| Перша публікація запізнюється        | Ні, на мою думку    | Для Apple тут немає нічого термінового           |
| Маркетингова дата без події          | Ні, на мою думку    | Кампанія не є подією, пов'язаною із застосунком  |
| Чекаєш довше, ніж зазвичай           | Ні, на мою думку    | Звичайний термін не є терміновим випадком        |

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

## Процедура у три кроки

1. **Надішли версію в App Store Connect.** Прискорити можна лише вже надіслану версію. Якщо якісь функції вимагають входу, вкажи демо-акаунт у розділі App Review Information.
2. **Заповни поле Notes під час надсилання.** Для критичного бага опиши виправлений баг і як його відтворити в поточній версії. Для події вкажи її назву, дату і що пов'язує з нею твій застосунок.
3. **Надішли форму Request an Expedited App Review**, яка доступна зі сторінки довідки Apple після входу в акаунт розробника. Там обираєш потрібний застосунок і платформу, а потім надсилаєш.

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

> Кнопка Reply to App Review в App Store Connect не призначена для запиту прискореної перевірки. [Сторінка контактів App Review](https://developer.apple.com/help/app-review/after-submitting-for-review/contact-app-review/) залишає її для листування щодо поточної версії на перевірці; для прискореної перевірки й для апеляції є окремі форми.

## Що написати: два шаблони

App Review читає англійською. Ось два тексти, які я тримаю напоготові: адаптуй їх у Notes і у формі, якщо там є вільне поле. Вони вміщаються в п'ять рядків, бо рев'юер має зрозуміти терміновість, не відкриваючи застосунок.

**Критичний баг в опублікованій версії:**

> Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build.

**Реліз, прив'язаний до події:**

> This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST.

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

## Перш ніж просити, перевір, чи воно тобі потрібно

Apple просить залишати це для справжніх термінових випадків. Три питання й одна пастка перед надсиланням форми.

**Чи можна випустити виправлення без перевірки?** В Expo віддалене оновлення замінює JavaScript-код у вже встановлених застосунках без нового білда. Саме так я випускаю свої виправлення. Але воно не охоплює ні нативний код, ні дозволи, ні нативні залежності: для них потрібні білд і перевірка. І його вміст має залишатися в межах того, що Apple вже схвалила, як нагадує [огляд EAS Update](https://docs.expo.dev/eas-update/introduction/): віддалене оновлення не змінює призначення застосунку. Гайд про [поступове розгортання оновлення iOS](https://devoria.fr/uk/blog/onovlennia-ios-postupovyi-vypusk-app-store) детально пояснює, що яким шляхом іде.

**Чи очікування справді ненормальне?** Apple каже, що зазвичай перевіряє щонайменше 50 % версій менш ніж за 24 години і 90 % менш ніж за 48 годин. Якщо твоя версія [чекає на перевірку](https://devoria.fr/uk/blog/waiting-for-review-app-store-connect-statuses) один день, ти в межах звичайного [терміну перевірки App Store](https://devoria.fr/uk/blog/skilky-tryvaie-perevirka-app-store-app-review). [Сторінка про статус перевірки](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/) також нагадує, що подовжує перевірку: перший застосунок без історії, документи на перевірку, регульована тематика.

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

**І головне: не відкликай версію, щоб надіслати її знову.** Відкликана версія виходить із черги й починає з нуля. Якщо Apple ставить тобі питання під час перевірки, відповідай в App Store Connect замість повторного надсилання, як пояснює гайд про [відповідь App Review у Resolution Center](https://devoria.fr/uk/blog/resolution-center-apple-reply-app-review-rejection).

## Якщо Apple відмовить у прискоренні

Ти зберігаєш своє місце в черзі: відмова у прискоренні ніяк не впливає на поточну перевірку. Щоб не опинитися в цій ситуації знову:

- **Плануй релізи.** Для події Apple радить обрати запланований реліз в App Store Connect: версію перевіряють заздалегідь, а виходить вона в потрібну дату. [Варіант релізу версії](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) налаштовується на сторінці версії, у розділі App Store Version Release.
- **Надсилай рано.** Версія, готова за тиждень до події, залишає час на звичайну перевірку і навіть на виправлення після відмови.
- **Тримай канал без перевірки для JavaScript.** В Expo саме це перетворює критичний баг на виправлення за кілька хвилин.

Мої шаблони нотаток для рев'юера, мій чекліст перед надсиланням і відповіді на найчастіші відмови зібрані в [Review Kit](https://devoria.fr/uk/kits/app-review). А якщо хочеш знати, чого бракує твоїй версії перед надсиланням, [безкоштовна діагностика](https://devoria.fr/uk/diagnostic) тобі це скаже і надішле мій чекліст проти відмов Apple. Усі етапи публікації описані в гайді [як опублікувати застосунок в App Store](https://devoria.fr/uk/expertise/publish-an-app-on-the-app-store).

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

### Скільки триває прискорена перевірка App Store?

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

### Чи можна попросити прискорену перевірку для першого застосунку?

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

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

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

### Чи треба відкликати версію, перш ніж просити прискорення?

Ні, навпаки. Прискорити можна лише вже надіслану версію, а відкликана версія втрачає місце в черзі. Надішли версію, заповни Notes, потім надішли форму.

### Де знайти форму прискореної перевірки?

На сайті Apple для розробників, після входу в акаунт: сторінка довідки про прискорену перевірку веде до неї через посилання Request an Expedited App Review. Там обираєш потрібний застосунок і платформу.

### Чи гарантує прискорена перевірка, що застосунок схвалять?

Ні. Вона змінює лише місце в черзі. Версія має відповідати App Review Guidelines, як і будь-яка інша, і відмова цілком можлива.

### Чи можна виправити баг без App Review?

В Expo або React Native віддалене оновлення замінює JavaScript-код без нового білда й без перевірки. Нативний код, дозволи й нативні залежності завжди потребують білда, надісланого в Apple.


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

[Review Kit](https://devoria.fr/uk/kits/app-review): Мій чекліст для перевірки в App Store, виправлені відмови Apple, чекліст для Google Play і три скіли для Claude Code. 2 499 ₴.

[iOS & Android Kit](https://devoria.fr/uk/kits/ios): Створи свій застосунок для iPhone і Android з Claude Code: стартовий код моїх застосунків, шлях до публікації в сторах і всі кіти. 4 999 ₴.

[Діагностика: що відділяє тебе від твого застосунку для iPhone](https://devoria.fr/uk/diagnostic): 7 запитань, 60 секунд: ти дізнаєшся, що насправді заважає тобі опублікувати застосунок для iPhone, отримаєш свій шлях у 4 кроки і кіт, який тобі підходить.