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. Без нього Apple може знадобитися дзвінок, а дзвінки зазвичай займають від трьох до п'яти робочих днів. Це цілий тиждень.
- Для підписок потрібен демо-обліковий запис із завершеною підпискою, щоб рецензент побачив увесь процес купівлі.
Що б я зробив: писав би поле Notes як коротку інструкцію для незнайомої людини. Куди клацнути спершу, яким обліковим записом користуватися і що робить значок у рядку меню, якщо в застосунку немає вікна. Останнє дуже по-маківському.
Якщо відхилили
Це те, що я хотів би мати в письмовому вигляді багато років тому.
- Не надсилайте повторно, щоб відповісти на запитання. Якщо App Review просить інформацію, відповідайте в App Store Connect. Надсилайте повторно лише заради виправлення в збірці й лише коли виправлено всі названі проблеми.
- Шукайте «Bug Fix Submissions:» на початку. Якщо відхилення починається з такої позначки, стаття про Bug Fix Submissions каже, що можна відповісти згодою й розв'язати проблему в наступному оновленні. Не надсилайте повторно. Це працює лише для застосунків, які вже були схвалені, ніколи для юридичних проблем і проблем безпеки, і проблему не можна відкласти двічі.
- Прискорення лише для справжньої терміновості. Apple пише, що запити на прискорення «мають бути зарезервовані для справді термінових випадків», і лише для збірок, уже надісланих на перевірку. Якщо запуск прив'язаний до події, вкажіть подію та її дату в Notes.
- Апеляція в останню чергу. Спершу дайте відповідь на відхилення й усе поясніть. Якщо не допомогло, App Review Board приймає одну апеляцію на застосунок, а після повторного надсилання апелювати проти цього відхилення вже не можна.
Чотири правила з числами
Статті про настанови короткі й конкретні.
- Скриншоти, 2.3.3. Понад половина скриншотів має показувати застосунок у роботі, рахуючи за типами пристроїв. Якщо скриншотів три, два з них мають показувати застосунок. Заставка або титульна картка припустимі, поки їх меншість. Перевірка скриншотів MacPip перевіряє розміри, а решту можна порахувати самому.
- Наслідувачі, 4.1. Не вказуйте назви популярних застосунків і торгові марки в жодному полі метаданих. Це стосується й ключових слів, де класична помилка: назва конкурента. Перевірка ключових слів App Store рахує ваші поля, тож ви бачите, що в них лежить.
- Purpose strings, 5.1.1(ii). Для кожного захищеного ресурсу потрібна власна зрозуміла purpose string, локалізована, якщо локалізовано застосунок. Поганий приклад від самої Apple: «To use location.» До того ж ви відповідаєте і за те, що запитують ваші SDK. Вставте Info.plist у розбір Info.plist, і він позначить порожні та розпливчасті рядки.
- Видалення облікового запису, 5.1.1(v). Якщо в застосунку можна створити обліковий запис, користувачі мають мати змогу почати його видалення просто в застосунку. Деактивації недостатньо, а змушувати людей вам телефонувати не можна. Якщо є підписка, повідомте, що оплата через Apple триватиме, доки її не скасують.
Єдиний рядок про 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 поруч, для стрічки, куди вони потрапляють.
Мій короткий список
- Два вільні дні до дня запуску і ручний випуск.
- Поле Notes, за яким зможе піти незнайома людина, і робочий демо-обліковий запис.
- Відповідайте, а не надсилайте повторно, коли ставлять лише запитання.
- Рахуйте скриншоти, читайте кожну purpose string і не пишіть чужі назви застосунків у ключових словах.
- What's New, який каже, що змінилося.
А коли застосунок вийшов, розміщення картки на MacPip безкоштовне, у Mac App Store чи ні. Картки автоматично перевіряються під час надсилання, а синя галочка означає лише те, що людина спробувала застосунок у вказану дату.
Джерела
- Apple Developer: Hello Developer, листопад 2026 р.
- Apple Developer: App Review Help
- App Review Help: Відстеження статусу перевірки надсилання
- App Review Help: Інформація для повної перевірки
- App Review Help: Прийняття пропозицій Bug Fix Submission
- App Review Help: Запит на прискорену перевірку
- App Review Help: Апеляція до App Review Board
- App Review Help: 2.3.3, Показуйте застосунок у роботі на скриншотах
- App Review Help: 4.1, Як уникнути відхилень за копіювання та видавання себе за інший застосунок
- App Review Help: 5.1.1(ii), Пишіть зрозумілі purpose strings
- App Review Help: 5.1.1(v), Видалення облікового запису в застосунку
- App Review Help: Тестування застосунку на сумісних пристроях
- Apple Developer: App Review Guidelines
Читайте далі
- Claude Fable 5.2 і Mythos 5.2: що нового, бенчмарки і що це означає для вашого MacClaude Fable 5.2 і Mythos 5.2 вийшли 9 листопада 2026 р. Бенчмарки Anthropic у вигляді графіків, ціни, що змінюється на Mac, і чотири безкоштовні інструменти.
- Swift Student Challenge тепер приймає застосунки для Mac. Ось що я б створивSwift Student Challenge 2027 від Apple приймає роботи з 8 лютого до 28 і вперше бере застосунки для будь-якої платформи Apple, зокрема macOS. Правила, дати і як я планував би участь із застосунком для Mac.
- macOS 27.2.1 більше не довіряє eMudhra в curl. Що я б перевірив у своєму застосунку для MacmacOS 27.2.1, 26.7.3 і 15.8.3 видаляють п'ять кореневих сертифікатів із /etc/ssl/cert.pem після компрометації ключів eMudhra. Що змінилося, кого це стосується і що варто перевірити авторам застосунків для Mac.
- Live Activities з'являться в рядку меню Mac. Що б я зробив зі своїм застосунком для MacУ бета-версії macOS 27.3 Live Activities з'являються в рядку меню комп'ютерів Mac на Apple silicon, і застосунки для Mac можуть запускати власні. Що змінилося, які є обмеження і що спробувати насамперед.
- Через пам'ять Mac дорожчають. Що б я зробив у своєму застосунку для MacApple каже, що через пам'ять Mac лишатимуться в дефіциті й дорожчатимуть аж до 2027, а найдешевший Mac має 8 GB. Чому це важливо для вашого застосунку для Mac і які перевірки запустити цього тижня.
- Apple тепер дозволяє звернутися до тих, хто скасовує підписку. Ось що я зробив би у своєму застосунку для MacВід 4 листопада підписки в App Store можуть показувати повідомлення або пропозицію в момент скасування. Правила, що каже Apple і що перевірити на Mac.
- Apple додає два питання про вікові обмеження. Ось що я зробив би зі своїм застосунком для MacВід 16 листопада App Store Connect питає про спільну геолокацію та функції знайомств, і кожен застосунок має відповісти до 12 січня 2027 р. Що змінилося і що робити.
- Siri AI тепер відкрита для всіх розробників. Ось що я зробив би зі своїм застосунком для MacApple відкрила Siri AI для всіх розробників у бета-версії macOS 27.3. Що змінилося, що можна й чого не можна випускати вже зараз, і короткий план для невеликого застосунку для Mac.
- Mac із сенсорним екраном виходять 6 листопада. Ось що я перевірив би у своєму застосунку для MacПерші Mac із сенсорним екраном виходять 6 листопада. Що змінилося, що Apple радить розробникам і короткий список того, що варто перевірити у власному застосунку для Mac.
- Знайомство з MacPipЩо таке MacPip, навіщо я його створив, як працюють картки й день запуску, що насправді означає синя галочка і справжні цифри з перших днів.
- Як запустити застосунок для Mac: список, що вміщується на одній сторінціЩо робити до, в день і після запуску застосунку для Mac: підписування, ваша сторінка, каталоги, Product Hunt, Show HN і що вимірювати.
- Як написати опис в один рядок, який пояснює, що робить ваш застосунок для MacПростий спосіб написати один рядок під назвою вашого застосунку для Mac: назвіть завдання, приберіть перебільшення і перевірте на тому, хто ніколи не бачив застосунку.
- Підпис і нотаризація простими словами для тих, хто створює перший застосунок для MacЩо робить кожен із кроків: підписування коду, нотаризація і stapling, у якому порядку вони виконуються, що бачать ваші користувачі без них і як перевірити власну збірку.
- Скільки насправді варте dofollow-посилання, з сайту, який його пропонуєЩо означає dofollow, що Google каже про посилання, чому посилання з нового каталогу сьогодні варте мало і що робити замість купівлі посилань.
Подайте свій застосунокБезкоштовні інструменти для розробників