Как справиться с ограничениями загрузки On-Demand Resources в 2027 году? 2026

Не отключайте On-Demand Resources во всех приложениях сразу: сначала установите, затрагивает ли проект новое правило загрузки, затем подготовьте миграцию на Background Assets там, где она необходима. Это решение подходит командам, которые проверяют релиз приложения, доставку игровых ресурсов или Apple-платформенный CI.

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

Обновлено 12 ноября 2026 года; сведения сверены с объявлением Apple в App Store Connect об ограничениях ODR, документацией Apple по ODR и руководствами Background Assets.

Сначала отделите правило загрузки от статуса уже выпущенного приложения

Apple объявила, что с начала 2027 года App Store Connect не будет принимать загрузки, содержащие On-Demand Resources, от новых приложений, а также от приложений, которые ранее не использовали ODR. В объявлении указано начало года, но не конкретный день. Поэтому зафиксируйте текущую категорию приложения и не планируйте выпуск, исходя из самостоятельно выбранной даты. Подробности области действия приведены в описании ограничения загрузок ODR.

Здесь важно не смешивать три разных утверждения:

• ODR объявлена устаревающей технологией для новых версий платформ.
• Для определённых приложений меняются условия приёма загрузок, содержащих ODR.
• Это не означает, что уже выпущенное приложение, использующее ODR, немедленно перестанет запускаться или получать ресурсы.

Apple указывает, что ODR устаревает начиная с iOS 27, iPadOS 27, tvOS 27 и visionOS 27, и рекомендует переходить на Background Assets. Это статус технологии в платформах. Ограничение загрузки — отдельное правило App Store Connect. Для приложения, которое уже использует ODR, Apple также сообщила о возможности продолжать работу в ближайшей перспективе. Это не обещание бессрочной поддержки, поэтому миграцию стоит планировать, но не следует трактовать изменение как требование немедленно снять приложение с продажи.

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

Определите категорию проекта по архиву и истории выпусков

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

Отметьте каждый пункт перед выбором дальнейшего пути:

• [ ] Проверьте настройки target и проекта. Найдите включение On-Demand Resources и связанные с ним параметры ресурсов. Учитывайте все конфигурации сборки: Debug, Release и варианты для отдельных схем.
• [ ] Проверьте архив, предназначенный для загрузки. Установите, содержит ли он ODR-ресурсы или соответствующие пакеты. Проверка исходников без проверки итогового архива не закрывает этот вопрос.
• [ ] Изучите историю приложения в App Store Connect. Уточните, использовались ли ODR в уже выпущенных версиях именно этого приложения. Не считайте локальный тест или неотправленную сборку доказательством прежнего использования в распространявшемся приложении.
• [ ] Сопоставьте результат с новым правилом. Если приложение новое или ранее не использовало ODR, загрузка с ODR попадает в описанную Apple категорию ограничения. Для такого проекта планируйте выпуск без этих ресурсов.
• [ ] Зафиксируйте решение в релизной документации. Запишите, кто проверил архив, какую схему доставки выбрала команда и какие тесты подтверждают доступность контента.

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

Перенесите не теги, а логику выдачи ресурсов

Миграция On-Demand Resources на Background Assets — изменение архитектуры доставки. Старый тег не превращается автоматически в новую сущность, а вызов NSBundleResourceRequest не получает эквивалентную замену простой сменой имени. Документация Apple описывает NSBundleResourceRequest как API прежней модели ресурсов; посмотрите его назначение и доступные методы, прежде чем убирать вызовы.

Сначала составьте инвентаризацию ODR. Для каждого тега укажите:

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

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

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

Выберите модель asset packs по контролю и ответственности

Для Background Assets нужно решить, кто хранит и раздаёт пакеты, как приложение узнаёт о доступном ресурсе и как команда поддерживает связь между версиями приложения и контентом. Apple документирует создание Managed asset packs, настройку загрузки Apple-hosted asset packs и конфигурацию проекта с самостоятельно размещаемыми пакетами в руководстве по unmanaged Background Assets.

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

Также определите реакцию на прерывание загрузки. Экран, который зависит от крупного пакета контента, должен иметь понятное состояние ожидания, возможность повторить операцию и безопасный путь возврата. Для игровых проектов отдельно проверьте, не теряется ли прогресс при недоступности пакета. Для CI зафиксируйте, какая версия приложения и какие пакеты использовались во время теста.

Проведите локальную проверку и отдельную проверку распространения

