Сайт для публикации приложения в App Store: что обязательно

Какие URL Apple требует при подаче приложения

В форме App Store Connect, на шаге подготовки версии к ревью, есть три поля для ссылок на сайт. Два из них обязательны, одно — нет, и их легко перепутать между собой.

Support URL — что это и чем отличается от общего сайта

Support URL — обязательная ссылка на страницу, где пользователь может получить помощь по приложению: написать в поддержку, найти ответы на частые вопросы, оставить обращение. Это не просто ссылка на главную сайта студии — страница должна реально работать как канал связи, иначе при ревью или позже, при жалобах пользователей, Apple может отклонить обновление.

Privacy Policy URL — обязателен даже для простых приложений без аккаунтов

Privacy Policy URL обязателен для любого приложения в App Store, вне зависимости от того, собирает ли оно данные пользователя. Даже у офлайн-инструмента без аналитики и без аккаунта это поле нельзя оставить пустым — Apple требует политику конфиденциальности как часть формы, и без неё версия не уходит на ревью в принципе.

Marketing URL — когда он нужен, а когда можно пропустить

Marketing URL — единственное из трёх полей, которое необязательно. Это ссылка на рекламный лендинг приложения: описание продукта, скриншоты, видео. Если отдельного маркетингового сайта ещё нет, поле можно оставить пустым — на прохождение ревью это не влияет, в отличие от Support URL и Privacy Policy URL.

Privacy Policy: что должно быть написано, а не просто «страница с текстом»

Наличие страницы по адресу ещё не значит, что требование Apple закрыто — ревьюеры проверяют, отвечает ли текст на конкретные вопросы о данных.

Какие данные приложение собирает — и как это описать

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

Privacy nutrition label (App Privacy details) в App Store Connect — связь с текстом политики

Отдельно от самой страницы политики разработчик заполняет privacy nutrition label — блок App Privacy details прямо в App Store Connect, с чекбоксами по категориям собираемых данных. Это не текст, а структурированная декларация, которая отображается на карточке приложения в App Store. Ключевое правило: то, что указано в nutrition label, обязано совпадать с тем, что написано в privacy policy и с тем, что приложение реально делает. Расхождение между декларацией и текстом политики — одна из частых причин ручной проверки и отказа.

Privacy manifest — новое техническое требование Apple

Помимо текста политики и nutrition label, Apple ввела privacy manifest — отдельный технический файл внутри билда приложения, который декларирует использование так называемых required reason API (например, обращение к файловой системе или UserDefaults с конкретной заявленной причиной) и используемые сторонние SDK с их собственными манифестами. Это требование уровня кода, а не сайта, но оно напрямую связано с содержанием privacy policy: если манифест заявляет сбор данных, которого нет в политике, это несоответствие тоже может всплыть на ревью.

Почему App Tracking Transparency усиливает требования к сайту

Если приложение показывает системный запрос на трекинг (App Tracking Transparency), содержание privacy policy становится ещё важнее: ревьюер и пользователь должны понимать, зачем запрашивается разрешение и что именно отслеживается. Запрос ATT без внятного объяснения в политике конфиденциальности выглядит для ревьюера нелогичным и повышает риск вопросов на этапе проверки. Если приложение не использует ATT вовсе, в политике стоит явно это отметить — это снимает лишние вопросы.

Почему App Review отказывает из-за сайта

Несколько причин отказа повторяются из подачи в подачу, и все они связаны с URL, а не с самим приложением.

Нерабочий URL — самая частая причина: ссылка на Support URL или Privacy Policy URL ведёт на страницу-заглушку, 404 или временно недоступный сервер в момент проверки. Вторая по частоте — URL формально открывается, но страница пустая или не по теме (например, ведёт на общую главную без текста политики). Третья — несовпадение текста политики с фактическим поведением приложения: декларирован сбор одних данных, а SDK внутри собирает другие. Четвёртая, актуальная для приложений с аккаунтами, — отсутствие функции удаления аккаунта прямо внутри приложения (in-app account deletion): если пользователь может зарегистрироваться через приложение, он обязан иметь возможность удалить аккаунт тем же способом, без обращения в поддержку.

Нужна ли отдельная privacy policy webview и гибридным приложениям

Да, нужна — требование Apple не зависит от технологии, на которой построено приложение. Даже если всё содержимое приложения — это обёртка над веб-страницей (webview) или кроссплатформенный фреймворк, в App Store Connect всё равно обязательно заполняются оба поля: Support URL и Privacy Policy URL, отдельно от любых ссылок внутри самого webview-контента. Технология реализации приложения на формальные требования формы подачи не влияет.

Чек-лист перед отправкой в App Store Connect

1. Support URL открывается и ведёт на страницу с реальным способом связи — email, форма или FAQ
2. Privacy Policy URL открывается и содержит перечень собираемых данных, цели сбора и упоминание сторонних SDK
3. Текст политики совпадает с тем, что заполнено в privacy nutrition label (App Privacy details)
4. Если приложение запрашивает ATT — в политике объяснено, зачем это нужно
5. Privacy manifest в билде не противоречит тексту политики по составу собираемых данных
6. Если в приложении есть регистрация — добавлена функция удаления аккаунта прямо в интерфейсе
7. Marketing URL заполнен, если лендинг уже готов — либо осознанно оставлен пустым

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

Нужен ли отдельный сайт для каждого приложения или можно один общий?

Можно использовать общий сайт студии, если на нём есть отдельные страницы Support и Privacy Policy для конкретного приложения — Apple не требует уникальный домен на каждый продукт, важны рабочие конкретные URL в форме подачи.

Что будет, если указать нерабочий Support URL?

Приложение не пройдёт ревью, либо ревьюер отклонит заявку с указанием причины. Это одна из самых частых технических причин отказа, не связанных с кодом приложения вовсе.

Чем Marketing URL отличается от Support URL?

Marketing URL — рекламная страница о продукте (необязательна), Support URL — канал помощи пользователю (обязателен). Путать их не стоит: заполнение Marketing URL вместо Support URL не закрывает обязательное требование.

Нужна ли privacy policy приложению без регистрации и сбора данных?

Да, поле обязательно для любого приложения в App Store вне зависимости от того, собирает ли оно данные. В этом случае политика просто прямо описывает отсутствие сбора.

Что такое privacy manifest и нужен ли он всем?

Это технический файл в билде приложения, декларирующий причины использования определённых системных API и сторонних SDK. Актуален для приложений, которые используют required reason API или сторонние библиотеки с собственными манифестами — на практике это касается большинства современных приложений с аналитикой или рекламными SDK.

Как быстро подготовить такой сайт, если его ещё нет?

Минимальные страницы Support и Privacy Policy можно сделать за несколько дней даже на статике — больше времени уходит на корректный текст политики, чем на вёрстку. Если нужен не минимум, а полноценный сайт студии с этими страницами с самого начала, разумнее сразу доверить это профильной команде, а не собирать в последний момент перед подачей.

Два обязательных поля в форме App Store Connect кажутся мелочью рядом с самим приложением, но именно на них спотыкаются даже опытные разработчики — не из-за кода, а из-за заглушки вместо рабочей страницы или расхождения текста политики с реальным поведением приложения. Проверить оба URL и сверить их с privacy nutrition label стоит до, а не после отправки на ревью — это самая дешёвая проверка, которая экономит цикл повторной подачи.