CarPlay app development

What you can ship, and what you cannot

CarPlay is not an open app platform. Every app on the dashboard is explicitly approved by Apple and must fall into a limited set of categories. Apple's documented list for third-party apps is audio, communication, navigation, EV charging, parking, and quick food ordering.

For a streaming service, exactly one of those applies: audio. That is the category covering music, podcasts and audiobooks.

CarPlay app development for streaming services therefore means building the audio product you may already have — or the audio half of the product you have. A music service, a podcast network, a radio brand, the audio feed of a sports rights holder: these are native fits, not workarounds.

Video, honestly

Apple is introducing a capability where iPhone video can be AirPlayed to the CarPlay display. Three limits define it:

• Playback is only allowed while the vehicle is parked and unmoving.
• Each vehicle manufacturer has complete control over whether their cars allow it at all, so some infotainment systems may never permit it.
• Third-party apps must integrate support themselves, and third-party video app support is described as coming to CarPlay with iOS 27.

So video in the car is real, later, partial, and outside your control in a way nothing else in your rollout is. CarPlay app development for vod platforms should be scoped as an audio product with a video question revisited after iOS 27, not as a video product with an audio fallback.

The entitlement is the schedule

This is the part that wrecks plans, and it is procedural rather than technical.

To integrate with CarPlay you request the appropriate CarPlay entitlement for your category through Apple's CarPlay contact page and agree to the entitlement agreement. Then:

• You cannot build or sign a CarPlay app until Apple assigns your developer account the entitlement. This is not a step that runs in parallel with development. It runs before it.
• Apple reviews requests case-by-case with no published service-level agreement, and reported timelines range from a few days to several weeks.
• The request must be made by the Apple Developer account's Admin or Account Holder — frequently someone in a different team from the people writing the app.
• You supply your app name, bundle ID, chosen category, and a description of the app's in-car use case and safety.
• After approval you create a new provisioning profile carrying the entitlement, and build with it.

Start the entitlement request in week one, before a line of CarPlay code exists. It is the only task on this project whose duration Apple will not tell you in advance.

One app, one category. Each CarPlay app is limited to exactly one Apple-defined category, and the entitlement locks it there. Your category also determines which templates you can use, and templates from different categories cannot be mixed in a single app. A service wanting audio playback and turn-by-turn guidance is looking at two apps.

The interface is not yours to design

CarPlay interfaces are built from predefined templates, which means developers cannot create completely free-form CarPlay interfaces. Apple's framework supplies the template types an app configures to build its in-car experience — originally available only to navigation apps, and since extended to further categories.

For a design team used to owning every pixel of a TV or mobile app, this is the adjustment. You are configuring a consistent, deliberately constrained interface rather than expressing a brand in it. The constraint is the product: it is what makes every app in every car behave the same way at 70mph.

Two consequences worth planning for:

Your app becomes voice-shaped. Apple's documentation states that to use CarPlay your iPhone must run the latest version of iOS and have Siri turned on — disable Siri entirely and CarPlay stops working. Voice is not a nice-to-have input here.

Adopting templates is a structural change to an existing iOS app, not a new screen. Apps using CarPlay templates must adopt Apple's modern scene lifecycle and move off the older application and window APIs, with a separate scene configuration declared for the CarPlay experience alongside the iPhone one. If your iOS app is old enough to predate that lifecycle, budget for the migration before the CarPlay work starts.

What actually carries over from your iOS app

The good news, and it is substantial.

Carries over. Your API layer, authentication, entitlement and subscription logic, catalogue metadata, download and offline behaviour, and your audio playback stack. The CarPlay app is the same iOS app with an additional interface, so none of that is rebuilt.

Does not. The interface, entirely — templates replace your views. Your navigation model, because depth that is fine on a phone is not fine on a dashboard. And any interaction that assumes a user can look at the screen.

CarPlay app development for media companies with an existing iOS app is usually measured in weeks of interface and integration work, plus an entitlement wait nobody can quote.

Where CarPlay is genuinely limiting

One honest limit, stated plainly.

You are building inside someone else's product decisions, and they can change. The category list is Apple's. The templates are Apple's. Whether video ever works in a given car is the manufacturer's. There is no equivalent of shipping a web app where you decide what the experience is. If your differentiation lives in interface design, CarPlay is the platform where you cannot express it, and no amount of budget changes that.

What you get in exchange is a driver who is already listening, in a context with almost no competition for attention.

What drives the cost

1. Whether you already have an iOS app with an audio stack. If yes, this is an interface project. If no, it is an iOS project with a CarPlay interface on top.
2. Whether that app has adopted the modern scene lifecycle. If not, that migration comes first.
3. How complex your catalogue browsing is. Templates are fixed, so deep or unusual navigation takes more work to express, not less.
4. Whether Android Auto is in scope too. Most in-car projects want both, and the shared layer is worth designing once.

Tell us those four and you get a scope and a number rather than a range.

Who builds it

We build audio apps as well as video ones — music and podcast apps are in scope, which matters here because CarPlay is audio-first by design and a video-only shop has nothing to offer you in the car.

The people who scope your project are the people who build it. There is no account layer between you and the engineer who will tell you to file the entitlement request today rather than in sprint three.

In-car is the part of the OTT surface most studios skip entirely. We cover it alongside smart TVs, streaming devices, consoles, mobile and web, so adding CarPlay and Android Auto to an existing rollout is one conversation and one shared codebase. CarPlay app development for telcos bundling music or podcasts with a subscription is usually exactly this shape — one more surface, not a standalone product.

We quote per project rather than publishing a rate card, because the four drivers above move the number more than any range would. Ask on a call and you get the number against your actual platform list.

What to send us

CarPlay app development for broadcasters and audio services goes fastest when the first message answers four things: whether you have an iOS app today, whether it has an audio playback stack, who holds Admin on your Apple Developer account, and whether Android Auto is in scope.

That third one is not administrative trivia. The entitlement request can only be filed by your Admin or Account Holder, and finding out who that is has delayed more CarPlay projects than any technical problem on this page.