Этот материал разбирает что нужно знать о требованиях App Store и Google Play: от аккаунтов и метаданных до приватности, разрешений, платежей и прохождения ревью. В одном потоке — правила, подводные камни и практики, которые повышают шансы пройти модерацию с первого раза.

Сторовые правила редко выглядят как скучная бумага: это скорее свод дорожных знаков, где каждая стрелка указывает не только «можно/нельзя», но и предупреждает о ямах. Игнорировать их — как выезжать на трассу без фар: пару километров удастся проскочить, а затем внезапная канава и возвращение в гараж.

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

Что на самом деле подразумевают «требования стора»

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

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

Аккаунты и договоры: кто имеет право на публикацию

Правильный тип учётной записи и подписанные соглашения — порог входа, без которого публикация невозможна. Для App Store нужен разработческий аккаунт Apple, для Google Play — аккаунт разработчика и при необходимости мерчант-аккаунт для платежей.

У Apple различают индивидуальные и организационные записи: компаниям требуется подтверждение юридического лица (включая D‑U‑N‑S) и право представлять организацию. Годовая плата за участие остаётся стандартной, а для распространения платных приложений и подписок потребуется активировать соответствующее соглашение в App Store Connect. В Google Play регистрация сопровождается разовой оплатой, а для приёма платежей открывается продавец (merchant) в связанной платёжной системе, что потребует банковских и налоговых данных. В обоих сторах важно, чтобы название аккаунта читалось пользователю как надёжный источник: модераторы обращают внимание на соответствие бренда приложению, контактам поддержки и сайту.

Разница в аккаунтах отражается и на скорости операций: у организаций надёжнее выглядит юридическая линия, особенно когда продукт ориентирован на B2B, использует защищённые каналы связи или предъявляет доверительные требования к бренду. На стороне Google Play ранние релизы новых издателей могут проходить более тщательную оценку; с ростом репутации аккаунта автоматизированные фильтры реже задерживают обновления. Практически это означает: подготовка документов и прозрачность бренда экономят дни и недели на старте.

Метаданные и визуал: карточка приложения как договор с пользователем

Описание, название, скриншоты и иконка — не витрина, а обязательства: они должны точно отражать функциональность и целевую аудиторию. Любая гипербола или несогласованность влечёт вопросы модерации.

У Apple карточка состоит из названия, подзаголовка, описания, ключевых слов, ссылок на поддержку и политику конфиденциальности, а также набора скриншотов для разных устройств и опционального видео. В Google Play — имя приложения, краткое и полное описание, категория, элементы графики (включая feature graphic), скриншоты и превью. В обоих случаях скриншоты должны отражать реальный интерфейс без чужих торговых марок, вводящих в заблуждение фраз и «обещаний» несуществующих функций. Если сервис требует регистрации, на скриншотах допустимо показать этот шаг; если функция доступна только платно, важно не маскировать её как базовую.

Модераторы сопоставляют карточку и поведение приложения шаг за шагом. Если сказано «без регистрации» — появление формы логина при первом запуске приведёт к возврату. Если обещано «бесплатно» — наличие ключевой функции только в подписке без пометок будет воспринято как вводящее в заблуждение. Для локализаций крайне важна семантика: дословный перевод без учёта культурного контекста и регуляторных норм (например, для финансовых продуктов) — частая причина задержек. Карточка — это договор с пользователем: что обещано тем и должно быть встречено сразу после установки, иначе стор встанет на сторону аудитории.

Конфиденциальность и отслеживание: прозрачность как условие допуска

Сбор данных должен быть минимальным, обоснованным и задекларированным: сторы требуют объяснить, что берётся, зачем и как это контролируется пользователем. Запрос на отслеживание должен быть честным и своевременным.

В экосистеме iOS действует схема прозрачности отслеживания: если используется идентификатор рекламы или кросс-приложечное отслеживание, запрашивается явное разрешение через системный диалог. В App Store Connect заполняется раздел о типах данных, их привязке к личности и цели использования; политики приватности должны совпадать с фактическим поведением кода. В экосистеме Android в Google Play Console заполняется форма «Безопасность данных»: описываются категории, шифрование, опция удаления и способы контроля со стороны пользователя. Использование сторонних SDK больше не проходит без внимания: сторы ожидают, что издатель понимает, какие данные утекают через библиотеки, и способен объяснить их назначение.

Практически это означает: перед релизом проводится «инвентаризация данных» — что собирается по факту вызовов SDK и API, какие экраны несут уведомления и согласия, есть ли у пользователя понятный механизм отзыва. Системные подсказки должны объяснять пользу и контекст, а не выглядеть как давление: фразы о «неполном опыте» допустимы, угрозы — нет. В требованиях конфиденциальности всё сводится к одному: данные — не добыча, а кредит доверия; он заканчивается, если используется чужой API без понимания последствий, а редакция карточки расходится с поведением сборки.

Разрешения и системные возможности: как обосновать доступ

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

На iOS назначение доступа описывается в purpose‑строках: пользователю показывается конкретная причина, и модерация её читает. Запрос до появления функции — частая ошибка: требует камера — значит, запрос возникает в момент, когда пользователь нажимает «снять фото», а не при первом запуске. В Android чувствительные разрешения регулируются политиками: SMS/звонки — только для приложений‑обработчиков по умолчанию, фоновая геолокация — после объяснения и прохождения проверки, доступ ко всем файлам — строго ограничен и требует убедительного сценария. Каждая система добавляет свой контекст к UX: отсутствие экрана с объяснением — сигнал, что запрос делается «на всякий случай», что почти гарантированно вызовет вопросы модерации.

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

