Meta App Review · Screencast
Your app works. Your permission justification reads well. You submit for Meta App Review — and weeks later it comes back rejected over the screencast. The demo video is where most submissions quietly fail, because Meta does not approve a permission from a written description. A reviewer follows your recording to test the app, and if they cannot see the permission being used, that permission is denied. This guide explains what the screencast really has to prove, why generic recordings get rejected, and where professional submission support removes the guesswork.

What the screencast is actually for

The screen recording is not a marketing demo of your product. Meta’s reviewers use it as a test script: they replicate the exact steps you show to verify that your app genuinely needs each permission and feature in the submission. Per Meta’s own guidance, any requested permission or feature that is missing a screen recording will not be approved — the recording is mandatory, not optional polish.

That single rule reframes the whole task. The video is evidence, and it has to stand on its own. If a reviewer watches it and still cannot tell how to trigger the permission, the safe decision for them is rejection.

The three things every recording must show

For each permission you request, Meta expects the recording to walk through a complete, reproducible journey. Miss any one of these stages and the submission is at risk.

1. The full login flow

From logged-out to logged-in — including the business login button and the moment the user authorizes your app. Reviewers need to see how a real user actually gets in.

2. The permission being granted

The consent screen requesting that specific scope, and the user approving it. A recording that skips the authorization step never proves the scope is really used.

3. The data actually being used

The app performing the action that depends on the permission — creating the post, reading the data, sending the message — and the visible result of that action.

Every permission, individually

One scope without its own demonstrated flow is enough to fail the whole submission. Each requested permission needs its own clear, on-screen proof.

Why so many screencasts get rejected

The failures are rarely about app quality. They come from the gap between what a founder thinks is obvious and what a reviewer — working from the video alone, with no context — can actually verify.

The reviewer cannot reproduce it

Reviewers test with their own accounts and test users. If your flow depends on hidden setup, a specific account state, or steps that are not shown on screen, they cannot replicate it — and an unreproducible flow is treated as unproven.

It is a product tour, not a permission proof

A polished walkthrough of your dashboard that never clearly shows the consent screen or the scope in action is the single most common reason demo videos fail. Reviewers are looking for the permission, not the features.

Advanced Access raises the bar

Publishing or managing data for accounts your users do not own requires Advanced Access, which is only granted through a clean App Review. A weak screencast is what blocks that step. See our guide to Meta Advanced Access for how this gate works.

Each rejection costs weeks

App Review is not instant, and every failed round means re-recording, resubmitting and waiting again. Two or three avoidable cycles can stretch a launch by a month or more — which is exactly the cost a correct first submission avoids.

How a review-ready submission comes together

A screencast that passes is the output of preparation that happens before the camera ever rolls. At a high level, this is the sequence we handle end to end.

1

Map every requested permission and feature to a concrete, demonstrable action in the app, so nothing is requested that cannot be shown on screen.

2

Confirm Business Verification and the supporting details — privacy policy, data handling, use-case description — line up with what the recording will show.

3

Stand up a clean, reviewer-ready environment with working test users so each flow can be reproduced exactly as recorded.

4

Record each permission’s full journey — login, consent, and the data being used — in English, in high resolution, with clear annotations on the moments that matter.

5

Submit, monitor the review, and if a specific item comes back, fix that exact reason and resubmit without disturbing the scopes that already passed.

What a clean submission gets you

Each requested permission demonstrated clearly enough for a reviewer to verify and approve
Advanced Access unlocked so the app can serve real client accounts in production
Fewer review cycles, which means a launch measured in days rather than repeated weeks
A submission record that holds up if you add scopes or resubmit later

If you have already been rejected, the path back is the same discipline applied to the exact failure point. Our case study on a rejected Facebook App Review walks through how a corrected justification and a proper screencast turned a denial into an approval.

Common reasons demo videos fail review

A requested permission has no screen recording showing it in use
The consent screen and scope authorization are never clearly shown
Reviewers cannot reproduce the flow with their own test user
The video is a product tour that never triggers the permission
Non-English UI with no captions or annotations to explain the steps
Advanced Access requested while Business Verification is incomplete

Failing review over the screencast?

If your Meta App Review keeps getting rejected on the demo video, I provide hands-on App Review and screencast submission support — from mapping permissions through to an approval-ready recording. See the Facebook App Review service or reach out directly.

Approval support and submission preparation only. Final approval decisions rest solely with Meta.