В примечаниях Apple указано, что App Store Connect API 4.5.1 выпущен 6 октября 2026 года и помечает связанные ресурсы скриншотов, предварительных просмотров и материалов событий как устаревшие (официальные примечания к выпуску). Вывод для вашей автоматизации: новые интеграции сразу стройте на App Asset Library, а существующие планово переводите на модель «ресурс — placement» и проверяйте на каждом приложении. Пометка «устарело» сама по себе не означает, что интерфейс уже отключён или что все материалы нужно немедленно загружать повторно.
Кому пригодится: если вы автоматически загружаете снимки экрана или видео предпросмотра, здесь найдёте соответствие старых и новых ресурсов. Если вы сопровождаете несколько приложений или пользовательские страницы продукта, используйте критерии для поэтапной миграции. Если вы автоматизируете медиа для событий внутри приложения, проверьте, в какую сторону переносить операции с материалами событий.
Сначала определите, нужно ли начинать миграцию сейчас
Ключевой вопрос — не «работает ли старый запрос сегодня», а какую роль он играет в вашей системе и когда вам предстоит менять связанные процессы. В примечаниях Apple слово «устарело» описывает статус ресурсов; оно не устанавливает дату отключения. Не превращайте статус API в выдуманный дедлайн и не связывайте его с обязательной повторной загрузкой всего каталога.
Примените условия выбора:
- Если вы пишете новую интеграцию, используйте App Asset Library и модель placement с самого начала. Так вы не закрепите в новом коде зависимость от ресурсов, которые Apple уже пометила как устаревшие.
- Если у вас есть работающая автоматизация старых наборов, спланируйте миграцию по типам материалов и операциям. Сначала составьте инвентаризацию, затем перенесите и проверьте отдельный сценарий, не меняя одновременно весь конвейер публикации.
- Если ваша система не обращается к устаревшим ресурсам, не меняйте её только из-за номера версии. Проверьте фактические вызовы и продолжайте следить за документацией Apple.
- Если скоро запланирована публикация, не совмещайте перенос модели с релизом, если это можно развести по времени. Сначала проведите тест на редактируемом материале, подтвердите его отображение, а затем меняйте производственный путь.
| Критерий | Старые наборы материалов | App Asset Library | Решение для миграции |
|---|---|---|---|
| Связь материала с показом | Материал создаётся в контексте набора для заданного места | Материал хранится как ресурс, а место показа задаётся отдельно через placement | Пересмотрите код, который считает запись материала одновременно и файлом, и его местом в интерфейсе |
| Повторное использование | Структура привязана к прежней модели наборов | Один ресурс может связываться с различными местами показа, если это допускают возвращаемые данные и результат обработки | Сверьте локализацию, тип placement и фактическую пригодность ресурса перед повторной привязкой |
| Операции автоматизации | Набор, его материалы и порядок обходятся как связанная конструкция | Загрузка ресурса и управление его placements — отдельные части работы | Переносите чтение, создание, сортировку и очистку, а не только загрузку |
| Оценка риска при неполной миграции | Сохраняется скрытая зависимость от устаревшей модели | Новый подход требует явного учёта связей | Высокая, если старые вызовы используются для чтения или удаления; ниже, когда затронутый сценарий изолирован и проверен |
**Важно:** не используйте пометку «устарело» как сигнал немедленно удалить старые запросы. Сначала определите, какие именно пути кода их вызывают, и сохраните возможность восстановить прежний рабочий процесс, пока новый сценарий не прошёл проверку.
Сопоставьте старую модель наборов с App Asset Library
В прежнем подходе автоматизация обычно начиналась с целевого места показа: код находил или создавал набор, затем загружал относящиеся к нему снимки или видео. В App Asset Library файл и его представление на странице больше не являются одной и той же сущностью. Материал хранится в библиотеке как image или video, а placement связывает его с конкретным контекстом показа.
Это изменение влияет не только на названия ресурсов. Если ваша база данных хранит один идентификатор старого набора и считает его достаточной ссылкой на файл и позицию в интерфейсе, такой идентификатор нельзя механически переименовать. Модель данных должна отдельно отслеживать ресурс библиотеки и связи placement. Сверьте концептуальное соответствие со справкой Apple по управлению материалами App Store.
Чем App Asset Library отличается от старого API наборов скриншотов? В библиотеке сначала появляется ресурс, а затем отдельно задаётся место, где он должен быть использован. Благодаря разделению одна и та же запись изображения потенциально может участвовать в нескольких показах, но допустимость такой связи зависит от типа placement, локализации и данных, возвращаемых API. Не считайте повторное использование гарантированным лишь потому, что файл уже загружен.
Для переноса данных заведите явное соответствие:
- внутренний идентификатор файла вашего конвейера;
- идентификатор ресурса image или video в библиотеке;
- приложение и локализация, для которых готовится показ;
- идентификатор и тип placement;
- позиция в порядке отображения;
- состояние обработки ресурса и результат проверки в App Store Connect.
Проведите инвентаризацию всех операций, а не только загрузки
До изменения кода найдите каждый запрос к прежним ресурсам и отметьте, какое действие он выполняет. В небольшом проекте это может быть скрипт публикации; в команде — несколько отдельных задач для снимков, видео предпросмотра, пользовательских страниц и событий приложения. Ищите не только создание, но также чтение, обновление, удаление и сортировку.
Соберите карту миграции для каждого сценария:
- Скриншоты и видео версии приложения: установите, где код создаёт набор и как после этого получает порядок материалов.
- Пользовательские страницы продукта: выясните, привязаны ли исходники к конкретной странице и локализации либо используются повторно.
- Материалы экспериментов страницы продукта: проверьте, как автоматизация определяет вариант, читает текущий состав и очищает заменённые материалы.
- События внутри приложения: отдельно найдите операции с медиа события; не предполагайте, что переход для скриншотов автоматически покрывает этот сценарий.
- Общие библиотеки и фоновые задачи: проверьте код повторного использования, обработку ошибок и задания очистки, которые могут не содержать очевидных имён ресурсов.
Как перенести один снимок на страницы с разной локализацией? Сначала отделите файл от конкретного места показа, затем получите поддерживаемые варианты placement и создайте отдельные связи для нужных контекстов. Перед повторным использованием проверьте, что язык страницы и тип показа соответствуют назначению изображения. Не копируйте старую привязку набора вслепую: библиотека хранит материал отдельно, но требования конкретного placement определяются возвращаемыми данными и результатом обработки.
Получайте сведения о placement и характеристиках из API
Новый код не должен считать перечень устройств, групп размещения, размеров файлов или ограничений неизменным. Вместо жёстко прописанного списка сначала запрашивайте доступные справочные данные API для соответствующего приложения и контекста. Документация по загрузке материалов в App Store Connect служит точкой сверки процесса передачи; детали допустимых связей и форматов проверяйте по актуальным ответам API.
Как учитывать IPHONE_DUO? Apple документирует IPHONE_DUO как категорию показа материалов, но наличие этой категории не означает, что каждый ресурс можно прикрепить к любому placement с таким названием. Включите её в обнаружение возможностей: прочитайте справочные данные, запишите доступный тип размещения и его группу, а затем проверьте фактический ответ при создании связи. Если API не возвращает нужный вариант для приложения или конкретного материала, не обходите ограничение значением, зашитым в код.
Практическая последовательность здесь такая:
- Запросите актуальные справочные данные для доступных групп и типов placements.
- Сопоставьте полученный ответ с целевым приложением, страницей и локализацией.
- Валидируйте требования к материалу по возвращаемым характеристикам, а не по старой локальной константе.
- Сохраняйте исходный ответ или его значимые поля вместе с журналом миграции, чтобы позднее выяснить, почему определённая связь была допустима или отклонена.
- При изменении справочных данных выдавайте контролируемую ошибку и требуйте повторной проверки, а не молча выбирайте «ближайший» тип показа.
Перенесите привязки, сортировку и очистку как единый сценарий
Старый конвейер часто связывает загрузку и дальнейшие действия через набор. В новой модели после загрузки следует отдельно управлять placements: ресурс может быть готов, но ещё не связан с нужной страницей; связь может существовать, но порядок показа нуждается в проверке. Поэтому разделите состояния в коде и в журнале выполнения.
Перед записью нового материала проверьте, есть ли у вас уже сохранённый идентификатор ресурса библиотеки и можно ли безопасно использовать его повторно. После загрузки дождитесь обработки, сохраните идентификатор ресурса и создайте необходимые placements. Для каждого placement записывайте контекст и локализацию, а не только общий статус задачи.
Порядок сортировки тоже требует отдельной проверки. Успешное создание связей не доказывает, что экран показывает снимки в желаемой последовательности. Перед очисткой старых данных выясните, какие связи ещё используют ресурс. Не переносите старую операцию удаления набора на новую сущность без проверки: при раздельных ресурсах и placements удаление только одного объекта может оставить лишнюю связь либо завершиться ошибкой из-за оставшихся зависимостей.
**Совет для безопасного отката:** держите соответствие «локальный файл — ресурс библиотеки — placement» в журнале миграции. Если шаг создания связи завершился неудачно, вы сможете повторить именно его, не загружая тот же файл заново и не удаляя материал, который всё ещё нужен другой странице.
Проверьте миграцию от загрузки до отображения
Для первой проверки выберите редактируемый сценарий, в котором можно проследить весь путь материала. Не начинайте с массового переноса каталога: ошибка в модели идентификаторов или порядке удаления тогда затронет больше данных, а причина сбоя будет менее очевидной.
Проверяйте по шагам:
- Зафиксируйте исходные файл, приложение, локализацию и целевое место показа. Запишите, какой снимок или видео должен появиться и в какой последовательности.
- Создайте ресурс в App Asset Library и сохраните идентификатор, возвращённый API. Успешная передача файла означает лишь, что запрос принят; она ещё не подтверждает, что обработка закончилась.
- Опросите или прочитайте состояние ресурса предусмотренным API способом. Сверьте его с документированными статусами материалов App Store; при ошибке остановите создание placements и сохраните сведения о причине.
- Получите справочные данные, выберите допустимый placement и создайте связь с нужной страницей и локализацией. Запишите ответ API отдельно от статуса самого ресурса.
- Проверьте порядок размещённых материалов через чтение состояния, предусмотренное API. Не полагайтесь на порядок файлов в локальном каталоге или на последовательность отправки запросов.
- Откройте соответствующий раздел App Store Connect и подтвердите, что выбрана ожидаемая страница, язык и набор материалов. Сверьте результат интерфейса с журналом API.
- Отдельно отметьте, что именно подтверждено: загрузка, обработка, создание placement и отображение. Не обозначайте всё это одним статусом «успешно» и не делайте вывод об одобрении или доступности в магазине по факту загрузки.
Для автоматизации, исполняемой на macOS, среда выполнения должна иметь доступ к проекту, секретам и журналам, а прерывание удалённой сессии не должно превращать частично завершённый перенос в неотслеживаемую задачу. Для подготовки такого контура пригодится руководство по удалённому Mac. Само обращение к App Store Connect API не требует удалённого Mac; он уместен, когда ваши скрипты, инструменты подготовки медиа или другие этапы публикации должны выполняться в macOS.
Выберите среду исполнения после проверки требований
Локальный Mac удобен, если публикации редки, рабочая машина доступна в момент запуска и нет потребности в отдельном постоянно готовом исполнителе. Но он связывает автоматизацию с доступностью одного компьютера, его свободным диском и сохранностью локальных секретов. Обычный сервер может выполнять сетевые запросы API, однако не заменит macOS для тех частей процесса, которые зависят от инструментов Apple.
Если вы публикуете часто или хотите отделить релизные задачи от личной машины, сравните фактические требования: нужна ли автоматизациям macOS, кто обслуживает обновления и где хранятся ключи. Не переводите процесс только ради «облачности»: удалённый Mac не исправит неверные placements, ошибки обработки или неполную модель данных. Если после аудита выяснится, что вам нужен именно доступный извне macOS-контур, изучите варианты аренды Mac и сравните их с поддержкой собственного оборудования.
Завершите миграцию проверяемым критерием
Для каждого типа материалов у вас должны быть ответы на три вопроса: какие старые вызовы заменены, какие новые записи и связи создаются, как подтверждается итоговое отображение. Держите раздельные статусы загрузки, обработки, placement и выбора материала на странице; фиксируйте справочные данные, по которым принималось решение о размещении. Это позволит планировать перенос без предположения о не объявленном Apple сроке отключения.
Если сегодня процесс держится на ручном запуске с личного компьютера, его слабые места — зависимость от доступности устройства, разрозненное хранение секретов и сложность повторного выполнения после частичного сбоя. Для редких публикаций достаточно локального контура с аккуратным журналированием; для регулярных задач, которым действительно нужны инструменты macOS, аренда удалённого Mac у MACGPU может быть удобнее покупки отдельной машины. Выбирайте её только после миграционной проверки: надёжная среда исполнения помогает запускать автоматизацию, но корректность App Asset Library и placements всё равно подтверждается ответами API и состоянием материалов в App Store Connect.
Последняя проверка: 15 октября 2026 года. Дата выпуска и статус устаревания сверены с примечаниями Apple к API 4.5.1; модель и материалы — с документацией Apple по управлению ресурсами и руководством по загрузке.