App Store app preview: one 886x1920 master covers four iPhone sizes

Yes: one portrait master at 886 x 1920 pixels serves four iPhone display classes at once. Apple's App Store Connect page lists 886 x 1920 (portrait) or 1920 x 886 (landscape) for the 6.9-inch, 6.5-inch, 6.3-inch and 6.1-inch iPhone app previews (read 2026-10-03). Only the older 5.5-inch, 4.7-inch and 4-inch classes ask for different sizes. That makes the 886 x 1920 file the first one worth producing, and Sume's video trim can cut it from a clip you already host.

The rest of Apple's requirements are length, size, frame rate and encoding. This post covers which of those Sume can set and which it cannot.

What Apple lists for iPhone previews

The general rules apply to every device: a duration of 15 to 30 seconds, a maximum file size of 500 MB, and either portrait or landscape orientation (macOS and tvOS are landscape only). Apple's page names H.264 and ProRes 422 (HQ) as supported formats. For H.264 it gives a target bit rate of 10 to 12 Mbps, a progressive profile up to High Profile Level 4.0, a maximum of 30 fps and the .mov, .m4v and .mp4 extensions. Audio is stereo AAC at 256 kbps with a 44.1 or 48 kHz sample rate (read 2026-10-03).

Cut the master with video trim

Sume's video trim returns a new MP4 from one clip hosted on media.sume.com. Its output object takes width, height and fps, with each edge between 256 and 2160, so 886 x 1920 is inside the range. The frame rate can be set only when precision is the default exact, and Apple's ceiling is 30 fps, so set fps to 30 or 24. The duration field sets the length; pick a value between 15 and 30 to stay inside Apple's window.

Be careful with the aspect ratio. 886 x 1920 is about 0.461, a little taller than 9:16 (0.5625). If your source is a 1080 x 1920 screen recording, a straight resize to 886 x 1920 would squeeze it. Decide whether the trim should crop or scale for your source before you ship, and compare a still against the original. The docs for trim do not describe a letterbox or crop mode for output, so treat the result as something to inspect, not assume.

A trim job costs $0.02 under the current public rate (confirm in GET /v1/catalog). The script below cuts 24 seconds at 886 x 1920 and 30 fps, then prints the new URL.

import os, time, requests
BASE = "https://api.sume.com"
H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}

def run(path, body, key):
    r = requests.post(BASE + path, headers={**H, "Idempotency-Key": key}, json=body)
    r.raise_for_status()
    job = r.json()["request_id"]
    while True:
        s = requests.get(f"{BASE}/v1/jobs/{job}/status", headers=H).json()["status"]
        if s in ("completed", "failed", "canceled"):
            break
        time.sleep(3)
    return s, (requests.get(f"{BASE}/v1/jobs/{job}/result", headers=H).json() if s == "completed" else None)

status, res = run("/v1/video-trim", {
    "video_url": "https://media.sume.com/artifacts/artf_demo/app-demo.mp4",
    "start": 3, "duration": 24,
    "output": {"width": 886, "height": 1920, "fps": 30}}, "app-preview-886-001")
print(status, res and res["video_url"])

Plan the older iPhone classes separately

The 5.5-inch and 4-inch classes both list 1080 x 1920 in portrait, and the 4.7-inch class lists 750 x 1334. If your app still supports those devices, you need one more file for them, and it is a different shape from the 886 x 1920 master, so cut it from the same source rather than rescaling the finished master twice. Each cut is a separate trim call with its own Idempotency-Key; reuse a key only when you retry the same request after a timeout, as the jobs-and-results page describes.

A short checklist keeps the set consistent: the same start and duration across all cuts so the story beats line up, the same fps for every file, and a still pulled from each result so you can look at the first screen a visitor sees. Name the files by device class when you save them, because Apple's page groups them that way and a mix-up between 886 x 1920 and 1080 x 1920 is easy to make when the files look alike.

What Sume does not control

Apple's page asks for a 10 to 12 Mbps H.264 target, a specific profile and level, and 256 kbps stereo AAC. Sume's docs reject client codec and bitrate fields (ffmpeg_fields_rejected, which covers codec and crf) and do not publish an output bit rate. So you cannot request those numbers, and you should not tell App Store Connect the file meets them without checking. Run video inspect with frames: false to read the probe facts, and compare them with Apple's list before you upload.

Apple remains the judge. Upload the file in App Store Connect, watch the validation message, and keep the untouched source so you can redo the trim with a different crop if the file is refused.