App Store Preview Video Review: Catch UI Errors Before You Submit

An app store preview video is the one release asset where a single outdated screen can quietly undo the work, right, and I think most teams pour their energy into the wrong half of the job, which is the specs and the hook. To be very honest that half is basically solved, because Apple publishes its own requirements and every ASO guide repeats them, so the part almost nobody writes about is the review, that boring stretch between the editor saying it's done and somebody clicking submit.

I run a video-editing agency alongside PlayPause, so I sit inside review rounds for short product videos and the odd mobile app promo video all the time, and the failure I keep seeing has a familiar shape, right. The edit looks great, and then somebody from product notices after release that the settings screen a few seconds in is the old design, the one they killed two sprints ago. When I trace a miss like that back it almost always comes down to how the review was run, and at the end of the day that's a very very fixable thing.

So here's how I'd run an app store video review for a release, from who watches the cut to the last pass before anything goes into App Store Connect.

What an app store preview video needs to show

I'm deliberately not pasting a full spec table here, right, because Apple changes accepted sizes over time, and a table copied into a blog post is exactly how teams export the wrong size the night before a release. The app preview video guidelines live in the App Store Connect help pages on app previews and in the App Review Guidelines, so whoever briefs the edit should open the current version of both and put the numbers for your device sizes straight into the brief.

The only numbers I'll mention are the ones that shape the review, and you should still confirm them on Apple's live page. At the time I'm writing, you can attach up to three previews per language, each between 15 and 30 seconds, and they autoplay muted on the App Store, so plenty of people will judge your app on a silent half minute and whatever overlay text sits on top of it.

What matters more is what the guidelines are getting at. Apple's position is basically that a preview shows the app itself, captured from the app, with narration and text overlays allowed where the footage alone isn't clear. That makes it very different from an explainer video, where you can illustrate an idea with characters and metaphors, and stricter than a general mobile app promo video for social, because here the footage has to be literal.

So you're reviewing something that behaves more like documentation than an ad, right. The motion graphics, captions and transitions are packaging, and packaging is easy to judge. The hard part is whether every screen underneath matches the build you're about to ship, because that's the promise the preview makes to a stranger scrolling past with the sound off.

Apple sets the specs, your team owns the accuracy

Read Apple's current preview requirements before briefing the edit, then spend review time checking every screen against the build you are shipping.

Where preview videos usually go wrong

In my experience the most common error by far is the outdated screen. The editor got screen recordings from a staging build weeks ago, design shipped a new onboarding since then, and nobody re-recorded, so the cut looks lovely and shows a product that no longer exists. Close behind it is test data, for instance a user called "test user 3" or a chart that only looks healthy because someone seeded it with a nonsense number.

Then there's the stuff that sneaks into screen recordings, a notification banner from somebody's personal chat, a low battery in the status bar, the keyboard flashing up for a frame, and so on. The catch here is that previews cut fast, so a problem might be on screen for less than a second, long enough for a customer to register it and short enough for a reviewer skimming on a laptop to miss it.

The last group is claims and markets, right, like an overlay promising a feature that's actually in the next release, or a German caption sitting over an interface that's still in English. It's the same pattern I wrote about in Amazon product video requirements, where the platform rules are the easy bit and the review pass is where things slip, and brand colors drifting in the export, which I covered in product video color accuracy, turns up in previews too.

If you're here because an app preview video got rejected, the first place I'd look is the part of Apple's guidelines about footage that isn't captured from the app. But I'm pretty sure the bigger risk for most teams is the preview that sails through App Review and is still wrong, because nobody at Apple is going to tell you your settings screen is two sprints old.

• Old screens from a previous build
• Placeholder names and test data
• Notifications caught in the screen recording
• Status bar showing an odd time or low battery
• Overlay text promising a feature not in this release
• Localized captions over an untranslated interface

Who should review a preview before submission

I'd keep the reviewer list small and give each person one layer to own, right, because ten people watching a short preview with no brief produces a pile of overlapping notes and a very confused editor. Product watches purely for accuracy against the release build, every screen and every flow, plus whichever feature flags are actually on. Design watches the final UI and a theme that matches your screenshots, marketing or whoever owns ASO watches the hook and every claim in the overlays, and each market you localize for gets one native reviewer who watches only their own cut.

I'm strict about this because in my own agency a review round basically doubles whenever notes arrive half on WhatsApp and half in email. Somebody has to own the round and chase the one person who hasn't watched yet, which is really the producer job I described in what an agency producer does, and in a small app studio that's often the product marketer.

This is also where the tool matters. In PlayPause the reviewer opens one link in a browser, no account and no install, so your localization freelancer or your CEO on a phone can leave a note without signing up. If some reviewers aren't technical, my post on faster sign-off from non-technical stakeholders was written for demo videos, and almost all of it transfers to previews.

1Product checks every screen against the release build

2Design checks final UI, spacing and theme

3Marketing checks the hook, overlay copy and claims

4Each market reviewer checks their localized cut

Review_Cut_v4.mp4In Review

212160p · ProRes

00:34 / 02:18

SR

Sarah 0:34

Frame-accurate note, everyone sees the exact same thing.

Marking outdated UI on the exact frame

This part decides whether the fix takes ten minutes or two days, right. A note saying "the settings screen around second eleven looks old" forces the editor to guess, because a fast cut might have three screens inside that second, and the editor will fix the wrong one with total confidence. You see what I mean here, the note has to point at one frame, and I explained the longer version in what frame-accurate commenting is.

