Руководство Apple по проверке приложений 2026: как независимому разработчику провести самопроверку?

16 октября 2026 года: что именно следует перепроверить

16 октября 2026 года Apple опубликовала обновление руководства по проверке приложений. В нём появился пункт 2.3.14 о творческих материалах, а пункт 2.5.19 подробнее описывает скрытые, неактивные или неуказанные функции. Это не означает, что каждому приложению нужно срочно менять код: сначала проверьте материалы, видимость функций и инструкции для проверки, а исправляйте только обнаруженные несоответствия. Дата и содержание обновления указаны Apple.

Обновлено 21 октября 2026 года; правила сверены с действующим руководством App Review и документацией App Store Connect о материалах приложения.

Статья предназначена для независимых разработчиков, которые готовят новую публикацию или отправляют обновление и хотят сверить поведение приложения с материалами страницы.
Командам с удалённой настройкой, переключателями функций и поэтапным открытием доступа стоит проверить, что включённые возможности понятны и проверяемы.
Тем, кто отвечает за страницу приложения, важно не смешивать творческие материалы со снимками экранов и видео предварительного просмотра.

Сначала отделите новые уточнения от требований, действующих для приложения

Разработчику полезно читать обновление не как перечень обязательных изменений кода, а как перечень рисков, которые нужно сопоставить с конкретной версией приложения. В пояснении Apple говорится, что требования к скрытым или неуказанным функциям ранее относились к пункту 2.3.1; новая структура выделяет отдельные аспекты в пунктах 2.3.14 и 2.5.19. Сверить формулировки можно в обновлении Apple от 16 октября 2026 года и в текущем тексте правил, на которые ссылаются источники в начале статьи.

Последний столбец — практический способ применить текст правил, а не отдельное утверждение Apple о результате проверки конкретного приложения. Обновление не позволяет заранее предсказать решение по отдельной отправке. Поэтому полезно фиксировать, какую именно формулировку или функцию проверяет команда, и не превращать редакционное уточнение в универсальную причину для изменения архитектуры.

Проверьте творческие материалы на точность и соответствие аудитории

Творческий материал должен быть связан с приложением, его функциями или брендом и подходить аудитории, для которой он показывается. Проверьте, не создаёт ли он впечатление, что приложение умеет больше, чем фактически умеет отправленная версия. Для утверждений о продукте нужна возможность подтвердить их самим приложением или надёжной информацией, а не только рекламной формулировкой. Эти требования следует сверять с пунктом 2.3.14 руководства App Review.

При проверке не ограничивайтесь вопросом «похоже ли это на наш продукт». Разберите каждый заметный элемент отдельно:

• Упоминается ли в материале другое приложение? Если да, понятно ли, зачем оно упомянуто, и не создаётся ли впечатление одобрения, совместимости или партнёрства, которого нет?
• Можно ли подтвердить заявленную функцию в версии, отправляемой на проверку? Если демонстрация показывает недоступную пользователю возможность, пояснение в описании не обязательно устранит расхождение.
• Есть ли конкретная или сниженная цена? Проверьте, актуально ли это предложение, где оно действует и не воспринимается ли как обещание, которое нельзя подтвердить.
• Подходит ли содержание всем пользователям, которым может показываться этот материал? Проверяйте не только текст, но и изображения, последовательность кадров и подразумеваемый контекст.

Для App Store творческие материалы, снимки экранов и видео предварительного просмотра решают разные задачи. Снимки экранов показывают интерфейс и должны представлять приложение; особенности требований к ним собраны в руководстве Apple по снимкам экранов. Для видео предварительного просмотра действуют собственные требования к формату и содержанию, изложенные в спецификации App Preview. Творческие материалы нужно сверять с отдельной документацией App Store Connect о материалах приложения, указанной выше.

Эта таблица — рабочее разграничение материалов, а не утверждение, что один тип контента может заменить другой. Если изображение одновременно используется в нескольких местах, проверьте его с учётом назначения каждого поля в App Store Connect. Не переносите автоматически требования к одному ресурсу на другой: Apple описывает их в отдельных документах.

Найдите функции, доступные через переключатель или удалённую настройку

