App Store Connect Retention Messaging не показывается в Sandbox? Проверка 2026

Apple объявила о доступности Retention Messages 4 ноября 2026 года: сообщения могут показываться в процессе отмены автоматически продлеваемой подписки, а Sandbox подходит для проверки и может отображать последнюю черновую версию. Поэтому, если App Store Connect Retention Messaging не показывается в Sandbox, сначала выясните, используете ли вы настроенное сообщение или выбор через API; затем проверьте статус, привязку к подписке и реальный сценарий отмены. Для API дополнительно проверьте ответ сервера и правила резервного выбора — отсутствие одобрения само по себе не доказывает, что сообщение не должно быть видно в тестовой среде. Объявление Apple о Retention Messages

Эта проверка предназначена для разработчиков приложений с автоматическими подписками, которые не видят ожидаемый текст, изображение или предложение во время тестовой отмены. Она также пригодится инженерам StoreKit и серверной части, проверяющим соответствие подписки, предложения и тестового аккаунта. Ответственным за сборку и выпуск она поможет отделить сбой сценария Sandbox от проблем проекта и CI.

Последнее обновление — 8 ноября 2026 года; сведения сверены с объявлением Apple, справкой App Store Connect, документацией Retention Messaging API и демонстрацией WWDC26. Запись Apple о выпуске · Демонстрация Apple на WWDC26

Сначала определите путь сообщения: настройка или выбор через API

У этих вариантов разные источники истины и разные доказательства при разборе сбоя. В конфигурационном варианте App Store Connect связывает подготовленное сообщение с подпиской и условиями его показа. В варианте Retention Messaging API приложение взаимодействует с серверным путём: запрос и ответ влияют на выбор сообщения, а при проблеме значение имеют предусмотренные резервные варианты. Смешивать проверки этих путей нельзя. Руководство Apple по настройке Retention Messages · Документация Retention Messaging API

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

Есть и важная граница терминов. App Store Connect API 4.6 и Retention Messaging API не следует считать одним интерфейсом только потому, что оба связаны с App Store Connect. Проверяйте документацию конкретного API, которым реально пользуется ваш код; сведения о версии App Store Connect API сами по себе не подтверждают, что сервер выбора Retention Message отвечает корректно.

Почему сообщение не появляется при отмене подписки в Sandbox? Чаще всего проверяется не тот путь: например, конфигурацию считают активной в пользовательском сценарии, хотя тестируется API-выбор, либо ответ API принимают за результат конфигурационного сообщения. Разделите тесты и собирайте доказательства для того пути, который действительно включён в приложении.

Статус сообщения: черновик не равен недоступности в Sandbox

Статус важен, но его нельзя трактовать без учёта среды. В справке Apple перечислены состояния сообщений, включая черновик, ожидание проверки, одобрение и отклонение; откройте карточку конкретного сообщения и сопоставьте фактический статус с тем, что ожидает команда. При этом Apple указывает, что тестировщики Sandbox могут видеть последнюю черновую версию. Следовательно, непрохождение App Review не означает автоматически, что сообщение обязано отсутствовать в Sandbox. Описание статусов Retention Message

Можно ли тестировать сообщение, которое ещё не прошло App Review? Для Sandbox — да, если вы проверяете именно тестовое поведение: Apple сообщает, что тестировщик может видеть последнюю черновую версию. Не переносите этот вывод на рабочую среду и не считайте черновик гарантией показа всем тестовым аккаунтам: отдельно нужны корректная привязка и соответствующий сценарий отмены.

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

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

Привязка и предложение: подходящее ли сообщение получает этот подписчик

Наличие сообщения в App Store Connect ещё не означает, что оно применимо к тестируемой подписке. Сверьте идентификатор автоматической подписки в приложении с тем, к которому привязано сообщение, а затем проверьте условия применения предложения и право тестового аккаунта на него. Ошибка в идентификаторе или неподходящая учётная запись могут выглядеть как неисправность всей функции, хотя сама конфигурация присутствует и доступна.

Сообщение настроено, но подписчик его не видит: что проверить в связях? Сопоставьте сообщение, тестируемую подписку и Sandbox Apple Account. Затем разделите проверку обычного сообщения и сообщения с предложением: у предложения есть собственные условия применимости, поэтому отсутствие скидки не доказывает отсутствие самого сообщения. Настройку и предварительный просмотр проверяйте по руководству Apple, а не по предположению, что одинаковый экран означает одинаковое право на предложение.

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

Процесс отмены: системный сценарий важнее имитации в приложении