So the product reviewer pauses on the frame where the old toggle appears, leaves a timestamped comment, and draws on the frame to circle exactly what's wrong. If a whole sequence is stale, like the entire onboarding flow, a range comment covers the full stretch in one note, and our page on time-coded annotations shows how that looks on screen.

A worked example of one review round

Here's how I'd want a first round to look on a 30-second MV1 for a made-up habit tracker app, so treat it as an illustration rather than a real project. Product pauses at 0:07 on the frame with the old sync toggle, circles it and writes "old toggle, re-record from the current release build", then drags a range comment across 0:14 to 0:19 because that whole onboarding stretch is the previous design. Design replies under the first note with the exact screen to capture, and marketing flags the overlay at 0:23 promising watch sync, because that feature ships next release.

Over on the German cut, the native reviewer leaves one note at 0:26 where the caption clips at the right edge, and that's the entire round, right, four notes and one reply, each pinned to a single moment with somebody who owns it. The editor works through them top to bottom without a single call, and I set custom statuses per video, like needs re-record and approved, so anyone glancing at the project knows where each locale stands.

If your editor cuts in Premiere Pro, our panel shows these comments inside Premiere and a click jumps the playhead to that frame. Only Premiere Pro has a native PlayPause panel, so with After Effects, Final Cut or Resolve the editor exports, uploads and works from the notes in their own app, which still beats a spreadsheet of timestamps by a mile.

Old way

An email says the settings screen near second eleven looks old and the editor guesses which shot

With PlayPause

A comment pinned to the exact frame with the old toggle circled so the fix is obvious

Comparing updated and localized versions side by side

Once the editor sends a fix, the new cut lands as the next version on the same card, right, so MV1 becomes MV2 and the old comments stay on the old version. That's basically version control for video, and version stacks come with Creator and every plan above it.

The step people skip is checking that the fix landed and nothing else moved. With side-by-side version compare, on Agency and Enterprise, you play MV1 next to MV2 in sync and sit on the frame where the old screen was, and you also catch sneaky stuff like the music shifting half a beat after a re-export. Our page on side-by-side version compare walks through it for SaaS marketing teams, and there's a general guide on comparing two video versions too.

Localization is where compare really really earns its keep. I stack the localized cut next to the English master and scrub both together, checking that overlay text fits without clipping and that the interface underneath was actually recorded in that language. If you ship to many markets, the thinking in localized cuts without version chaos applies almost directly, and guest version upload on Agency and Enterprise lets a freelance localization editor drop in a new version with just a name and email.

If the preview has narration, AI transcription on Agency and up gives a native reviewer a clickable transcript to read line by line, and Playbooks hold the permanent brand rules, like no test data ever, as checklists that aren't done until someone ticks them, does that make sense, right.

$19

flat per month on Agency, not per member

50

members on Agency, room for every market reviewer

A final check before you upload

Before the file goes near App Store Connect, I watch the export on an actual phone, right, muted first because that's how most people meet it, then once with sound. Then someone from product opens the current release build next to it and checks screen by screen one last time, because builds keep moving between approval and submission.

I also review the poster frame as its own still, because that's the image people see before the video plays, so if it lands on a half-faded transition or a loading spinner, it's basically a bad screenshot in your product page gallery. Pick it deliberately and leave a comment on that exact frame so everyone signs off on it too.

Since the preview usually shows features that aren't public yet, I share the final approval cut through a password-protected link and revoke it the moment the release is out. Who-watched analytics, on Creator and up, shows who opened it and when, so you know whether the product lead actually watched the final cut before typing "approved", and trust me on any level, that matters. Our video proofing page covers this approval step, and my post on video review software ROI does the math on whether a tool is worth paying for.

“

A preview can pass App Review and still show a screen your users will never see, and that is the mistake worth reviewing for.

Frequently asked questions

Where do I find the official app preview video guidelines?

Apple keeps them in two places, right, the App Store Connect help pages on app previews for sizes and lengths, and the App Review Guidelines for what a preview is allowed to show. I'd read both at the start of every release rather than trusting an old brief, and put the current specs straight into the edit brief so the editor never has to guess.

Why was my app preview video rejected?

I can't see inside Apple's review, so I won't pretend to know your specific case, but the guidelines are clear that a preview should be built from footage captured from the app itself, with narration and overlays there to explain it. Check whether any shot is a mockup, a render or footage from outside the app, and read the exact note Apple sent, because it usually points at the problem fairly directly.

Can a freelancer or client review the preview without a PlayPause account?

They can, and that's basically the point of the share link. The reviewer opens one link in a browser, with no account and no install, and can leave frame-accurate comments, draw on the frame and reply in threads. On Agency and Enterprise a freelancer can also upload a new version as a guest, with their name and email collected, which really helps localization editors who only touch one market.

Which PlayPause plan do I need for an app store video review?

Creator at $9 a month, with room for 10 members, covers frame-accurate comments, drawing on the frame, password-protected links, version stacks and who-watched analytics, which is enough for a small studio shipping in one market. If you localize or ship updates often, Agency at $19 a month adds side-by-side version compare, AI transcription, guest version upload and Playbooks, and pricing is flat per workspace rather than per member.

If your next release has a preview going out, set up the review before the edit is even finished, so your reviewers are ready the moment MV1 lands, right. You can see every plan on the PlayPause pricing page, and each one starts with a 7-day free trial, which is enough time to run one full preview review before you decide anything.

So yeah. That's my way of saying it.