App Store Screenshot Sizes 2026: Multilingual Asset Preparation and Upload Tutorial

The publishing owner should not ask for “screenshots in every language” as a single design task. That request hides several separate decisions:

• Which platforms and device classes need assets?
• Which storefront languages are active?
• Which screenshots are required for the submission?
• Which App Preview videos are optional for the current release?
• Which markets need different claims, interface text, or feature emphasis?
• Which assets are approved, uploaded, pending, rejected, or awaiting regional review?

Create one row for each platform, device class, and localization. Keep the source file path and approval owner in the same record. A simple matrix is more reliable than a shared folder full of filenames such as final2 or latest-final.

Apple’s device and screenshot requirements can change with platform classifications. Use the current Screenshot Specifications reference as the source of truth. Do not build a production template from an old forum image or a saved design file with no date or specification reference.

Reminder: A successful upload proves that the file was accepted by the interface. It does not prove that the right language, order, message, or fallback asset appears on the product page.

You do not always need a separate design for every device size. Apple provides a scaling workflow for some screenshot cases, so a high-resolution source may cover compatible display requirements. The decision is safe only when the screen content remains correct after scaling.

Reuse is usually reasonable when:

• The interface is identical.
• The same controls remain visible.
• The screenshot orientation is unchanged.
• Text remains legible at the destination size.
• The feature shown is available in the target build.
• The visual composition still leaves the main claim visible.

Create a separate asset when:

• A tablet layout exposes different navigation or controls.
• A device class uses a different orientation.
• A localized headline changes line wrapping.
• The target market has a different feature set.
• A payment, login, map, or content screen changes by region.
• Scaling makes a disclaimer, button, or key product benefit unreadable.

The mistake is treating scaling as a design shortcut. It is a compatibility tool, not permission to ignore layout differences. Your designer should open the scaled result at its intended display size and inspect the first screenshot, the smallest text, and any screen with dense controls.

The specification review for designers

Before exporting the master files, check the following against Apple’s current documentation:

• Pixel dimensions for each selected device category.
• Portrait or landscape orientation.
• Accepted image file formats.
• Whether transparency is appropriate for the selected asset.
• Screenshot order and the strongest first frame.
• The relationship between screenshots and any App Preview.
• Whether the content reflects the submitted build rather than a prototype.

Apple’s official specifications are the correct place to confirm supported formats, dimensions, and device groups. Keep the editable design source, the export, and the specification reference together. That makes a later device-category change traceable instead of forcing a full reconstruction.

A useful naming pattern is:

platform_device_language_sequence_status

For example, the filename can identify the platform, device category, locale, position, and review state. Avoid using only a translated language name. A language folder does not tell the uploader which device slot the file belongs to.

Different languages can share the same screenshot set, but only when the image itself does not contain language-dependent information. If the screenshot includes interface labels, promotional copy, feature names, or market-specific claims, mechanical translation of the headline is not enough.

The localization operator should compare three layers:

• App interface: What language and features does the build actually display?
• Screenshot copy: What does the image promise or explain?
• Store metadata: Do the title, subtitle, description, and keywords support the same message?

A screenshot can be linguistically correct and still be operationally wrong. For example, a localized headline may mention a feature that is unavailable in that market. A translated image may also use a term that differs from the product’s interface, creating a visible mismatch.

Use this decision table before asking design for exports.

The primary language should be clearly marked in the matrix. Each target language needs its own upload location in App Store Connect. Do not assume that a browser language, team member language, or operating-system language determines the storefront asset that users will see.

Apple explains the relationship between localized app information and the product page in its localization guidance. Use that documentation when deciding what is localized, what falls back, and what still needs a separate review.

The design lead owns more than visual quality. This role must make each export reproducible.

Follow this production sequence:

1. Confirm the current specification reference and selected device categories.
2. Capture screens from the build that matches the intended submission.
3. Build the master composition at the required source resolution.
4. Add the screenshot headline only after checking the localized copy length.
5. Export the required image format without accidental compression or color changes.
6. Review transparency, orientation, text size, and visual cropping.
7. Save the editable source beside the approved export.
8. Record the exact language, device category, sequence, and build reference.

Do not place fake interface content in a screenshot unless it clearly represents the real product experience and complies with Apple’s submission expectations. A polished image that shows unavailable functionality creates a later acceptance and trust problem.

The design lead should also keep a “known differences” note. It should list screens that cannot be reused, such as region-specific payment flows, different onboarding copy, or platform-specific navigation. This note prevents the localization team from requesting a blind batch translation.

The localization operator checks whether the screenshot says what the app actually does in that market.

Use a three-way review record:

This role should flag more than spelling errors. Check terminology, plural forms, currency references, date conventions, and claims that depend on local availability. If the app supports several languages but the product page has incomplete localized assets, document which language is intentionally used as fallback.

A fallback is not a substitute for acceptance. It may be technically valid while still weakening conversion or confusing a regional reviewer. The project owner should approve every intentional fallback before upload.

The administrator should treat the upload as a controlled publishing operation, not a file drag-and-drop exercise.

Uploading multilingual screenshots through App Store Connect

Use the following runbook:

1. Open the app record and select the release or product-page area that is currently editable.
2. Enter the intended platform and device category.
3. Select the target localization before choosing files.
4. Upload the approved screenshots and any App Preview to that exact location.
5. Wait for processing to finish before judging the final order.
6. Review the first screenshot, sequence, orientation, and scaled result.
7. Confirm that the asset is associated with the intended language and device class.
8. Record the upload operator, date, source folder, and processing result.
9. Repeat the same checks for every localization instead of assuming the interface preserved your previous selection.

