iOS streaming app development

Only you can request FairPlay, not your agency

This is the sequencing trap, and it is worth knowing on day one rather than in week six.

FairPlay Streaming is Apple's DRM, and deploying it to production needs Apple's approval to create credentials. Apple is specific about who may ask: the Account Holder for your Apple Developer Program membership should request approval, the request is approved only if your team provides a streaming service to consumers, and requests from third-party accounts acting on behalf of content owners or licensees will not be approved.

Read that last clause again if you are planning to hand the whole project to a studio. We cannot request FairPlay credentials for you. No agency can. We can build the key-server integration, the player, and everything either side of it, but the approval has to come from your Apple Developer Program Account Holder, under your own membership.

So the first thing we do on an iOS project is start that request, because it runs in parallel with the build and it is the item most likely to be sitting unresolved when everything else is finished.

The technical side is more ordinary. The FairPlay Streaming Server SDK ships an implementation guide, development keys for Key Server Module implementors, and a sample iOS app that handles key requests and plays back encrypted content. Recent SDK versions add protection for CBCS-encrypted content, support for multiple certificate bundles, SPC v3 licence requests with integrity protection, and reference implementations in Swift and Rust.

If your packaging already produces CBCS for Apple devices, that part lines up. DRM on iOS is a procurement problem long before it is an engineering one.

Who collects the subscription

This is the question with real money attached, and the answer is not the one most teams assume.

The default is strict. Guideline 3.1.1 requires in-app purchase to unlock features or content — subscriptions, premium content, unlocking a full version — and explicitly prohibits your own mechanisms such as licence keys.

The route that matters for streaming is the reader app rule, 3.1.3(a). It covers apps that let a user access previously purchased content or content subscriptions, and Apple names the categories: magazines, newspapers, books, audio, music and video. A reader app may offer account creation for free tiers and account management for existing customers.

If your subscribers buy on your website and then sign in on the app, that is precisely the shape Apple describes.

Eligibility turns on primary functionality. Apple's own counter-example is a social networking app that lets people stream audiovisual content — not eligible, because streaming is not what the app is for. A streaming service is.

On top of that sits the External Link Account Entitlement, which lets a reader app link out to your own site to create or manage an account. Before the detail, the part with the money attached:

Using the entitlement means no in-app purchases at all on iOS, iPadOS or tvOS. It is not a supplement to in-app purchase, it is an alternative to it. So this is a fork in the business model, not a feature you add later — and picking the wrong branch is expensive to reverse.

The link rules are narrow, and each one is a way to fail review:

• the link must go to a website you own or are responsible for
• it must open in the default browser and may not open a web view
• it must not pass additional parameters in the URL
• it must go directly to the site, with no redirect, intermediate link or landing page
• it must carry no pricing information — Apple's acceptable wording is "go to example.com to create or manage your account"
• it must be a standard HTML link containing the domain name, shown once per page
• it must be statically defined in the external-link.account key in Info.plist before submission, and resubmitted if the URL changes

iOS streaming app development for broadcasters usually lands here, because a broadcaster typically already has a subscriber base and a billing relationship it has no intention of re-platforming onto Apple's. The reader-app route is how that survives contact with the App Store.

Decide the billing model before the design. Whether you are a reader app or an in-app purchase app changes onboarding, the sign-in screen, the paywall and what you are allowed to say in the interface. It is not a setting; it is an architecture.

The rule everyone still quotes and Apple no longer publishes

If you have collected quotes from studios, at least one will cite guideline 2.5.7: video over cellular longer than ten minutes must use HTTP Live Streaming with a baseline 192 kbps stream.

That guideline is no longer in the App Store Review Guidelines. It was removed and the surrounding section renumbered, so the 2.5.7 in today's document is a different clause entirely.

This does not mean stop using HLS. HLS remains the correct choice on Apple platforms, because FairPlay is defined on top of it and the whole toolchain assumes it. But it does mean two things worth noticing. A vendor quoting a withdrawn guideline is quoting a document they have not re-read in years. And a technical decision that used to be compliance is now engineering — you choose HLS because it works, not because you will be rejected without it.