Платежи и подписки: границы встроенных покупок

Цифровой контент и функции внутри приложения оплачиваются встроенными покупками стора, за пределы которых выходить нельзя. Физические товары и услуги — другой режим: допускаются внешние платежи.

В App Store действует строгий принцип: цифровые услуги и доступ к функциям приложения — через встроенные покупки и подписки; сторонние платёжные формы внутри iOS‑приложения для таких продуктов считаются нарушением. Исключения ограничены категориями вроде «ридер‑приложений», где допускается ссылка наружу по специальному разрешению, и определёнными программами в отдельных юрисдикциях. В Google Play правило аналогично: цифровой контент продаётся через Play Billing, при этом существуют программы, разрешающие альтернативный биллинг в установленных рамках и регионах. В обоих сторах важно не путать модели: если подписка управляется стором, её пробные периоды, отмены и восстановление должны корректно отражаться в интерфейсе, а цены — совпадать с заявленными в консоли.

• Ясно отделять то, что покупается через стор, от внешних услуг (доставка, офлайн‑мероприятия).
• Показывать цену и условия подписки до оплаты: период, пробный срок, автопродление.
• Предусмотреть экраны управления подпиской, ведущие в системный менеджер.
• Не прятать функциональность за «замком» без пояснения, что это платная опция.

Стор особенно чувствителен к манипуляциям: «таймеры» со снятием скидки на глазах, затруднённый отказ, серые формулировки — всё это воспринимается как тёмные паттерны. Прозрачность, аккуратная локализация финансовых терминов и соответствие локальному праву (например, отображение итоговой цены с налогами там, где это обязательно) — тот самый невидимый бампер, о который так часто разбиваются хорошие продукты. Монетизация построена не на хитрости, а на честном обмене ценностью; сторам это важно не меньше, чем пользователям.

Контент, аудитория и рейтинг: линии, которые нельзя пересекать

Контентная политика сторо́в защищает аудиторию от вреда, обмана и ненадлежащего материала. Приложение обязано соответствовать возрастному рейтингу и иметь механизмы модерации для пользовательского контента.

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

Релиз и техническая готовность: как пройти ревью с первой попытки

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

На iOS путь часто начинается с TestFlight: внутреннее и внешнее тестирование, сбор обратной связи, исправление падений и проблем UX. В Android выручает ступенчатый релиз: внутренний канал, закрытая или открытая бета, пре‑лаунч‑отчёты с реальных устройств. Для Google Play критичны показатели стабильности: аномальный процент «анров» и крэшей воспринимается как недоработка; для App Store — полнота и отсутствие «пустых экранов». Сторовому ревью помогают технические маркеры: минимальный целевой уровень API в Android в пределах актуального окна, 64‑битные сборки, формат Android App Bundle; на iOS — корректная подпись, поддерживаемые архитектуры, отсутствие запрещённых API. Разные по сути требования сходятся в одном: показать зрелость сборки и готовность к поддержке пользователей.

• Подготовить тестовые учётные записи, доступы к серверу и сценарии для модераторов.
• Проверить локализации метаданных и экранов оплаты на соответствие правилам и рынкам.
• Собрать отчёты о крэшах/ANR и устранить пики до релиза.
• Согласовать возрастной рейтинг и контентные фильтры с фактическим поведением.
• Проверить тайминг запросов разрешений и тексты объяснений.

Отдельный пласт — поддержка и контакты. Указанная почта и сайт поддержки должны быть живыми: модераторы действительно пишут и проверяют. Автоматические ответы‑рыбы, недоступные страницы или домены с сомнительной репутацией — слабые сигналы, которые складываются в решение отложить выпуск. Релиз — это не «выложить файл», а согласованное движение: документы, карточка, сборка, тестирование, поддержка. Когда каждый элемент на своём месте, ревью превращается из рулетки в процедуру.

FAQ: ответы на частые вопросы по требованиям стора

Можно ли упоминать конкурентные бренды в описании и скриншотах?

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

Разрешено ли просить доступ к геолокации при первом запуске?

Технически возможно, но почти всегда неуместно: запрос должен возникать в момент, когда он логичен для пользователя и подтверждён действием в UI. Если геолокация — критическая часть сценария, нужно объяснение на экране до системного диалога и альтернатива, которая позволяет осмотреться без немедленного согласия.

Как оформить подписку, чтобы пройти модерацию?

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

Обязателен ли сайт и политика конфиденциальности?

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

Что делать, если приложение отклонено за «минимальную функциональность»?

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

Можно ли использовать альтернативный биллинг?

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

Ниже — краткая «карта местности», которая стягивает все нити воедино и превращает подготовку к релизу в чёткий маршрут действий. Она не отменяет глубину требований, но расставляет ориентиры в порядке, в каком с ними сталкивается продуктовая команда.

1. Оформить правильный тип аккаунта и договоры на приём платежей; привести бренд, сайт и контакты поддержки в соответствие.
2. Собрать карточку: честные описания, локализации, реальные скриншоты и видео без маркетинговых ухищрений.
3. Провести «инвентаризацию данных»: что собирается, где запрашиваются согласия, как пользователь может отказаться.
4. Перепроверить разрешения: тайминг, объяснения, минимально необходимый объём доступа.
5. Настроить монетизацию: встроенные покупки там, где это требуется, понятные условия подписки.
6. Проверить контент и возрастной рейтинг: модерация UGC, фильтры, ограничения для детей.
7. Пройти тестовые каналы: собрать отчёты, устранить падения и аномалии производительности.
8. Подготовить для ревью тестовые учётки, сценарии, ссылки и контакты, убедившись, что всё работает «снаружи» так же, как «внутри».

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