Функциональный флаг, серверная настройка или поэтапное открытие доступа сами по себе не доказывают нарушение. Риск возникает, если фактическая возможность не описана, её невозможно обнаружить или понять либо отправленная версия ведёт себя иначе, чем обещают материалы страницы. Пункт 2.5.19 следует применять к видимости и ясности функций, а не к названию конкретной технологии; точную формулировку можно сверить в руководстве Apple, указанном выше.

Составьте перечень функций, которые уже есть в сборке, но доступны не всем или не сразу. Для каждой запишите:

• Где пользователь узнаёт о функции и как может понять её назначение.
• Какие условия открывают доступ: настройка, учётная запись, последовательность действий или этап запуска.
• Что увидит специалист App Review при обычной проверке и какие действия позволят ему добраться до нужного экрана.
• Не расходится ли фактическое поведение с описанием приложения, снимками экранов или творческими материалами.
• Нужны ли дополнительные сведения в App Review Notes, чтобы проверяющий мог пройти нужный путь.

Особенно внимательно проверьте два разных сценария. В первом функция доступна в отправленной версии, но запускается после понятного действия или условия; задача команды — ясно описать этот путь. Во втором приложение включает возможность удалённо, но пользователь не может понять, что она существует, как она работает или когда появится. Тогда одних заметок для проверки может быть недостаточно: сначала определите, что именно увидит пользователь и соответствует ли это описанию продукта. Это анализ риска, а не обещание, что конкретная схема будет принята или отклонена.

Сопоставьте страницу приложения с фактическим поведением сборки

Самостоятельная проверка часто обнаруживает не отдельное нарушение, а разрыв между несколькими слоями: страница обещает функцию, изображение показывает один вариант интерфейса, а отправленная версия предлагает иной путь или вовсе не открывает его. Проверяйте вместе метаданные, творческие материалы, снимки экранов, видео и фактическое поведение именно той версии, которая направляется на проверку.

Функции с ограничениями не всегда нужно описывать длинным техническим текстом. Но из представления приложения должно быть ясно, что именно получает пользователь, при каких условиях доступна возможность и какие ограничения сохраняются. Если основная функция не видна сразу, не заставляйте проверяющего угадывать её расположение или последовательность действий. Подготовьте проверяемый путь и согласуйте его с фактическим поведением версии.

Зафиксируйте риски до отправки в App Store Connect

Проверку удобнее вести как журнал конкретных объектов, а не как единственный флажок «готово к отправке». Тогда команда сможет отделить вопрос к рекламному материалу от вопроса к реализации функции или к доступу для App Review.

Порядок проверки:

1. Зафиксируйте отправляемую версию. Укажите, какой архив, версия приложения и номер сборки проверяются. Сведения о версии в App Store Connect сверяйте с официальной справкой Apple.
2. Соберите материалы страницы. Выпишите описания, творческие материалы, снимки экранов и видео предварительного просмотра. Для каждого запишите назначение и версию приложения, которую он представляет.
3. Сопоставьте утверждения с приложением. Отметьте каждую функцию, цену, ограничение и заявление, которое может повлиять на решение пользователя. Проверьте, можно ли подтвердить их в отправляемой версии.
4. Проверьте переключатели и удалённые настройки. Пройдите пользовательский путь для каждой функции, которая запускается не сразу или доступна по условию. Запишите, что увидит человек без специальных сведений и что нужно сообщить проверяющему.
5. Подготовьте App Review Notes. Укажите точный путь к неочевидным функциям, необходимые условия доступа и объяснение поведения. Требования Apple к сведениям для проверки описаны в разделе полноты информации для App Review.
6. Проверьте согласованность перед отправкой. Повторно сравните страницу и архив после последних изменений. Если изменились интерфейс, доступность функции или условия запуска, обновите соответствующие материалы и инструкции.
7. Запишите результат по каждому риску. Для записи достаточно указать объект, проверку, результат и следующее действие; не смешивайте фактическую ошибку с предположением о том, как именно её оценит Apple.

Для сверки архива с тем, что команда считает отправляемой сборкой, можно получить номер сборки из Info.plist:

/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' \
  'Payload/ИмяПриложения.app/Info.plist'

Пример формата вывода:

номер-сборки-из-архива

Это техническая сверка идентификатора, а не проверка соответствия правилам. Она не подтверждает, что материалы страницы актуальны, удалённая функция доступна или App Review сможет воспроизвести сценарий. Эти пункты нужно проверять отдельно, по фактическому содержимому отправки.