Review is fast here, and that changes the plan

Apple states that on average 90% of submissions are reviewed in less than 24 hours.

Set that against the rest of a rollout. Samsung publishes no review duration at all and says it depends on tester availability and the number of certification rounds. Google Play refers to review times of up to 7 days, or longer in exceptional cases.

The practical consequence for a multi-platform launch is that iOS should not drive your schedule. Submit the platforms with no published review time first and let Apple catch up, rather than sequencing the way most plans do — iOS first because it feels like the flagship — and then waiting on a television.

iOS streaming app development for vod platforms benefits most from this, because a catalogue business ships far more releases than a live one, and a fast review compounds across every one of them.

What actually delays a submission

That speed assumes a complete submission, and two things account for most of the avoidable delay.

Give the reviewer a way in. Apple requires that a submission with account-based features includes either an active demo account or a fully-featured demo mode, along with any other credentials, hardware or resources the reviewer needs to reach the whole app. A reviewer who cannot sign in cannot approve, and for a subscription streaming service that is every screen worth reviewing.

If that sounds familiar, it should: missing test credentials is the leading cause of certification failure on Samsung too. The same avoidable mistake costs you a day on iOS and an unknown number of weeks on a television.

Answer the age-rating questions. Since 31 January 2026, Apple requires responses to updated age-rating questions for every app — including whether it contains loot boxes or uses other people's content. Without those answers, App Store Connect will not let you submit a new build at all.

That one catches teams who have not shipped an update in a while, which for a TV service's companion app is common. It is a form, not an engineering problem, and it will still stop your release.

What carries over from what you already have

The honest split, if you have an Android app or a web player today:

Carries over. Your API layer and entitlement model. Your catalogue metadata. Your analytics contracts. Your design tokens. Your CBCS packaging, if you already produce it. Most of your product decisions.

Does not. The player, because AVFoundation is its own architecture rather than a wrapper around anyone else's. The purchase flow, per the whole section above. And the surfaces Apple users expect and notice the absence of — AirPlay, Picture in Picture, offline downloads with sensible storage management, and handoff to Apple TV.

That last group is where iOS projects overrun. Each one reads like a checkbox and behaves like a feature.

iOS streaming app development for media companies tends to feel this hardest, because the app sits on a home screen next to Netflix and YouTube and gets judged against them. The Apple-native surfaces are the visible difference between an app that feels like it belongs on the device and one that feels like a website in a frame.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Your billing model. Reader app versus in-app purchase is the single biggest fork on this platform, and it is a commercial decision, not a technical one.
2. Whether FairPlay is already deployed. If your key server is live and credentialed, this is integration. If not, add the approval cycle.
3. Which Apple surfaces you want. AirPlay, Picture in Picture, downloads, Apple TV handoff, widgets. Each is real work.
4. Whether Apple TV follows. tvOS shares the language, the developer account and most of the player layer, so a second build is largely a new interface. Deciding that now costs a design conversation; retrofitting it later means rewriting the layer that already shipped.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly this problem — shipping to every platform means testing on every platform — and it streams real iOS simulators in a browser, which means a reviewer, a product manager or a client can open a build without a Mac and without an install. When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who knows why your FairPlay request has to come from your Account Holder.

Where iOS sits in the rest of your rollout

iOS is usually where the entitlement model gets its hardest test, because the billing question forces you to be explicit about what a subscription actually is and where the truth about it lives. Answer that here and every other platform inherits it.

Apple TV is the natural pair — it shares the language, much of the player layer and the same developer account — and scoping the two together costs far less than sequencing them.

We build these, end to end

The app, the AVFoundation player, the FairPlay integration once your credentials exist, the reader-app or in-app purchase flow, AirPlay and Picture in Picture, downloads, and App Store submission.

If you already have an iOS app that is stuck in review, failing on protected content, or paying commission you did not intend to pay, we will tell you straight which of those is a fix and which is a rebuild.

Send us your billing model, whether FairPlay is already deployed, and the platforms you expect to be on in two years. You will get back a scope and a number rather than a brochure. If you do not know whether you qualify as a reader app, start there — it decides more about this project than any choice we will make together.