Новые справочные статьи Apple об App Review глазами автора Mac-приложений

Короткий ответ

В заметке 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 описала, как работает App Review. Вот что я бы изменил перед отправкой