Symptom: Screenshots or creative assets appear in Asset Library, but you cannot tell whether they are actually live on the intended product page.
Fastest fix: Track library storage, review status, and page configuration as separate checks; verify the language, device specification, and destination before marking release assets complete.
This guide is for indie developers preparing store assets, teams maintaining localized app listings, and release leads coordinating review and publication.
If you only need to upload one asset and already know its destination, use Apple’s current upload instructions first.
If you own the handoff, localization, or final release check, follow the workflow below.
Last updated: October 26, 2026. The current-state notes are checked against Apple’s App Store Connect release notes and the linked Apple Help documentation.
Manage App Store Connect Asset Library materials by release role
Asset Library helps you organize and reuse screenshots, app previews, and creative assets across supported platforms, sizes, and display locations. Apple also documents that assets can be uploaded and submitted for review separately from an app version. That does not mean an asset has been configured on a product page, or that the page is ready to publish. Treat those as separate release states. See Apple’s Asset Library guide and its instructions for submitting library assets.
The useful working distinction is:
- In the library: The file is available for management or reuse.
- Submitted or reviewed: The asset has a review status. Check the status shown in App Store Connect; do not infer approval from upload.
- Configured: The asset has been selected for a particular product page, language, or display location.
- Release-checked: You have verified that the intended page uses the intended asset and that the remaining app-version or event submission steps are complete.
Apple describes Asset Library as a way to manage assets across locations and supported sizes. Use the Asset Library documentation as the source of truth for the available controls. Do not use a team spreadsheet as evidence that a change has been applied in the console.
Independent developers: prepare the asset set, not just the files
When you are preparing a release alone, the failure is often not a missing image. It is an untracked relationship between the image and its destination. A screenshot can be present in the library yet still be absent from the product page you intend to update.
Before you upload, make a release record for each asset. Include its filename or library identifier, language, intended app page or location, device category, review state, and configuration state. Add a note if the asset replaces an existing item. This gives you a way to distinguish “ready to upload” from “selected for this page.”
Can you add an Asset Library screenshot to an app product page?
Yes, where the item is compatible with the destination. Select or configure it in the relevant product-page workflow rather than treating library presence as publication. Apple’s screenshot and app preview upload guide explains the product-page upload workflow. After selection, inspect the page configuration and confirm the displayed order and preview.
For a solo release, make the check observable. Keep the source file, the library record, and a capture or note of the final page state together. If you later need to undo the change, you can identify which asset was selected and where it was used instead of re-uploading files until the page looks right.
Localization owners: separate language from device compatibility
Localized product information and localized media belong together in the release plan, but they are not interchangeable. An asset prepared for one language should not be assumed to be suitable for another. Likewise, a file that fits one supported device or display context should not be assumed to fit every other destination.
How should you manage different languages and device sizes?
Create an asset record for each language and intended device context. Then compare the file with Apple’s current screenshot specifications and the supported creative asset specifications. Check the specifications again when you prepare a new release; do not rely on dimensions copied from an older checklist.
Use Apple’s localization instructions for app information to check how localized listing information is managed. During the asset check, confirm that the locale selected in the console matches the language in the image itself. A filename containing a locale code is a useful clue, not proof that the image contains the correct translated copy.
A small team can prevent accidental cross-language reuse by recording both the asset language and its destination language. If they differ intentionally—for example, because a creative asset is designed to appear in more than one locale—record that decision. Otherwise, the next person reviewing the page may interpret the mismatch as an upload mistake.
Product-page owners: check reuse and destination together
When you maintain more than one app page or display location, reuse is convenient only if you can tell where an asset is compatible and where it is already used. Review the details App Store Connect provides for the asset, including compatible locations and recent-use information where available. Use those details to decide whether the item is suitable for the target destination; do not assume that appearance in the library guarantees compatibility everywhere.
Can you submit screenshots or creative assets for review ahead of an app version?
Apple documents a workflow for submitting assets from Asset Library independently of an app version. Use that option when it fits your release plan, then track the resulting status separately from the app version. The asset-submission instructions describe the available flow. Confirm the current status in App Store Connect; an upload or submission is not the same as an approved asset.
Keep three actions distinct:
- Reuse from Asset Library: Choose an existing file that is suitable for the intended use.
- Configure a location: Assign the asset through the relevant product-page or media-management workflow.
- Archive or delete: Change the library’s stored material, which is not a substitute for checking what remains configured on a page.
Before replacing a live asset, record the current selection and destination. Then make the change and re-open the intended page. This catches a common handoff error: the new file is present, but the previous file is still selected—or the new file has not been assigned at all.
Marketing and release teams: treat creative review as a separate gate
A team may prepare campaign or brand assets while app engineering is still finishing a version. Asset Library can support independent asset submission, but approval alone does not confirm that the asset appears in the intended product-page header, search placement, or in-app event. The destination and its configuration still need their own check.
Does approval mean the asset is already visible on the product page?
No. Treat approval as a review result, not a publication receipt. Verify the target location in App Store Connect and confirm the actual selected creative there. Record the planned location, review state, and configuration result separately.
A practical handoff note might say: “Approved; not yet selected for the product page,” or “Configured for the intended locale; final page preview checked.” Those statements make the remaining work explicit. Avoid a single “done” status that hides whether the team means uploaded, submitted, approved, configured, or checked.
Permissions can also affect handoffs. Before assigning a publishing task, verify that the team member has the role and access needed for the intended action. Apple’s role-permission reference is the authority for App Store Connect permissions. Do not solve an access problem by sharing another person’s credentials; assign access through the supported account workflow and confirm the task can be completed.
If review is complete but the listing still looks unchanged, stop and inspect the destination configuration before resubmitting the same file. Repeated uploads can create more records without fixing the missing page assignment.
Run the final asset acceptance check
Use this checklist for the release owner’s final pass. Mark an item only after you have verified it in App Store Connect or against the current Apple specification.
- [ ] The asset has a filename or library identifier that your team can trace to its source.
- [ ] The recorded language matches the text visible in the asset and the intended listing locale.
- [ ] The device or display context matches the destination’s current Apple specification.
- [ ] The asset is compatible with the intended product page or display location.
- [ ] Its review state is recorded separately from its upload state.
- [ ] The correct asset is selected in the intended page or location.
- [ ] The page preview shows the expected asset and order.
- [ ] Any app-version, product-page, or event submission still required is assigned and tracked separately.
- [ ] The handoff record identifies the owner and the last verified state.
This is especially useful when a marketing owner supplies files, a developer uploads them, and a release lead performs the final check. Each person can complete a different stage without assuming that someone else finished the page configuration.
For teams working across several locales, do not clear the checklist by checking only the default-language page. Review each intended locale and destination independently. A correct English page does not establish that localized pages use the right screenshots, nor does a successful asset review verify every page assignment.
Compare the workflow states before closing the release
The table below is a release decision aid, not a replacement for Apple’s live interface or current specifications.
| What you can see | What it establishes | What to verify next |
|---|---|---|
| File appears in Asset Library | The asset is available in the library | Language, device context, and destination compatibility |
| Asset has been submitted or reviewed | A review action or status exists | Current status and whether more action is required |
| Asset is selected for a product-page location | The page has an asset assignment | Correct locale, order, and preview |
| Page preview matches the release plan | The selected content appears as expected in that view | Remaining app-version or event submission and handoff record |
If your workflow also requires generating or inspecting screenshots, keep that work separate from library administration. Xcode Simulator is relevant when you need to capture or verify app screens in a macOS development environment. Asset Library itself is for managing, reviewing, and assigning store assets; it is not a requirement that forces you to use a remote Mac. Choose an environment based on the screenshot and build tasks you actually need to perform.
For a temporary release task that needs Xcode or Simulator on macOS, a remote Mac can be an alternative to buying hardware solely for that work. It is not automatically the right choice: an existing Mac is simpler if you already have one and need frequent hands-on access; a rented environment can make more sense when you need a separate, time-bounded macOS workspace. You can review MACCOME’s English service options and, if a hosted Mac fits your workflow, check the Mac mini rental option. Keep the decision tied to your actual build and screenshot workflow—not to Asset Library access alone.
The release is ready to hand off only when the library record, review state, intended page assignment, locale, and final preview agree. That separation prevents the most misleading status in asset work: a file that looks finished in the library but has not been checked where customers will see it.