Guaranteed 100% Facebook, Instagram and WhatsApp Approvals & App Review
Quick Transfer Ready to use app available for Facebook, Instagram and WhatsApp
Guaranteed 100% Facebook, Instagram and WhatsApp Approvals & App Review
Quick Transfer Ready to use app available for Facebook, Instagram and WhatsApp
Meta App Review · Screencast
Your app works. Your permissions are coded. You submit for Meta App Review — and it comes back rejected with a note about the screen recording. For most teams, the screencast is the single hardest part of the whole submission, because Meta does not approve a permission from a written description. A reviewer has to watch the permission being used, end to end, in a video they can follow. This guide explains what that video really has to show, why so many get rejected, and where professional submission support removes the guesswork.

What the screencast actually is

The screencast is a screen recording you attach to your App Review submission. Meta is explicit: your submission must include recordings that demonstrate how to use your app to test every permission and feature you are requesting. Reviewers use your video as a guide to test the app themselves. If they cannot verify from the recording that your app genuinely needs a permission, that permission is not approved.

It is not a marketing demo and not a product tour. It is functional proof, recorded for a reviewer who has never seen your app and will not read a long explanation. The recording shows how to test each permission; the submission form separately asks why you need it.

What a reviewer needs to see in the video

Meta breaks the recording into three things the reviewer must observe for each permission in the submission. Miss any one of them and the permission can be rejected.

1. The complete login flow

From logged-out to logged-in. Log out of any test account first, then capture the entire sign-in, including any non-Facebook login your app uses.

2. Permission being granted

The business login button, the consent screen requesting that exact scope, and the user actually granting it — the full authorization flow, not a skip-ahead.

3. The data being used

The app user performing the action that requires the permission, and what the app does with that data — create, publish, read, view the result.

Every permission, no gaps

The recording must cover each permission and feature in the submission. Omit one and the reviewer cannot test it — that alone triggers a rejection.

Why the screencast is where submissions fail

The video looks simple, but it sits on top of a working, reviewer-reproducible environment — and that is what trips teams up. These are the complications that turn a screencast into weeks of resubmissions.

The reviewer must be able to reproduce it

Meta tests your app with their own accounts. The flow you record has to actually work for a fresh reviewer with a test user — not just on your machine with your data. A flow they cannot replicate is treated as unverifiable.

It has to prove the exact scope, visibly

Generic product walkthroughs that never clearly show the consent screen and the scope in action are the most common failure. Each permission needs its own clear, on-screen proof, ideally annotated so the reviewer sees precisely when it is used.

Accessibility rules are real rejection triggers

Recordings should use English UI or captions, high resolution, a visible cursor, no audio, and annotations on the key moments. If a reviewer cannot clearly see what is happening, they cannot verify it — and unverified means not approved.

Advanced Access raises the bar

Permissions that serve accounts you do not own need Advanced Access, which is granted only through a clean App Review. The screencast is the evidence that decides it. See our explainer on Meta Advanced Access for how this gate works.

How we prepare an approval-ready screencast

At a high level the work runs in a fixed order. Each stage has to be right before the recording matters — this is the part we handle for clients end to end.

1

Map every permission and feature in the submission so the recording plan covers all of them with nothing missing.

2

Stand up a reviewer-ready environment with working test users, so the exact flow can be reproduced cleanly by Meta.

3

Record each permission's full journey — login, consent screen, scope in use — in clear, high-resolution, annotated segments.

4

Pair every recording with a use-case justification that matches what the video shows, so the form and the proof agree.

5

Submit, track the review, and if a permission comes back, fix the exact reason and re-record only what is needed — without breaking approved scopes.

What a clean screencast gets you

Each requested permission verified by the reviewer on the first watch
Advanced Access granted for the scopes your app actually uses
Fewer review cycles and weeks saved versus trial-and-error resubmissions
A submission package that holds up if you add scopes later

A note worth setting expectations on: a strong screencast removes the avoidable reasons for rejection, but the final approval decision always rests with Meta. The goal of professional preparation is to give the reviewer no reason to say no.

Common reasons a screencast gets rejected

The recording skips the login flow or starts already logged in
The consent screen and the permission being granted are never clearly shown
Reviewers cannot reproduce the flow with their own test user
One or more requested permissions are missing from the video
Low resolution, hidden cursor, or non-English UI with no captions
The use-case justification does not match what the video actually shows

Screencast holding up your approval?

If your Meta App Review was rejected over the demo video, or you are not sure your recording proves the scope, I provide hands-on submission and screencast preparation — from a reviewer-ready environment to the final resubmission. See the Facebook App Review service or the App Review rejection fix service.

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