СпонсорУвійтиПодати
Блог

Apple описала, як працює App Review. Ось що я б змінив перед надсиланням

Від Justinas Rolando, розробника MacPip

Коротка відповідь

У нотатці Hello Developer від листопад 2026 р. Apple вказала розробникам на нові довідкові статті App Review. У них письмово зафіксовано те, що більшість із нас дізналася з відхилень: Apple прагне перевіряти 50% надсилань менш ніж за 24 год, а 90% менш ніж за 48 год; демо-логіни мають працювати, коли починається перевірка; на запитання треба відповідати в App Store Connect, а не надсилати повторно; відхилення, що починається з «Bug Fix Submissions:», дає змогу випустити виправлення й розв'язати проблему наступного разу; понад половина скриншотів має показувати застосунок у роботі; і кожен дозвіл має мати власну зрозумілу purpose string. Лише одна стаття прямо згадує Mac, але кожне правило стосується надсилання до Mac App Store.

Майже все, що я знаю про App Review, я дізнався з листів про відхилення. Тому, коли в Hello Developer від листопад 2026 р. написали «Browse new App Review help articles», я прочитав їх усі. Тепер вони зібрані в одному місці, App Review Help, і прямо кажуть багато з того, що раніше було фольклором.

Ось що в них важливо для Mac-застосунку і що я б змінив перед наступним надсиланням.

Для кого це

App Review дивиться лише на те, що проходить через App Store Connect: Mac App Store, TestFlight, In-App Purchases та решту. Якщо ви продаєте Mac-застосунок зі свого сайту з Developer ID, в Apple його ніхто не перевіряє. Він проходить нотаризацію, це автоматична перевірка. Тож якщо ви поширюєте застосунок лише напряму, просто проглянте текст і збережіть його на день, коли додасте версію для Mac App Store.

Скільки триває перевірка

Стаття про статус перевірки дає власну ціль Apple: перевіряти щонайменше 50% надсилань менш ніж за 24 год і 90% менш ніж за 48 год. У ній також сказано, що сповільнює перевірку: обмежена історія перевірок, потрібні Apple документи, складні або нові проблеми.

Що б я зробив: планував би день запуску з двома вільними днями перед ним, а для першого застосунку із запасом більше. І надсилав би заздалегідь із ручним випуском, щоб обрати хвилину виходу.

Поле Notes: саме тут виграють перевірки

Стаття про повну перевірку пряма: «Неповні надсилання буде відхилено.» Важливі деталі:

Що б я зробив: писав би поле Notes як коротку інструкцію для незнайомої людини. Куди клацнути спершу, яким обліковим записом користуватися і що робить значок у рядку меню, якщо в застосунку немає вікна. Останнє дуже по-маківському.

Якщо відхилили

Це те, що я хотів би мати в письмовому вигляді багато років тому.

Чотири правила з числами

Статті про настанови короткі й конкретні.

Єдиний рядок про Mac

Лише стаття про сумісні пристрої називає Mac. У ній сказано, що сумісні застосунки для iPhone та iPad можуть працювати без змін на Mac з Apple silicon, а застосунки, які спираються на дотики, неможливі з клавіатурою, погано підходять для macOS. Якщо ви робите застосунок для iPad, перевірте, чи він з'являється в Mac App Store, і вимкніть це, якщо він погано працює з клавіатурою та трекпадом. На тій самій сторінці сказано, що в TestFlight діють ліміти: внутрішніх тестувальників до 100, зовнішніх до 10 000, і що перша збірка, яку ви даєте зовнішнім тестувальникам, теж іде до App Review.

What's New теж рахується

Ще одне правило, з настанов, а не з нових статей. Guideline 2.3.12 каже, що текст What's New має описувати нові функції та зміни, і лише прості виправлення помилок та робота над продуктивністю можуть обійтися загальним рядком. «Bug fixes and improvements» у релізі з новою функцією напрошується на запитання.

Тож сьогоднішній новий безкоштовний інструмент: форматувальник нотаток про реліз. Вставте чорнові нотатки або рядки git log --oneline. Він розкладає їх на «Нове», «Покращено» та «Виправлено», прибирає рядки chore, ci і merge, позначає номери тікетів та імена файлів, перевіряє ліміт у 4 000 символів і видає три копії: простий текст для App Store Connect, HTML для вашого Sparkle appcast і Markdown для GitHub. Ваші нотатки лишаються в браузері. Перевірка Sparkle appcast поруч, для стрічки, куди вони потрапляють.

Мій короткий список

  1. Два вільні дні до дня запуску і ручний випуск.
  2. Поле Notes, за яким зможе піти незнайома людина, і робочий демо-обліковий запис.
  3. Відповідайте, а не надсилайте повторно, коли ставлять лише запитання.
  4. Рахуйте скриншоти, читайте кожну purpose string і не пишіть чужі назви застосунків у ключових словах.
  5. What's New, який каже, що змінилося.

А коли застосунок вийшов, розміщення картки на MacPip безкоштовне, у Mac App Store чи ні. Картки автоматично перевіряються під час надсилання, а синя галочка означає лише те, що людина спробувала застосунок у вказану дату.

Джерела

Читайте далі

Подайте свій застосунокБезкоштовні інструменти для розробників