Разделите причину риска и способ исправления

Перед отправкой полезно определить, где именно находится проблема: в материале, функции или объяснении. Так исправление не превратится в ненужное изменение кода, если достаточно обновить ресурс страницы или добавить понятный путь проверки.

Используйте только текст правил Apple как нормативное основание, а ожидаемое решение по конкретной отправке формулируйте осторожно. Самопроверка помогает выявить несоответствие и подготовить понятную проверку; она не заменяет оценку App Review и не гарантирует результат. Если причина неоднозначна, сохраните факты отдельно от предположений: что показано, какой сценарий воспроизведён, что именно остаётся неясным.

Фиксация результатов

Для рабочего журнала подойдёт такая форма:

Объект: творческий материал / функция / инструкция
Версия приложения: номер из отправляемого архива
Наблюдение: проверяемый факт
Доступ для App Review: путь и необходимые условия
Результат: соответствует / требует уточнения
Следующее действие: конкретное исправление или пояснение

Записи помогают обнаружить противоречия между материалами и сборкой после изменения функции, условий доступа или текста страницы. Не заполняйте их прогнозами вроде «точно отклонят»: решение по конкретной отправке из этого списка не следует.

Ответы на вопросы о самопроверке

Что изменилось в правилах проверки приложений Apple в 2026 году?

В опубликованной Apple редакции появился пункт 2.3.14 о творческих материалах, а пункт 2.5.19 подробнее описывает скрытые, неактивные или неуказанные функции. В пояснении Apple отмечено, что соответствующие требования ранее относились к пункту 2.3.1. Это повод проверить собственные материалы и функции, а не автоматически переделывать любое приложение.

Какими должны быть творческие материалы для страницы приложения?

Материалы должны относиться к приложению, его функциям или бренду, быть пригодными для заявленной аудитории и не вводить пользователя в заблуждение. Проверьте упоминания других приложений, проверяемость рекламных утверждений и сведения о конкретной или сниженной цене. Также не смешивайте творческие материалы с изображениями экранов и видео предварительного просмотра: у этих элементов разные роли.

Становится ли функция скрытой, если она включается удалённой настройкой?

Сам способ включения — например, удалённая настройка, переключатель или постепенное открытие доступа — сам по себе не даёт основания объявлять функцию нарушением. Важно, что увидят пользователь и специалист App Review: ясны ли назначение и условия доступа, можно ли обнаружить функцию и проверить её. Если это неочевидно, заранее опишите поведение и путь проверки.

Что писать в App Review Notes о функции, которую трудно найти?

Укажите, где находится функция, какие действия нужны для её проверки и какие условия доступа действуют в отправленной версии. Если требуется учётная запись или специальная последовательность действий, предоставьте рабочие сведения и точные шаги в материалах для проверки. Сверьте описание с фактическим поведением сборки: пояснение помогает разобраться, но не заменяет доступ к функции и не гарантирует положительное решение.

Выберите среду для финальной проверки сборки

Если для подготовки архива и сверки отправляемой версии уже есть подходящая Mac-среда, отдельная аренда может быть не нужна. Но если текущий процесс зависит от нестабильного доступа к Mac, локальное хранилище ограничивает работу с архивами или разработчику приходится откладывать сборку до появления свободной машины, сравните стоимость и ограничения этих вариантов до следующей отправки. Удалённый Mac не исправляет несогласованные материалы и не влияет на решение App Review; он может быть полезен именно как доступная macOS-среда для сборки и проверки архива.

Перед выбором оцените, нужен ли такой доступ эпизодически для подготовки версии или постоянно для регулярных сборок. Для разовой проверки можно оставить локальный процесс, если он воспроизводим и архив легко сверить. Если Mac требуется только на этапах сборки и отправки, условия аренды Mac через ViewMini стоит оценить отдельно от покупки собственного компьютера. За техническими условиями доступа и возможностями конкретной среды можно обратиться через страницу связи ViewMini.

Практичный следующий шаг — завершить журнал самопроверки и убедиться, что материалы, функции и сборка описывают одно и то же состояние приложения. Только после этого имеет смысл решать, нужна ли дополнительная macOS-среда для подготовки и повторной проверки отправляемого архива.

Часто задаваемые вопросы