Как опубликовать приложение в App Store, если в нём используются встроенные покупки?

У меня приложение с встроенными платежами через Юкасса. Планирую опубликовать его в Appstore, но слышал, что Apple не пропускает приложения с собственными платежными шлюзами. <br/> <br/> Чтобы обойти это, я настроил фича-флаги: при модерации приложение выглядит как бесплатное, а после одобрения на бэке включаю флаги и активирую платёжный функционал. <br/> <br/> Вопрос к знающим: <br/> Насколько эта схема реально помогает пройти модерацию Apple? <br/> Какова вероятность получить блокировку от Apple позже за попытку обойти их правила? Могут ли они проверить уже одобренное приложение и принять меры после модерации?
  • 9 апреля 2026 г. 8:01
Ответы на вопрос 3
Короткий ответ: схема с «выключенными» фичами для модерации — рискованная и не даёт юридической гарантии. Apple может и будет проверять скрытые/серверные функции, и в случае обнаружения обхода правил приложение могут удалить или даже принять более жёсткие меры против учётной записи разработчика.

Пояснения и детали.

1) Что требует Apple (важные места правил)
- Правило 3.1 App Store Review Guidelines: для цифрового контента/функций, используемых внутри приложения (подписки, внутриигровые предметы, премиум-функции и т.д.), обязателен In‑App Purchase (IAP). Сторонние платежные шлюзы запрещены для таких случаев.
- Есть исключения: физические товары/услуги, платежи P2P, некоторые бизнес-модели (например, «reader apps») — у них свои правила и ограничения.
(В целом: если пользователь получает в приложении цифровой контент или доступ к функционалу — Apple ожидает IAP.)

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

3) Насколько вероятно обнаружение / блокировка
- Точных процентов дать нельзя. Но на практике:
  - Если нарушение очевидно (встроенный собственный платёжный экран для цифровых товаров, ссылки на внешние покупки и т.п.), вероятность отказа на модерации высокая.
  - Если вы специально скрываете функционал, есть значительный риск, что Apple обнаружит это позднее (через внутреннюю проверку, жалобы пользователей или мониторинг трафика). Вероятность обнаружения нельзя считать низкой.
  - Последствия зависят от масштаба и намерения: единичный пропуск может закончиться простым требованием изменить приложение; систематический обман — более жёсткие меры.

4) Практические советы (что делать)
- Лучший и наиболее безопасный путь — привести модель оплаты в соответствие с правилами Apple:
  - Для цифрового контента и подписок используйте IAP.
  - Для физических товаров/услуг используйте сторонние платёжные системы — это разрешено.
  - Для «reader apps» — следовать специальным правилам (логин/доступ к ранее купленному контенту допускается, но нельзя рекламировать внешние покупки внутри приложения).
- Если всё же хотите публиковать сейчас и постепенно включать платёжный функционал:
  - Не обманывайте рецензента умышленно. В поле «Инструкции для обзора» (App Review) честно опишите, какие фичи активны в сборке и как их тестировать.
  - Лучше загрузить сборку, где реальный платёжный функционал отключён и заменён тестовой/демо логикой, и в примечании сообщить, что продакшен‑флаг будет переключён после релиза — но учтите, это всё равно риск.
- Если вы считаете, что ваша модель подпадает под исключение, аргументируйте это в App Review подробно и приложите схему работы, примеры транзакций, и учётные данные для тестирования.
- Рассмотрите консультацию с юристом/специалистом по публикации приложений или напрямую обратитесь в Apple Developer Support за разъяснениями прежде чем публиковать с обходными путями.

5) Практические признаки, которые мониторят рецензенты
- Наличие в приложении интерфейса оплаты для цифрового контента, не использующего IAP.
- Ссылки/тексты, призывающие покупать вне приложения.
- Сетевые вызовы на платежные шлюзы/эндпоинты при тестировании.
- Наличие кода/ресурсов, явно указывающих на сторонние платёжные услуги.

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

Если хотите — пришлите краткое описание того, что именно продаётся в приложении (тип товара/услуги, как проходит оплата), и я помогу оценить, подпадает ли это под правило об IAP и какие у вас безопасные варианты.
Как только ваше приложение станет статистически значимым - могут проверить и дать по жопе полным баном аккаунта. Пока там две калеки в качестве пользователей - может и пронесет. Особенно если не будет жалоб со стороны пользователей. <br/> <br/> Но не стоит забывать что проверить наличие всякого стороннего можно и без запуска приложения - и это делают и гугл точно и скорее всего эппл. Банально найдут у вас сигнатуру юкассы и все.
почему бы не сделать нормально - просто перекидывая юзеров на сайт для оплаты
Похожие вопросы