Apple TV app development

The device does not promise to keep anything

This is the constraint that surprises people, and it is worth putting first because it changes what you can promise your subscribers.

Apple's guidance for Apple TV is direct: storage on the device is limited, and there is no guarantee that information stored on it will be available the next time someone opens your app. That is not a bug to engineer around. It is the design of the platform.

For anything you need to survive, Apple points off the device: iCloud key-value storage for small needs under 1 MB, CloudKit or your own service for anything larger.

The consequence for a streaming product is specific and commercial: download-to-watch is not an Apple TV feature the way it is on a phone. If your marketing promises offline viewing across devices, Apple TV is the exception, and it is much better to know that during scoping than during a launch review.

The good news is that a well-built streaming service is already mostly immune. Resume points, watchlists, continue-watching rows and entitlement state should live in your backend regardless, because a viewer expects to start on the phone and finish on the television. If that is already true, this constraint costs you almost nothing. If your design assumed a local cache, it costs you a rewrite of the state layer.

Worth noting honestly: the page where Apple states this most plainly is in its documentation archive and carries a 2017 date. The architectural constraint has not changed, but if you need a current written commitment for a procurement document, ask Apple rather than citing that page.

Sizes, and a system Apple just deprecated

The published limits for tvOS are generous for a streaming app, because your content is streamed rather than shipped:

• App bundle: 4 GB
• Hosted on-demand resources: 20 GB
• Asset packs: 512 MB each, up to 1000 of them

The part that matters more than the numbers: on-demand resources are deprecated as of tvOS 27, and Apple recommends migrating to Background Assets.

So if you are scoping new work, do not build on on-demand resources, and if a vendor proposal in front of you is built around them, ask when it was written. This is the same signal as any deprecated framework — it tells you how recently that team looked at the platform rather than at their last project.

Apple TV app development for vod platforms feels this least, because a catalogue app ships almost no bundled content. It matters most for anything that packages assets locally, which on a television is usually a mistake anyway.

The device matrix is the smallest in your rollout

After Samsung and LG, this is a relief worth pricing in.

tvOS 26 — released in September 2025, succeeding tvOS 18, with Apple having moved to numbering that matches the release season — supports Apple TV HD and every Apple TV 4K. A handful of newer features need a second-generation Apple TV 4K or later, but the baseline is one product line with a short history.

Set that against the pages either side of this one. On Samsung, your floor is a Tizen version per model year. On LG, it is a Chromium version, and a 2016 set is running an engine from 2014. On Apple TV there is no equivalent argument to have, because Apple pushes tvOS updates to the devices it still supports and the hardware range is small.

That means less device procurement, a smaller test matrix, and a front end you write once. It is the quiet reason Apple TV usually comes in under the estimate people carry over from the smart-TV platforms.

The interface is the part you actually rebuild

Everything else in this article is reuse. This is not.

Apple TV is driven by the Siri Remote and the system focus model, and Apple is prescriptive about it for a reason: at three metres, focus is how a viewer knows what they are about to activate. On Apple TV, a focused element lifts and responds with parallax to movement on the remote's touch surface. That is not decoration — it is the entire feedback mechanism replacing a cursor and a fingertip.

Two things follow that teams underestimate:

1. Focus order is a design deliverable, not an implementation detail. Every screen needs a defined traversal, and retrofitting it after visual design is signed off means redoing the visual design.
2. Top Shelf is a real surface with real value. The Home Screen area above your icon can showcase content, preview what a viewer cares about, or drop them directly into part of the app. It is the closest thing Apple TV has to merchandising real estate, and it is routinely left as a static image because it was not in the estimate.

Apple TV app development for broadcasters tends to run aground here rather than in the player, because broadcast design language assumes dense, simultaneous information and tvOS rewards the opposite.

Design the focus states and the Top Shelf in the first design pass. Both are cheap to specify up front and expensive to add after the interface is agreed.

What actually carries over from iOS

This is the reason Apple TV is the cheapest second platform, and it is worth being precise about.

Carries over. Swift, so no new language. The same Apple Developer Program account. Your FairPlay setup, including the credentials your Account Holder already had to request. Your AVFoundation player logic. Your networking, your entitlement model, your catalogue code, your analytics contracts, most of your business logic.

Does not. The entire interface layer, per the section above. Any assumption about local persistence. Touch gestures, obviously. And sign-in, because typing on a remote is the worst experience in the product — which is why device-code pairing against a phone is worth building here exactly as it is on other televisions.

If you have already shipped iOS, the honest estimate for Apple TV is a new front end on an existing spine. That is a real project, and it is a fraction of the first one.

What drives the cost

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

1. Whether an iOS app already exists. Sharing the player, the FairPlay integration and the entitlement layer is the single biggest saving on this platform.
2. The size of your navigation graph. Every screen needs a focus order. Ten screens is a different project from forty.
3. Whether Top Shelf is in scope, and whether it is dynamic or a static image.
4. Sign-in. Device-code pairing done properly is its own slice of work.

Apple TV app development for telcos usually adds one more: an operator bundle can mean specific entitlement handshakes that are neither Apple's problem nor yours alone.

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 treats Apple TV as a first-class target alongside phones, with a focus-walk driver rather than blind remote chaining, because a focus bug is the defect a TV app ships with most often. 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 watchlist cannot live on the device.

Where Apple TV sits in the rest of your rollout

Apple TV should follow iOS, not lead it. Almost everything expensive — the FairPlay approval, the player, the entitlement model — is done once on iOS and reused here. Sequencing it the other way means paying for that work before you have a phone app to amortise it against.

Against Android TV it is the easier of the two if you already have an iOS app, and the harder one if you do not.

We build these, end to end

The tvOS app, the focus and navigation model, Top Shelf, the AVFoundation player and FairPlay integration, device-code sign-in, and App Store submission through the account you already have.

If you have an iOS app today, we will tell you honestly how much of it moves — and where the estimate someone gave you assumed more reuse than the interface layer allows.

Send us your iOS status, whether downloads are promised anywhere in your product, and the platforms you expect to be on in two years. You will get back a scope and a number rather than a brochure.