Apple’s release notes date App Store Connect API 4.5.1 to October 6, 2026, and mark legacy screenshot, preview, and certain in-app event asset resources as deprecated (Apple’s 4.5.1 release notes).
Symptom: Your media automation still creates screenshot sets and uploads files through the older resource model. Fastest fix: Use App Asset Library for new integrations; plan existing integrations around assets and placements, then verify upload, placement, and ordering for each app. Deprecated does not mean shut down.
Who should read this: Independent developers who automate App Store screenshots or preview videos and need to map old calls to the new model. Small teams maintaining several apps, custom product pages, or in-app event media who need a controlled migration and acceptance plan.
_Last updated October 15, 2026; checked against Apple’s API 4.5.1 release notes, App Asset Library migration guidance, API reference material, and App Store Connect asset documentation._
Set migration priority for App Store Connect API 4.5.1 screenshot interfaces
Do not start by replacing every endpoint in your codebase. First decide whether you have an affected workflow, which media it handles, and whether a release is already in progress. Apple has marked relevant older resources as deprecated, but the release notes do not establish that they have stopped working or set a removal deadline. Use the release notes to confirm the status rather than treating the deprecation label as an outage notice.
Use these conditions to choose the next action:
- If you are building a new integration, use App Asset Library. Avoid creating a new dependency on a resource model Apple has marked deprecated.
- If an existing job reads, uploads, updates, deletes, or orders legacy screenshots, previews, or affected event media, plan a migration. Keep the current path available during validation; do not replace it just because an upload call succeeds in a test.
- If your automation does not touch the deprecated resources, leave it unchanged for now. Record what it does use, and recheck Apple’s reference material when you next change the workflow.
- If you have an imminent release, avoid mixing a broad API rewrite with the release itself. Test the new flow against an editable app or page first, then schedule the production switch around your release controls.
| Situation | Migration priority | Runbook action |
|---|---|---|
| New automation | High | Build against App Asset Library and placement references from the start. |
| Existing automation uses affected resources | Planned | Inventory every operation, map it, and validate a parallel path before switching. |
| Existing automation does not use affected resources | Low | Confirm the boundary and avoid an unrelated rewrite. |
| Release already in progress | Controlled | Protect the release path; test migration separately before production cutover. |
Separate stored assets from storefront placements
The key model change is that media and its presentation destination are no longer the same concept. In the older set-based approach, a workflow commonly creates a media set for a particular destination and manages files through that set. With App Asset Library, you store an image or video as an asset, then use a placement to associate eligible media with a destination and localization. Apple’s App Store asset management guidance provides the migration context and terminology.
| Old workflow concept | App Asset Library concept | What to change in your integration |
|---|---|---|
| Screenshot set | Image asset plus placement | Store the asset identity separately from its destination. |
| Screenshot resource | Image asset | Track processing and asset identity; do not infer storefront display from upload alone. |
| Preview set | Video asset plus placement | Keep the video record separate from the placement that selects it. |
| Preview resource | Video asset | Verify the asset’s processing result and its later placement association. |
| Destination-specific media association | Placement | Record destination, localization, and ordering as placement data. |
That mapping also makes retries safer. If a request fails after an asset has been created but before the placement is confirmed, a job that records only “upload failed” may upload a duplicate on its next run. Persist the asset identifier and current workflow state before retrying the placement step. Before deleting anything, determine whether the asset is still referenced by another placement.
Inventory every media operation before changing calls
A migration that replaces only the upload call is incomplete. Your automation may also read existing media to avoid duplicates, update a selection, reorder displayed items, or clean up records left behind by a previous release. Review each operation in the source code, scheduled jobs, and any manual recovery script.
| Media workflow | Calls and behaviors to inventory | Migration check |
|---|---|---|
| App Store version screenshots and previews | Read current media, upload files, check processing, choose display order, remove obsolete records | Map each old set and file operation to the asset and placement operations available for that destination. |
| Custom product page media | Read page selections, upload or reuse assets, update placements, verify localization | Confirm the page and localization are represented by the returned placement data. |
| Product page experiment media | Identify experiment variants, select media, change ordering, remove test assets | Keep variant-to-placement mapping explicit; verify the intended page receives the intended media. |
| In-app event media | Create or update event assets, inspect processing, remove replaced media | Check the specific deprecated resource family and its supported App Asset Library replacement. |
Also check cleanup logic. A legacy set may have been the unit your script deleted after replacing media. In the new model, the asset and its placements have separate roles. Deleting an asset without checking its placements can fail or remove media still used elsewhere; deleting a placement does not necessarily mean the underlying asset should be discarded. Confirm the supported operation and relationship in the current App Store Connect API reference for uploading assets, then test your cleanup path on non-production content.
Discover supported placements and formats at runtime
Do not turn the first successful migration into a permanent list of supported devices, placement groups, image dimensions, or media limits. Those are compatibility inputs, not safe assumptions to hard-code indefinitely. Query the API reference data for the app and use the returned placement types, placement groups, and specifications to decide what your job can create.
API 4.5.1’s reference material includes the IPHONE_DUO display category. Treat that as a category your integration can discover, not as evidence that every asset is eligible for every placement. The returned reference data and the result of processing a particular asset determine what the workflow can actually use. Apple’s asset status documentation is also useful when distinguishing an uploaded resource from one that has reached a usable status.
A robust capability check should:
- Fetch the relevant reference data for the app and the operation you intend to perform.
- Compare the returned placement groups and specifications with the media your pipeline can generate.
- Skip unsupported combinations with a logged reason instead of guessing a destination.
- Keep the discovered capability data alongside the migration run so you can explain why a placement was or was not created.
- Recheck the data when the app, destination, or media type changes.
Migrate reuse, ordering, and cleanup as separate responsibilities
When the same source image is intended for more than one localized page, upload or identify the asset once, then create a placement for each destination that the API reference data allows. Do not assume that a placement created for one localization automatically selects the media for another. Store each placement ID and its localization separately, even if both point back to the same asset.
Ordering needs its own test. A successful placement response does not prove the page will show assets in the sequence your script expects. Read back the placement state where supported, compare it with the intended order, and confirm the visible selection in App Store Connect. Make ordering idempotent: rerunning the job should restore the desired order, not append another copy or leave conflicting records.
Before enabling automatic deletion, define a cleanup policy that follows the new relationships:
- Mark the replacement asset and placement as active before removing an obsolete association.
- Check whether an asset is reused by another page or localization.
- Remove the destination association and the stored asset through the supported operations and in a tested order.
- Record a failed cleanup separately from a failed upload, so a retry does not recreate already-valid media.
- Keep a local-to-remote mapping and enough request identifiers to trace which job changed each placement.
Verify the full path before switching production
Run a controlled migration against an editable app media destination. The acceptance target is not “the upload request returned success.” You need evidence for asset creation, processing, placement association, ordering, and the page’s selected media. Keep API responses and the App Store Connect state as separate records so you can distinguish an API-level success from a later processing or display issue.
Use this sequence:
- Capture the baseline. Record the existing page, localization, media selection, and order. Save the local file identity and the old resource IDs needed for comparison.
- Discover current capability data. Fetch the supported placement types, groups, and specifications for the target app. Check the intended image or video against the returned requirements.
- Create or identify the asset. Upload the media through the new flow, preserve the returned asset identity, and poll or inspect status according to the documented workflow.
- Create the placement. Associate the processed asset with the intended destination and localization. Record the placement ID and the API result.
- Verify ordering and selection. Check the saved order, then inspect the editable page in App Store Connect to confirm the intended media appears in the intended location.
- Exercise retry and cleanup. Interrupt or repeat the test at a safe point, confirm the job does not create duplicate records, and verify that obsolete placements can be cleaned up without removing reused assets.
- Separate release outcomes. Record upload success, processing completion, placement state, page selection, and any review or publication status independently. A media upload does not mean the page has been published or approved.
FAQ: Resolve common migration decisions
What did API 4.5.1 deprecate?
Apple marks legacy screenshot-set, screenshot, preview-set, and preview resources as deprecated, along with certain in-app event asset resources. Check the release notes and current reference for the exact resources your code uses. The deprecation notice is not proof that those resources have stopped working, and it does not provide an unannounced shutdown date. Plan migration based on actual usage.
How is App Asset Library different from screenshot sets?
The older workflow centers media management on destination-specific sets. App Asset Library separates the stored image or video from the placement that associates eligible media with a destination and localization. Your code should therefore track both the asset and its placements. A successful asset upload alone does not establish which storefront page displays it or in what order.
How can one screenshot serve more than one localization?
Keep one asset record and create a separate placement for each eligible localized destination, using the placement types and groups returned by API reference data. Do not assume that every localization accepts the same asset or that a placement is automatically shared. Record each placement ID and verify the selected media on the corresponding editable page.
How do you validate placement order?
Check the API result for placement creation and ordering, then read back the saved state where supported. Inspect the App Store Connect page to confirm the displayed selection and sequence. Track upload, processing, placement, and page state separately. If an upload succeeds but the page is unchanged, debug the association and order rather than treating the upload response as proof of completion.
For teams whose scripts also build, sign, or publish releases on macOS, a remote Mac can provide a persistent execution environment; it is not required just to call the App Store Connect API. A self-managed Mac can mean hardware cost, maintenance, and capacity sitting idle between releases. Renting can be a more flexible option when you need a real macOS environment temporarily or for a continuously running release worker, while a machine you already own may be the better choice for steady workloads or workflows that need local physical connections. Review MACGPU’s remote Mac options and available Mac configurations only if your automation has that macOS execution need.