What to know
Apple’s Asset Library centralizes images and app previews so eligible media can be reused across product-page placements. That changes the planning unit: an asset is no longer only a file attached to one release. It is a named, reviewable item with a device specification and placement history.
Start with Apple’s reference data before exporting media. Record the asset kind, category, device class, pixel dimensions, file type, and locale scope. Treat the reference response as the source of truth for the current App Store Connect workflow, especially when a new iPhone size or paired-device class appears.
Use a deterministic upload record. Keep the source file name, checksum, reference name, target category, specification, uploader, date, processing state, and reviewer. An upload that has been accepted by the transfer endpoint is not necessarily ready for placement until Apple finishes processing it.
Separate the library asset from its placement. A screenshot or preview can be reusable, while a placement answers where that asset appears on a localized product page. This makes it easier to update one asset deliberately and see which page stories depend on it.
For Custom Product Pages, connect each placement to one audience and one campaign promise. For the default page, preserve the core product story. Do not use the library to multiply near-identical assets without a clear user question or a maintenance owner.
Review new device-size coverage as a compatibility check, not as permission to stretch an old image. Export at the required dimensions, inspect text at the target size, and verify that the screenshot shows the current build. A resized file can meet a pixel requirement while still producing weak or misleading product proof.
Keep an asset retirement rule. Archive or remove media when the feature, campaign, locale, supported device, pricing, or deep link changes. Before deleting an asset, list its placements and replace or remove those relationships so a page does not silently lose an important screenshot.
ASOgenic can read Apple’s reference data, upload and track library assets, and manage placements. Your team still owns the product truth, visual review, localization quality, and approval before a page is published.
Create a small asset manifest for every release or campaign. Include the library identifier, asset identifier, media kind, category, specification, locale, placement identifiers, source file, checksum, processing result, and reviewer. This gives the next person a reliable starting point when a device family or campaign changes.
Do not confuse an archived item with a corrected item. If the artwork is wrong, export and review a replacement, then update placements deliberately. If the asset is simply no longer needed, archive it after checking dependencies. Preserve the decision so an old campaign cannot silently reactivate stale media.
Use the new iPhone and paired-device classes as a design review trigger. Check safe areas, readable type, contrast, crop behavior, and the order of the story on the actual target canvas. The file can be technically valid and still fail to communicate the app’s main benefit.
For localized media, confirm that text, screenshots, preview narration, and deep-link destinations agree with the locale. A reusable asset should not be reused across markets when its copy, currency, feature availability, or cultural context makes the promise inaccurate.
Keep the library review-first. A successful API response means the server accepted the requested operation. It does not replace a human check of the rendered page, the linked app flow, or the evidence that the asset is suitable for the audience receiving it.
When a page is ready, archive the final manifest with the approved copy, build number, storefronts, locales, campaign link, and screenshots of the rendered result. That record makes future refreshes safer and helps explain whether a change came from the asset, placement, page story, or product itself.