Короткий вывод: сначала проверьте, что именно покупает пользователь
Apple указывает, что Bundles и Suites предназначены для приложений на iOS 27, iPadOS 27, macOS 27 или tvOS 27 и новее и требуют StoreKit 2 — это условие описано в официальном руководстве Apple по Bundles и Suites. Если ваши подписки по-прежнему можно покупать отдельно, сначала оценивайте Bundle. Если вы продаёте доступ к нескольким приложениям как единый сервис, рассматривайте Suite. Для совместного предложения подписок разных разработчиков проверяйте вариант multideveloper Bundle, но не планируйте запуск до прохождения заявки и настройки.
Кому читать: если у вас одно приложение с несколькими подписками — решите, нужно ли пользователям покупать их набором.
Если вы поддерживаете несколько приложений — сопоставьте подписку с тем, что она открывает в каждом из них.
Если вы договариваетесь с другими разработчиками — заранее разделите права на контент, обязанности и процесс подачи заявки.
Последнее обновление: 25 октября 2026 года; требования и порядок действий сверены по документации Apple о Bundles и Suites и материалу Apple Developer о новых возможностях.
Чем Bundle отличается от Suite: покупка набора или единая услуга
Название формата само по себе не определяет правильный выбор. Начните с пользовательского результата: человек приобретает несколько самостоятельных подписок со скидкой или оформляет одну подписку на сервис, который работает в нескольких приложениях? В первом случае логика ближе к Bundle. Во втором стоит оценить Suite — при условии, что именно так устроены продукт и права доступа.
| Вопрос для оценки | Bundle | Suite |
|---|---|---|
| Что объединяется | Подписки, которые могут оставаться доступными для отдельной покупки | Подписки, образующие единый сервис для нескольких приложений |
| Что получает пользователь | Возможность приобрести сочетание подписок | Доступ к согласованному набору сервисов или приложений |
| Когда рассматривать | Когда отдельные продукты сохраняют собственную ценность и аудиторию | Когда подписка задумана как единый уровень доступа между приложениями |
| Что проверить до настройки | Состав набора, отдельные варианты покупки и правила предоставления прав | Общий пользовательский сценарий и то, как доступ подтверждается в каждом приложении |
Это различие не заменяет проектирование каталога. Bundle не следует выбирать только потому, что у вас уже есть несколько SKU, а Suite — только потому, что в портфеле несколько приложений. Разберитесь, какие функции покупатель ожидает получить, какие подписки он может оформить отдельно и кто отвечает за их обслуживание.
Не смешивайте подписочные Bundles с традиционным App Bundle. Это разные сущности и процессы: документация о создании и отправке App Bundle в App Store Connect описывает группировку приложений для распространения, а не выбор единой модели доступа к подпискам. Если переносить привычную терминологию из старого процесса в новый без проверки, команда рискует настроить не тот объект и неверно оценить путь выпуска.
Один список до выбора
Перед обсуждением формата соберите текущие SKU в одном документе. Для каждой позиции укажите приложение, доступные функции, возможность отдельной покупки, владельца продукта и способ проверки права доступа. Отдельно зафиксируйте, что произойдёт с пользователем при отмене, истечении срока или смене плана: условия должны быть понятны и для приложения, и для поддержки.
Такой перечень помогает увидеть, например, что несколько подписок называются по-разному, но фактически открывают одну и ту же функцию. Или наоборот: одинаковый тариф в двух приложениях обещает разные права. Пока такие расхождения не устранены, выбор Bundle или Suite будет маскировать дефект продуктовой модели, а не решать его.
В чём основная разница между StoreKit Bundle и Suite? Bundle стоит оценивать как объединение подписок, которые сохраняют самостоятельный смысл и могут предлагаться по отдельности. Suite подходит для модели, где подписка представляет общий сервис в нескольких приложениях. Решение зависит не от количества приложений, а от того, как устроены покупка и права доступа.
Для одного приложения: отдельные планы или предложение набором
Если у вас один iOS App, начните с вопроса, остаются ли подписки полезными сами по себе. Например, два плана могут покрывать разные задачи и иметь собственные страницы покупки. Тогда объединённое предложение может дать пользователю дополнительный вариант, не обязательно отменяя выбор отдельных планов. В таком сценарии первым кандидатом для оценки обычно будет Bundle.
Suite не становится предпочтительным автоматически из-за того, что у приложения несколько уровней доступа. Если пользователь покупает подписку только для одного приложения, а других приложений или общего сервиса нет, проверьте, соответствует ли Suite реальному продукту. Не подменяйте продуктовую структуру терминологией нового механизма.
Подойдёт ли Bundle независимому разработчику с одним приложением? Да, его стоит оценить, если подписки можно продолжать продавать отдельно, а объединённая покупка решает конкретную задачу пользователя. Если же планы дублируют друг друга или комбинированное предложение не имеет ясной выгоды, сначала пересмотрите каталог и описание прав, а не добавляйте новый вариант ради самой функции.
| Состояние подписок в одном приложении | Что оценить сначала | Причина |
|---|---|---|
| Каждый план открывает отдельный набор возможностей | Bundle | Отдельные покупки сохраняют смысл, а набор может стать дополнительным способом покупки |
| Есть один общий доступ к функциональности | Текущую модель подписки и права | Несколько SKU могут оказаться лишними; объединение не исправит неясную структуру |
| Разные планы используют общую часть функций и отдельные дополнения | Матрицу прав и варианты покупки | До выбора нужно определить, какие возможности включены в набор и что доступно отдельно |
| Suite рассматривается только потому, что в StoreKit появились Suites | Сначала продуктовую границу | Наличие нового механизма не является основанием менять модель доступа |
Проверьте также поддержку и аналитику. Когда появляется комбинированная покупка, важно понимать, какой вариант выбрал пользователь и какие права должны быть активны. Поддержке нужны однозначные правила ответа на вопросы о составе подписки, а аналитике — разделение исходных планов и объединённого предложения. Не запускайте новый вариант, пока не сможете объяснить его состав без внутренних сокращений и условных названий SKU.
Для нескольких приложений: единая подписка не означает Suite автоматически
Для портфеля приложений ключевой вопрос звучит иначе: пользователь хочет купить права в одном приложении или получить связанный доступ во всей группе? Если продукты остаются самостоятельными и подписки можно приобретать по отдельности, Bundle может лучше соответствовать такой модели. Если же вы создаёте единый сервис, который должен работать в нескольких приложениях как одна подписка, рассмотрите Suite и заранее согласуйте, как каждое приложение распознаёт права.
Составьте матрицу «подписка — приложение — право». Укажите, какая функция открывается после покупки и какие приложения должны принять это право. Это покажет, где нужно менять логику интерфейса, восстановления покупок и серверной проверки. Даже если покупка оформляется через StoreKit, каждое приложение должно корректно отреагировать на результат и показать именно обещанный доступ.
Когда нескольким приложениям нужен Suite, а не Bundle? Когда вы продаёте их как части одной услуги и подписка должна предоставлять согласованный доступ между ними. Если приложения сохраняют самостоятельную покупку и собственные подписки, Suite не следует выбирать только по признаку «их больше одного». Сначала зафиксируйте продуктовую границу, затем соотнесите её с возможностями, описанными Apple.
До разработки проверьте крайние случаи: пользователь установил только одно приложение; купил доступ в другом; восстановил покупку после переустановки; сменил план; отменил продление. Для каждого состояния определите ожидаемое поведение интерфейса и источник истины для прав. Такой разбор особенно важен, когда приложения выпускаются разными командами: общий платёжный продукт без общего контракта на права быстро приводит к разным трактовкам одной покупки.
Для сотрудничества между разработчиками: договорённость не равна разрешению
Apple относит предложения, объединяющие подписки разных разработчиков, к multideveloper Bundle. Это отдельный вариант для оценки, а не автоматическое следствие партнёрства. До заявки перечислите участников, принадлежащие им подписки и права, которые должен получить покупатель. Затем договоритесь, кто поддерживает каждую часть предложения, кто обрабатывает вопросы пользователей и как участники сообщают об изменениях.
Особое внимание уделите договорным условиям. Официальная информация Apple предусматривает заявку и последующую конфигурацию, в том числе необходимые документы и дополнительное юридическое соглашение. Наличие заинтересованных партнёров не означает, что предложение уже одобрено или может быть опубликовано. Проверяйте текущие требования в официальном описании Bundles и Suites и не включайте предполагаемую дату запуска в план как подтверждённую.
| Этап сотрудничества | Что подготовить | Условие перехода дальше |
|---|---|---|
| Определение состава | Список участников, приложений, подписок и прав | Каждый участник подтвердил свою часть предложения |
| Распределение ответственности | Поддержка, обработка вопросов, порядок уведомления об изменениях | Нет спорных зон ответственности между командами |
| Подача заявки | Сведения и документы, затребованные Apple | Заявка отправлена, но команда не считает это одобрением |
| Ответ и дополнения | Проверка полученного подтверждения и запросов на материалы | Все затребованные сведения переданы |
| Конфигурация и выпуск | Настройки StoreKit и App Store Connect, проверка покупок | Права и пользовательский путь проверены до публикации |
Не формируйте общий каталог, пока не согласованы правила на случай выхода партнёра из проекта или изменения его подписки. Если пользователь купил объединённое предложение, а один участник перестал предоставлять свою часть, заранее установленный процесс уменьшит неопределённость и для команды, и для покупателя. Это не только юридическая деталь: от неё зависит, какие права приложение должно показывать и как объяснять изменения.
Для миграции: StoreKit 2 и совместимость важнее названия API
Apple указывает, что для Bundles и Suites требуется StoreKit 2, а приложения должны соответствовать целевым версиям iOS 27, iPadOS 27, macOS 27 или tvOS 27 и новее. Эти требования относятся к доступу к новому механизму. Они не означают, что ради его оценки обязательно переписывать всё приложение. Сначала проверьте, как сейчас загружаются продукты, обрабатываются транзакции и подтверждаются права; затем определите объём изменений именно в нужных местах.
Какие системы нужны для использования StoreKit Bundles? Проверьте целевую платформу и её минимальную версию: в официальных требованиях перечислены iOS 27, iPadOS 27, macOS 27 и tvOS 27 или более поздние версии. Также требуется StoreKit 2. Сверяйте условия с актуальной документацией перед изменением настроек проекта: версия Xcode сама по себе не заменяет системное требование для приложения.
| Проверка перед миграцией | Что выяснить | Какое решение принять |
|---|---|---|
| Текущая интеграция | Использует ли приложение StoreKit 2 в нужном сценарии | Выделить отсутствующие части, не планируя полную переделку без необходимости |
| Поддерживаемые платформы | Какие целевые системы заявлены для каждого приложения | Определить, затрагивает ли запуск только новую аудиторию или требует пересмотра поддержки |
| Модель прав | Где и как приложение узнаёт о действующем доступе | Согласовать одинаковые правила для всех приложений в наборе |
| Интерфейс покупки | Как пользователь увидит состав и условия предложения | Проверить соответствие экранов фактической конфигурации |
| Выпуск и проверка | Какие действия выполняются в Xcode, а какие — в App Store Connect | Разделить тестирование реализации и настройку магазина |
Практический порядок миграции может быть таким:
- Зафиксируйте исходное состояние. Составьте перечень продуктов, идентификаторов, приложений и прав. Отметьте, какие подписки продаются отдельно и какие сценарии уже работают в выпускной версии.
- Проверьте используемый StoreKit. Просмотрите код получения продуктов, обработки транзакций и обновления доступа. Сопоставьте его с документацией StoreKit 2 и требованиями нового предложения.
- Опишите пользовательский сценарий. Запишите, что покупатель видит до покупки, какой результат ожидает после неё и что происходит при восстановлении или изменении подписки.
- Выберите тип предложения. Примените условия выбора ниже, затем зафиксируйте аргумент: почему объединённое предложение лучше отдельных покупок или общей подписки.
- Проверьте платформенную совместимость. Сопоставьте целевые системы и настройки проекта с опубликованными требованиями Apple. Учитывайте каждое приложение, которое должно предоставлять права.
- Подготовьте заявку и материалы. Для предложений, требующих участия Apple, отделите отправку заявки от получения подтверждения и выполнения последующих запросов.
- Настройте App Store Connect и проведите приёмку. Сверьте конфигурацию магазина, экран покупки, результат транзакции и фактическую выдачу прав в приложениях. Только после этого планируйте выпуск.
Условные ветви выбора: что делать на этой неделе
Используйте этот список как первичную развилку, а не как замену проверке текущей документации:
- Если подписки остаются доступными по отдельности, а покупателю нужен их набор, сначала оцените Bundle. Если объединение размывает различия между планами, вернитесь к отдельным предложениям.
- Если один план должен открывать согласованный сервис в нескольких приложениях, оцените Suite. Если приложения продаются независимо и права различаются, сначала уточните продуктовую границу.
- Если в предложении участвуют другие разработчики, рассматривайте multideveloper Bundle и распределите права и обязанности. Если участники не согласовали ответственность, отложите конфигурацию.
- Если приложение ещё не использует StoreKit 2 или целевые системы не соответствуют требованиям, сначала оцените объём совместимости. Не выдавайте локальный эксперимент за готовый путь публикации.
- Если заявка ещё не подтверждена или настройка магазина не завершена, не обещайте дату запуска и не считайте тест API доказательством готовности продукта.
На этой неделе соберите список SKU и матрицу прав, затем назначьте ответственных за платформенную проверку, заявку и приёмку. Такой небольшой план помогает отделить решение о продукте от работ по реализации и от действий в App Store Connect.
Xcode 27 и App Store Connect: тестирование не завершает настройку
В докладе Apple для разработчиков о возможностях StoreKit показано тестирование соответствующих сценариев в среде StoreKit в Xcode 27. Используйте локальные тесты, чтобы проверить поведение кода и обработку покупок, но не трактуйте успешный тест как доказательство завершённой конфигурации магазина. Это разные этапы: локальная среда проверяет реализацию, а настройки и заявка относятся к процессу публикации.
Apple отдельно описывает настройку StoreKit Testing в Xcode и проверку StoreKit на разных этапах разработки. Разделите приёмку на три части: локальная проверка логики, проверка сценария покупки в доступной тестовой среде и подтверждение того, что конфигурация App Store Connect соответствует итоговому продукту.
При тестировании заведите отдельные результаты по приложениям. Для каждого запишите, какой набор продуктов был выбран, какой результат покупки получен и какие права появились. Затем проверьте отмену, восстановление и переход между состояниями там, где это предусмотрено вашим сценарием. Не ограничивайтесь тем, что транзакция прошла: важен конечный результат в каждом приложении, которому обещан доступ.
Для автоматизации тестов или удалённой проверки сначала убедитесь, что ваша среда действительно поддерживает нужную версию Xcode и целевую платформу. Локальный Mac удобен, если он уже готов и доступен команде. Если подходящего macOS-окружения нет, перед арендой уточните доступную конфигурацию и способ подключения: сам факт удалённого доступа не подтверждает совместимость с требуемым Xcode и сценарием StoreKit.
Следующий шаг: закрепите выбор до подготовки выпуска
Сравните не только Bundle и Suite, но и текущий вариант без объединённой покупки. Для решения нужны каталог продуктов, матрица прав и сценарии перехода между приложениями. После этого проверьте требования StoreKit 2 и платформ, а затем разнесите локальные тесты, заявку и конфигурацию App Store Connect по отдельным контрольным точкам.
Если сейчас вы проверяете подписки только на личном Mac, у такой схемы есть практические ограничения: машина может быть занята другими задачами, окружение сложнее воспроизводить для команды, а постоянная доступность не гарантируется. Покупка отдельного Mac снимает часть этих проблем, но требует вложений в оборудование и обслуживания. Перед выбором временного удалённого окружения сопоставьте стоимость и период аренды с планом проверок в тарифах VMSPIN, а доступные варианты подключения посмотрите на странице заказа Mac. Если вам нужно временное macOS-окружение для проверки реализации или сборки, аренда Mac у VMSPIN может быть удобнее покупки отдельной машины: перед заказом сверьте версию macOS и Xcode с требованиями проекта.