Apple предоставляет сценарий локального тестирования asset packs с mock server, поставляемым с Xcode. Следуйте официальной инструкции локального тестирования Background Assets. Локальный тест помогает проверить поведение клиента при работе с тестовыми ресурсами. Он не доказывает, что производственная загрузка настроена правильно, и не означает, что приложение пройдёт проверку App Store.

Разделите проверку на последовательные этапы:

1. Подготовьте тестовый набор. Выберите пакет, покрывающий основной сценарий приложения, и отдельный сценарий с ошибкой или повторным запросом. Включите ресурсы, для которых важны порядок доступности и обработка состояния.
2. Соберите приложение и пакеты в Xcode. Проверьте настройки целевой конфигурации и убедитесь, что тестируется актуальная сборка. Не сравнивайте результаты старого архива с изменёнными пакетами, не фиксируя их версии.
3. Запустите локальный mock server. Настройте тестирование по документации Apple и пройдите путь от запроса пакета до момента, когда приложение может прочитать ресурс.
4. Проверьте состояния приложения. Убедитесь, что интерфейс не обращается к файлу до его доступности. Проверьте повторный запрос после ошибки и восстановление сценария после повторного запуска.
5. Проверьте выбранный способ хостинга. Для Apple-hosted пакетов проверьте процесс загрузки и связь с приложением. Для самостоятельно размещаемых пакетов отдельно проверьте конфигурацию клиента и фактическую доступность ресурса.
6. Пройдите путь распространения проекта. Выполните реальный релизный или бета-процесс, который использует команда, и проверьте пакет вместе с приложением в этом процессе. Для Apple-hosted пакетов изучите процедуру тестирования asset packs через TestFlight.
7. Сохраните протокол приёмки. Запишите версию Xcode, сборки и пакетов, выбранную модель размещения, результат локальной проверки и результат проверки распространения. При сбое укажите, на каком этапе ресурс перестал быть доступен.

Локальная проверка и распространение отвечают на разные вопросы. Mock server позволяет воспроизвести работу клиентского сценария в локальной среде. Реальная проверка выпуска показывает, как собранный продукт ведёт себя в выбранном процессе дистрибуции. Не объединяйте эти результаты в один статус «прошло»: иначе команда не сможет понять, проблема в коде загрузки, в пакете или в конфигурации публикации.

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

Используйте контрольный список перед миграционным релизом

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

• [ ] Категория приложения установлена по истории выпуска, а не по предположению.
• [ ] Архив проверен на фактическое наличие ODR, включая все используемые конфигурации.
• [ ] Для каждого старого тега записано, какие экраны, уровни или функции от него зависят.
• [ ] Вызовы NSBundleResourceRequest сопоставлены с точками использования ресурсов и обработчиками ошибок.
• [ ] Новая схема группирует пакеты по времени и условию доступности, а не копирует старые теги.
• [ ] Определено, кто отвечает за хостинг и поддержку выбранной модели.
• [ ] Код не использует ресурс до подтверждения его локальной доступности.
• [ ] Локальный тест через mock server и проверка процесса распространения сохранены как отдельные результаты.
• [ ] План выпуска учитывает будущие уточнения Apple, поскольку точная дата начала ограничения пока не названа.

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

Частые вопросы о переносе ресурсов

Когда App Store Connect перестанет принимать такие загрузки?

Apple указывает начало 2027 года, но не публикует конкретную календарную дату. Ограничение относится к содержащим ODR загрузкам новых приложений и приложений, которые прежде не использовали функцию. Перед релизом сверяйте актуальное объявление App Store Connect: если Apple обновит дату или область действия, нужно пересмотреть релизный план, а не опираться на прежнюю оценку.

Нужно ли срочно переносить действующее приложение?

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

Можно ли заменить NSBundleResourceRequest на Background Assets без переписывания логики?

Нет, рассчитывать на автоматическую замену нельзя. Старые запросы связаны с ODR, а Background Assets требуют пересмотреть структуру asset packs, момент получения ресурса и логику его готовности. Код, который показывает контент сразу после завершения прежнего запроса, может нуждаться в изменении. Мигрируйте по сценариям использования и отдельно проверяйте недоступность пакета.

Как проверить Background Assets локально в Xcode?

Используйте mock server, который поставляется с Xcode, и следуйте инструкции Apple по локальному тестированию asset packs. Пройдите запрос, получение данных и чтение файлов приложением, включая повторный запуск и обработку неудачного сценария. После этого проверьте реальный процесс распространения проекта. Локальная проверка подтверждает тестовый путь, но не заменяет проверку бета- или производственной поставки.

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

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