Пользовательский экран приложения, который называется «отменить подписку», не обязательно запускает тот же системный процесс, в котором Apple показывает Retention Message. Для проверки используйте предусмотренный Apple сценарий отключения автоматического продления для Sandbox-тестирования. Убедитесь, что активны нужный тестовый аккаунт и соответствующая среда, а операция относится именно к проверяемой подписке. Инструкция Apple по отключению автоматического продления при тестировании

Почему не стоит принимать внутреннюю кнопку приложения за полноценный тест? Она может изменить состояние приложения или показать собственное подтверждение, не воспроизводя системный путь отмены, где ожидается Retention Message. Используйте такую кнопку для проверки логики интерфейса приложения, но для приёмки показа сообщения выполняйте отмену способом, указанным Apple для Sandbox.

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

Серверный путь: запрос, ответ и резервный выбор

Если приложение использует Retention Messaging API, отсутствие сообщения может возникнуть не в App Store Connect, а на участке между запросом Apple и ответом вашего сервера. Проверьте, получил ли сервер запрос, соответствует ли ответ документированному формату и указывает ли выбранный идентификатор на сообщение, подходящее для этой подписки. Сохраняйте факт запроса, результат обработки и факт ответа отдельно: иначе тайм-аут, некорректный ответ и корректный выбор без отображения будут неразличимы.

Что будет показано, если API не вернул пригодный выбор? Не делайте вывод о конкретной заглушке по одному отсутствующему экрану. Сверьте фактический ответ и поведение с описанным Apple порядком выбора: ответ API, сообщение, настроенное в App Store Connect, и сообщение по умолчанию участвуют в резервной логике в предусмотренных документацией случаях. Важны не только отсутствие ответа, но и его валидность, связь выбранного сообщения с подпиской и применимость результата.

Разведите результаты на отдельные категории: запрос не пришёл; запрос пришёл, но ответа нет; ответ отклоняется как неподходящий; ответ указывает на сообщение, которое не соответствует тестируемой подписке; запрос и ответ успешны, но экран не показывает ожидаемый результат. Такое разделение превращает расплывчатое «API не работает» в проверяемую точку сбоя.

Для проверки производственного поведения не подменяйте тест реальными ожиданиями от Sandbox. Apple отдельно документирует запуск теста производительности и ограничения частоты запросов; прежде чем проводить нагрузочную проверку, сверяйте текущие требования и ограничения по официальной документации. Не выводите допустимую нагрузку из единичного тестового ответа. Инструкция Apple по запуску теста производительности · Описание ограничений частоты запросов

Порядок повторной проверки: от превью к реальной отмене

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

• Шаг первый. Запишите, какой путь реализован: конфигурационное сообщение или выбор через Retention Messaging API. Если задействованы оба варианта, ведите их проверки раздельно.
• Шаг второй. Откройте сообщение в App Store Connect и зафиксируйте статус, текст, изображение, связанную подписку и наличие предложения. Сверьте карточку с руководством по настройке и официальным описанием статусов.
• Шаг третий. Проверьте предварительный просмотр. Убедитесь, что он соответствует нужной версии сообщения; для сообщения с предложением отдельно проверьте его представление и условия.
• Шаг четвёртый. Подтвердите, что Sandbox Apple Account и активная тестовая подписка соответствуют конфигурации. Не используйте результат для одной учётной записи как доказательство поведения другой.
• Шаг пятый. Запустите предусмотренное Apple тестовое отключение автоматического продления, а не только внутреннюю имитацию отмены в приложении.
• Шаг шестой. При использовании API сохраните запрос, результат серверной обработки, ответ и то, какой резервный вариант был применён. Сопоставьте выбранный идентификатор с сообщением и подпиской.
• Шаг седьмой. Повторите тест после изменения только одного установленного фактора. Это позволит отличить исправление статуса или связи от изменения поведения аккаунта, среды или ответа сервера.

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

Матрица решения: какой участок проверять дальше

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

Если для проверки или сборки нужен отдельный macOS/Xcode-узел, сначала определите, что именно блокирует вас: сборка, подпись приложения или системный тест отмены. Материалы по удалённой разработке на Mac помогут оценить, какие действия можно выполнять в удалённой среде; доступ к физическому устройству это не подразумевает.

Если проблема оказалась не в сообщении, а в отсутствии macOS/Xcode для сборки или подписи, выбирайте среду по реальному этапу проверки. Windows или Linux могут оставаться удобными для основной разработки, но не заменят macOS-часть сборки; собственный Mac требует покупки и обслуживания, а неподходящая виртуальная среда не гарантирует нужный процесс тестирования. Для временной работы над сборкой удалённый Mac от OSXPort может быть удобнее, чем покупать отдельную машину под разовую задачу; однако заранее подтвердите, что вашему тестовому процессу не требуется физическое устройство. Посмотреть варианты можно на странице Mac mini для удалённой работы.