Apple’s official upload procedure for App Previews and screenshots should be open during this work. The exact buttons and editable states can vary with the selected app status, so also check Apple’s app and submission status reference when an upload control is unavailable.

Media Manager is useful when you need to organize reusable media across product-page work. It does not remove the need to confirm the destination localization, platform, device class, and sequence. A file stored correctly in the media library can still be attached to the wrong publishing context.

Fixing a size mismatch after upload

When an upload reports a dimension or compatibility problem, do not immediately resize the file until it passes. First isolate the cause:

• The export may target a different device category.
• The image may have been rotated during export.
• The file may contain an unexpected color or transparency setting.
• The selected upload slot may not match the design template.
• The platform may have changed the accepted device classification.
• A previously accepted file may be reused from an outdated specification.

Return to the master file, select the correct current specification, export again, and upload the replacement. Keep the rejected file in the project log with the reason for rejection. This is faster than allowing several near-identical versions to circulate among design and publishing teams.

The regional reviewer owns the final presentation check. “Uploaded successfully” is not the acceptance criterion.

Review the target storefront using the intended language and confirm:

• The first screenshot communicates the correct benefit.
• The sequence matches the approved ASO plan.
• Every visible headline matches the app interface and store metadata.
• No key text is cropped after scaling.
• App Preview placement does not displace the intended first impression.
• The fallback language is understood and approved.
• The product page does not show an older asset after a replacement.
• The evidence distinguishes search-result exposure from the complete product-page view.

A remote Mac can help keep a separate Safari language profile, account session, and regional verification workflow. It can also give a distributed team a stable place to upload, review, and hand over assets. It cannot bypass App Store regional rules, force a particular search result, or guarantee review or release outcomes.

For teams that need to inspect several storefront presentations, keep the browser session isolated from personal Apple accounts. If your process also involves several developer accounts, document that separately in a multi-account permission and environment isolation plan. Screenshot acceptance and account governance are related, but they are not the same control.

Static screenshots can be designed, exported, and uploaded without a dedicated Mac when the team has an accurate build capture and a compliant editing workflow. App Preview is different because it involves video capture, device behavior, timing, audio decisions, and platform-specific review.

Apple’s App Preview specifications should determine the supported duration, dimensions, formats, and other video requirements. Do not infer those requirements from a general social-video preset.

A Mac is especially useful when you need to:

• Capture an App Preview from a real Apple platform.
• Reproduce Safari or macOS presentation behavior.
• Keep a controlled Apple account and browser session.
• Upload repeatedly during a release cycle.
• Give a designer and an administrator the same working environment.
• Preserve a handoff point when the usual publisher is unavailable.

A Mac is not automatically necessary for a one-time set of static images. Buying hardware may be more sensible for a team with long-term daily Apple development, physical-device testing, or sustained heavy workloads. A short remote session is more appropriate when the need is temporary and tied to a release or localization batch.

If your team lacks a continuously available Mac, review remote Mac delivery and administrator-permission checks before choosing a short-term environment. Confirm the delivery method, access scope, file transfer process, and handoff evidence before moving production assets.

The project owner should close the release with an evidence package. It should contain the editable source, approved exports, localization map, upload record, acceptance captures, and the next-update owner.

Solo operator checklist

• [ ] Platform and device classes are listed.
• [ ] Each target language has an explicit asset state.
• [ ] Current Apple specifications are linked in the project record.
• [ ] The first screenshot has been reviewed at its destination size.
• [ ] Reused images have passed interface and message checks.
• [ ] Localized images match the build and metadata.
• [ ] Upload location and order were verified after processing.
• [ ] App Preview was either checked or intentionally omitted.
• [ ] Regional product-page evidence is saved.
• [ ] Source files and export names are understandable to your future self.

Shared team checklist

• [ ] A publishing owner is named.
• [ ] Design, localization, upload, and regional acceptance owners are separate or explicitly combined.
• [ ] Every file has a language and device-class identifier.
• [ ] Upload access has been tested before the release deadline.
• [ ] The handoff includes the exact source and export locations.
• [ ] Rejected files and reasons are logged.
• [ ] Fallback language decisions are approved.
• [ ] A replacement owner is assigned for the next update.
• [ ] The team knows which assets remain editable and which require a new submission state.
• [ ] Any remote Mac session has a documented transfer and account-cleanup procedure.

The key keyword is App Store screenshot sizes 2026, but the operational decision is broader: map the audience and storefront first, then let the current specification determine the export. If your current workflow relies on shared desktops, personal Macs, or ad hoc file transfers, it commonly creates three weaknesses: unclear ownership, mixed browser or account sessions, and no reliable handoff when the release owner is unavailable.

For a release-bound team without a continuously available Mac, renting a remote Mac from CALMVPS can be the cleaner temporary option for App Preview work, repeated uploads, and acceptance handoff. It is not a promise of approval or regional visibility. Choose it when the publishing cycle is short, the team is distributed, and you need a controlled macOS workspace without buying hardware; choose a local Mac when the workload is permanent or depends on physical interfaces. You can review the available remote Mac plans against your release schedule before committing.

Keep the final evidence package with the release record. When Apple changes device categories, screenshot specifications, Media Manager behavior, fallback rules, or editable states, rebuild the matrix before reusing the old templates.