Getting a Streaming App Through Apple and Google Review

Why streaming apps get extra scrutiny

Video apps combine three things reviewers care about: content that may not belong to the developer, money changing hands for digital goods, and personal data used for advertising. Each of these has its own section in Apple’s App Review Guidelines and in Google Play’s Developer Program Policies, and a streaming app usually touches all three at once.

Reviewers also judge the app by what they see in the first few minutes. They do not browse your whole catalog. They look at the home screen, open one or two titles, try to sign up, try to buy, and look for settings. Whatever appears on that path has to be consistent with your store listing. A placeholder poster, a title named “Test”, or a channel that fails to play is enough to make the app look unfinished, which Apple treats as a completeness problem under its performance guidelines.

Match the age rating to what is actually in the catalog

Both stores ask you to complete a content questionnaire that produces an age rating. Apple’s current scale is 4+, 9+, 13+, 16+ and 18+; Google uses the IARC questionnaire, which produces regional ratings such as ESRB and PEGI. The answers must describe the most mature content a user can reach in the app, not your average title.

For a catalog-driven app this means the rating is a database query, not a marketing decision. Before every submission, list every title that is active and visible to a signed-out or default profile, group them by rating, and look at the highest one. If you want a 13+ app, nothing rated R, NC-17 or TV-MA can be reachable without a parental gate, and the store questionnaire must say so honestly.

• Check the hero banner and the first rails separately. They are what reviewers see, and they are often driven by editorial picks that bypass the normal catalog filters.
• Check the metadata, not just the video. A family film that is mislabeled R in your CMS is shown with an R badge, and the reviewer will believe the badge.
• Check years and release dates. A banner that says a 2024 documentary was released in 2043 is a small error, but it tells the reviewer the data is not maintained.
• If you rely on profile-based parental controls, make sure the default profile a reviewer lands in is the restricted one, or explain the control in the review notes.

When you change the catalog to fit a lower rating, deactivate titles rather than deleting them. You keep the history, and you can bring a title back once you have the rights evidence or the parental gate that justifies it.

Account deletion has to be inside the app

If users can create an account in your app, Apple requires that they can also start deleting it from inside the app (guideline 5.1.1(v)). A link to a support email is not enough, and neither is “deactivate”. Google Play has a similar requirement and additionally asks for a web page where people can request deletion without reinstalling the app; you enter that URL in the Data safety section of Play Console.

Reviewers test this. They sign up with a throwaway address and look for the option under Account or Settings. Make sure the flow exists in the build you submit, that it works on the review environment, and that it produces something your team will actually act on, such as a ticket in your support desk with a clear type like “account deletion”. We cover the full flow, including what data to keep for legal reasons, in a separate guide on account deletion.

Privacy policy, privacy labels, and Data safety must agree

Apple shows a privacy “nutrition label” on your App Store page, built from the answers you give in App Store Connect. Google shows a Data safety section built from the Play Console form. Both stores also require a link to a privacy policy. Reviewers compare all three with what the app actually does.

Ad-supported streaming apps are where these documents most often drift apart. Adding Google AdMob or another ad SDK means the app now shares a device advertising identifier, IP address, and ad interaction data with a third party. If your privacy policy still says “we do not use third-party tracking”, it contradicts both your labels and the SDK in your binary. On iOS, if any of that data is used to track users across other companies’ apps or websites, you also need the App Tracking Transparency prompt before the SDK reads the advertising identifier.

1. List every SDK in the build and what each one collects. Ad, analytics, crash-reporting and payment SDKs are the usual sources.
2. Fill in the Apple privacy label and the Google Data safety form from that list, not from memory.
3. Update the privacy policy so it names the same data types, the same purposes, and the same third parties.
4. Put the policy at a stable public URL that does not require sign-in, and link the same URL from both stores and from inside the app.

Be ready to prove you have the rights to your content

Apple’s intellectual property guidelines say an app may not show content it is not authorized to use, and reviewers apply this firmly to streaming apps whose catalogs contain recognizable studio films or series. If your home screen shows well-known titles, expect a request for documentation: licence agreements, distribution agreements, or a written authorization from the rights holder that covers streaming in the territories where the app is offered.

The fastest way through this is to prepare the evidence before you submit and to keep the catalog you submit limited to titles you can document. A clean, smaller catalog of original, licensed or public-domain material passes faster than a large catalog where half the titles have no paperwork. Our guide on content rights evidence covers what reviewers accept and how to organize it.

In-app purchases, subscriptions, and the paid apps agreement

If users can buy a subscription or rent a title inside the iOS app, Apple expects that purchase to go through in-app purchase, with some exceptions for reader apps and for certain regions where alternative payment rules apply. Google Play has a parallel requirement to use Google Play Billing for digital goods sold in the app. Mixing a web checkout button into the app without the right entitlement is a common rejection.

Two administrative steps catch new teams out. On Apple, in-app purchases cannot be submitted or tested until the account holder has accepted the Paid Applications agreement in App Store Connect and filled in banking and tax details. On Google, subscription products must be created and activated in Play Console before the app can query them. If these are not done, the purchase screen in your review build shows nothing, and the reviewer reports a broken feature.

Also make sure restored purchases work. Reviewers often delete and reinstall the app, then tap Restore. A subscriber who paid should get access back without buying again.

Give the reviewer a working account and clear notes

Reviewers can only judge what they can reach. If most of your catalog is behind a subscription, create a dedicated review account with an active entitlement, and put the credentials in the review notes. Do not use a staff account; reviewers may change its settings or delete it as part of testing account deletion.

• Explain any region locks. If titles are geo-blocked, say which test region the reviewer is likely in and confirm the review account can play there.
• Explain ads. If the app shows pre-roll ads, say so, and make sure at least one title has an ad attached so the reviewer sees the real experience rather than a blank pause.
• Explain sign-in methods. If you offer Sign in with Apple or Google sign-in, both must work in the review build.
• Point to the deletion flow and the privacy policy location in the app, so the reviewer does not have to hunt.

Short, specific notes save a rejection cycle. Each cycle typically costs one to three days, and repeated rejections for the same reason slow the next review down further.

A pre-submission checklist

We run this list against the production catalog and the exact build being submitted. Every item has an owner, and the submission does not go out until all of them are checked.

1. Highest active rating in the catalog matches the declared store age rating.
2. No titles named “Test”, no placeholder artwork, no rails with a single item, no channels without an image.
3. Every visible title plays, including the first live channel and the hero banner title.
4. Account deletion works end to end and creates a request your team can see.
5. Privacy policy, Apple privacy label and Google Data safety list the same data and the same third parties.
6. Rights evidence for any recognizable third-party title is ready to attach.
7. Paid Applications agreement accepted; in-app products created, priced and approved for review.
8. Review account has an active subscription; credentials and notes are in the submission.

Treat a rejection message as a precise bug report. Fix the specific thing named, reply in Resolution Center explaining what changed, and avoid resubmitting the same build with only an argument attached. Reviewers respond well to evidence and badly to repetition.