Building CarPlay Support for Rork Apps — Entitlements, CPTemplate APIs, and Winning App Store Review

Writing an Entitlement Request That Actually Gets Approved

Apple takes CarPlay entitlement requests through a dedicated form. The form looks simple, but reviewers evaluate submissions on three unspoken dimensions, and missing any one of them gets you denied.

The first dimension is necessity. Apple is actively filtering out "apps that work fine on a phone." You need to describe use cases that only exist while driving, or that gain meaningful value from the driving context (location, speed, route history). A generic "users want to use our app in the car" is not enough. Describe specifically what the user is trying to accomplish, and why the in-car context changes the experience meaningfully.

The second is safety. Every CarPlay app must demonstrate minimized visual attention. Your request should concretely describe text-length caps, tap-target sizes, and voice feedback — not just claim "we care about safety." Apple looks for proof that you've thought through the driver's cognitive load at every interaction point.

The third is category fit. If you apply under Audio, audio playback must be the app's core function. If you apply under Navigation, you need your own turn-by-turn navigation implementation; handing off to Apple Maps or Google Maps won't cut it. Apple has seen too many apps try to slip through the Audio category when they're really social apps with a music feature bolted on.

Here's a template I've seen get approved:

App Name: DriveRadio by Rork Lab
Requested Entitlement: com.apple.developer.carplay-audio
Primary Category: Audio Streaming
 
Why CarPlay is essential for this app:
DriveRadio generates personalized radio programs based on the user's
driving history (GPS logs). Program generation depends on context
that's only available while driving — current location, speed, and
past routes — so the in-car scenario is intrinsic to the value.
 
Safety considerations:
- Entire UI built with only CPListTemplate and CPNowPlayingTemplate
- Any program reachable within 3 taps
- All text items capped at 36 characters
- Voice feedback for selected items
 
Expected launch timeline: Q3 2026
Expected user base in first year: ~10,000 MAU

For individual developers, approval typically takes 2–4 weeks on the first attempt, with rejections adding weeks to the cycle. My own first two attempts were denied — first for weak category-fit justification, second for vague safety language. The third attempt, written in this structure, cleared in ten days. The pattern I've seen across other developers is consistent: reviewers reward precision and specificity. Vague language of any kind is interpreted as a sign that you haven't done the real design work yet.

UIScene Configuration — Adding a CarPlay Scene to Info.plist

Once entitlements are granted, the next step is declaring a CarPlay scene in Info.plist. For a Rork-generated Expo project, you either edit ios/YourApp/Info.plist directly or configure it via app.json plugins. Most Rork users prefer the app.json path because it survives expo prebuild regenerations, but for advanced CarPlay configurations the direct edit is sometimes unavoidable.

<key>UIApplicationSceneManifest</key>
<dict>
    <key>UIApplicationSupportsMultipleScenes</key>
    <true/>
    <key>UISceneConfigurations</key>
    <dict>
        <key>CPTemplateApplicationSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneClassName</key>
                <string>CPTemplateApplicationScene</string>
                <key>UISceneConfigurationName</key>
                <string>CarPlay Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).CarPlaySceneDelegate</string>
            </dict>
        </array>
        <key>UIWindowSceneSessionRoleApplication</key>
        <array>
            <dict>
                <key>UISceneClassName</key>
                <string>UIWindowScene</string>
                <key>UISceneConfigurationName</key>
                <string>Default Configuration</string>
                <key>UISceneDelegateClassName</key>
                <string>$(PRODUCT_MODULE_NAME).SceneDelegate</string>
            </dict>
        </array>
    </dict>
</dict>

This manifest declares two distinct scenes — one for the iPhone window, one for CarPlay — with independent delegates and lifecycles. Closing the iPhone window doesn't stop the CarPlay scene, and vice versa. This independence is powerful but also a source of bugs if you treat the two as sharing state.

One footnote: $(PRODUCT_MODULE_NAME) must remain a build variable. React Native + Expo auto-generates the module name, so hard-coding it will break the build in subtle ways. I've burned half a day on that mistake. If you see errors about "missing symbol for CarPlaySceneDelegate," check this variable first before anything else.

Picking the Right CPTemplate — Audio, Navigation, Communication

CPTemplate APIs are the heart of CarPlay. Apple limits which templates you can use based on your category, and mixing, say, Navigation templates into an Audio app will get you rejected in review. The constraints feel arbitrary until you see them through Apple's safety lens: each template is optimized for a specific driving context, and misusing them creates cognitive mismatches for the driver.

For Audio apps, the allowed templates are:

• CPListTemplate for song, album, and playlist listings
• CPTabBarTemplate for top-level sections (Music, Podcasts, Library)
• CPNowPlayingTemplate for the playback screen (Apple provides the UI — do not reimplement it)
• CPGridTemplate for up to eight grid buttons (favorite categories)

For Navigation, you get CPMapTemplate, CPRouteChoicesTemplate, CPSearchTemplate, and related templates, but you must supply your own map renderer. MapKit cannot be rendered directly onto CarPlay. This is a significant engineering commitment — building a CarPlay-capable map renderer is comparable in effort to building a real navigation app on its own.

For Communication, CPListTemplate displays contacts and CPPointOfInterestTemplate handles location-tagged messages. Message bodies must be in a form Siri can read aloud; text with emoji or complex formatting won't pass review. Apple explicitly designs communication templates around hands-free interaction, so your implementation must not require text input from the driver.

Here's a minimal Audio-category implementation:

import CarPlay
 
class CarPlaySceneDelegate: UIResponder, CPTemplateApplicationSceneDelegate {
 
    var interfaceController: CPInterfaceController?
 
    func templateApplicationScene(
        _ templateApplicationScene: CPTemplateApplicationScene,
        didConnect interfaceController: CPInterfaceController
    ) {
        self.interfaceController = interfaceController
 
        let nowPlayingButton = CPNowPlayingButton { _ in
            interfaceController.pushTemplate(
                CPNowPlayingTemplate.shared,
                animated: true,
                completion: nil
            )
        }
 
        let episodes = loadEpisodes()
        let items = episodes.map { episode in
            CPListItem(
                text: episode.title,
                detailText: episode.duration,
                image: episode.artwork
            )
        }
 
        let section = CPListSection(items: items)
        let listTemplate = CPListTemplate(
            title: "Latest Episodes",
            sections: [section]
        )
        listTemplate.trailingNavigationBarButtons = [nowPlayingButton]
 
        interfaceController.setRootTemplate(listTemplate, animated: false) { _, error in
            if let error = error {
                print("CarPlay root template error: \(error)")
            }
        }
    }
 
    func templateApplicationScene(
        _ templateApplicationScene: CPTemplateApplicationScene,
        didDisconnectInterfaceController interfaceController: CPInterfaceController
    ) {
        self.interfaceController = nil
    }
}

The critical move here is pushing CPNowPlayingTemplate.shared directly. Apple supplies the now-playing UI; rolling your own triggers a review rejection. Leaning on Apple's defaults is an unspoken rule of CarPlay development. Early in my CarPlay journey I tried to customize the now-playing screen and wasted two weeks debugging rendering issues before learning that the shared template is non-negotiable.

Sharing Data Between iPhone and CarPlay — Shared UserDefaults and App Groups

The CarPlay scene runs in a separate process from the iPhone app, so in-memory state and AsyncStorage are unavailable on the CarPlay side. You need an App Group and either shared UserDefaults or a shared container to move data across. This is the single most common source of "it works in development but breaks in production" bugs for CarPlay apps.

In a Rork + Expo project, add this to app.json:

{
  "expo": {
    "ios": {
      "entitlements": {
        "com.apple.security.application-groups": [
          "group.com.yourcompany.yourapp"
        ]
      }
    }
  }
}

To push data from React Native to the CarPlay scene, build a native module that writes to the shared UserDefaults:

@objc(SharedStorage)
class SharedStorage: NSObject {
 
    @objc func saveEpisodes(_ episodes: NSArray, resolver: RCTPromiseResolveBlock,
                            rejecter: RCTPromiseRejectBlock) {
        guard let defaults = UserDefaults(suiteName: "group.com.yourcompany.yourapp") else {
            rejecter("ERR_NO_SUITE", "App Group not configured", nil)
            return
        }
        defaults.set(episodes, forKey: "carplay_episodes")
        defaults.synchronize()
        resolver(nil)
    }
}

Read from the same suite in the CarPlay scene. The most common mistake here is using UserDefaults.standard, which maintains separate stores for the iPhone and CarPlay processes. Always use UserDefaults(suiteName:). A related trap is forgetting to register the native module with React Native's bridge — the Swift class has to be exposed via the RCT_EXPORT_MODULE() macro or the Expo equivalent for the JS side to call it.

Testing and Debugging with the CarPlay Simulator

Physical CarPlay testing obviously requires a compatible vehicle, but the Xcode CarPlay Simulator is enough for most development. Open Window > Devices and Simulators > CarPlay in Xcode and the CarPlay window appears alongside the iPhone Simulator. The simulator accurately reflects most runtime behaviors, though it runs faster than real CarPlay units, which can hide performance issues you'll only notice in production.

The detail that trips people up is scene lifecycle timing. didConnect fires when the CarPlay cable plugs in, but in the simulator it fires every time Xcode launches. In production, account for cases like "already connected, but the iPhone was restarted" — you need explicit state restoration logic in didConnect, otherwise users see empty lists for a moment after starting their car.

Also watch image sizing. CPListItem images have category-specific caps. For Audio, the ceiling is 108pt × 108pt (324px × 324px at @3x). Exceed it and the image silently fails to render, with no log warnings. This is one of the quietest bugs in CarPlay development. Build a dedicated image-processing step in your content pipeline that resizes artwork specifically for CarPlay, rather than reusing the same assets from the iPhone UI.

Five Common Pitfalls in CarPlay Development

Here are five real problems I've hit or seen in consults:

1. Entitlement granted, but provisioning profile missing the CarPlay capability. After Apple approves the entitlement, you still need to enable the CarPlay capability in the Identifier settings in the Developer portal and regenerate the provisioning profile. Skip this and your build succeeds but nothing shows up in CarPlay — no error, no hint. This is the single most common time-waster for new CarPlay developers.

2. Works in the simulator, fails on device. Nine times out of ten this is UIRequiredDeviceCapabilities in Info.plist containing a flag like location-services that's incompatible with CarPlay. Check that list carefully. A less common but equally frustrating cause is a third-party SDK that adds its own required capability without you realizing.

3. Audio stops when the iPhone screen is closed. You need AVAudioSession set to .playback plus audio in UIBackgroundModes. Missing either of these kills playback the moment the user locks their phone. React Native projects often miss this because neither flag is set by default in a fresh Expo project.

4. Scroll position diverges between iPhone and CarPlay lists. The two scenes are independent; if you want scroll state to track, sync it explicitly through the App Group. The right approach is to treat scroll position as shared state, not as something the UI "just remembers."

5. Rejected for "insufficient category fit." App Store reviewers are stricter than entitlement reviewers. Apple employees sometimes test in actual vehicles. Attach a video demonstrating the in-car use case to preempt the rejection. I've also seen reviewers test whether the app behaves sensibly when CarPlay disconnects mid-session, so include that flow in your testing.

Putting It Together — The Fastest Path for a Rork App

Here's the most efficient order of operations for adding CarPlay to an existing Rork project.

Open the Rork-generated Expo project in Xcode and create CarPlaySceneDelegate.swift inside ios/YourApp/. Asking Rork's AI to scaffold the Swift code is fine as a starting point, but explicitly require conformance to CPTemplateApplicationSceneDelegate and include the lifecycle methods shown above — AI-generated CarPlay code often misses these. Treat the AI output as a 70% starting point, not as production-ready code.

Then add the entitlements and App Group to app.json and run expo prebuild --clean to regenerate the native iOS project. Build locally through Xcode rather than Rork's cloud build so the entitlement changes take effect. Cloud builds tend to cache provisioning profiles in ways that mask entitlement issues; local Xcode builds fail loudly, which is what you want.

Finally, submit the entitlement request to Apple. You can't upload CarPlay-enabled builds to TestFlight until the entitlement is live, so submitting early and implementing in parallel is the time-efficient move. From my experience, parallelized effort lands a CarPlay-enabled release in 4–6 weeks. If you wait until the implementation is complete before submitting, your timeline balloons to 8–10 weeks in exchange for zero additional quality.

After launch, track CarPlay-specific metrics separately — in-car session duration, continuous playback time, and crash rates during driving — in App Store Connect. For related architectural context, Rork iOS Production Guide and Complete App Store Review Guide pair well with this article.

Wrapping Up — Your First Concrete Step

CarPlay support is one of those features that compounds over time. Once you clear the approval hurdle, you permanently unlock a channel that deepens engagement in ways most indie apps never get. The weeks you invest now become an asset that keeps delivering retention lift for the life of the app.

Your first move should be identifying which CarPlay category fits your app. Check Apple's CarPlay developer page, pick the category closest to your core functionality, and try to write — in under 500 characters — why your app meets the three criteria: in-drive necessity, safety consideration, and category fit. If you can write those three paragraphs, your app is a legitimate candidate for CarPlay. If you can't, that's useful information too: the value story isn't crisp enough yet, and the clarity exercise itself will improve your product thinking even if you decide not to pursue CarPlay right now.

Individual developers ship CarPlay apps all the time. The approval process takes weeks, but the implementation itself is typically 30–50 hours of additional work on top of an existing iPhone app. And for the right category, I've seen subscription conversion rates climb 1.8x after CarPlay support ships. That's a return worth the patience, and one of the few product moves where the bureaucratic investment pays back the largest long-term dividend.

Deep Dive — Category-Specific Design Patterns

Each CarPlay category has its own conventions, and understanding them before implementation saves significant rework. Below are practical design patterns I've refined through multiple CarPlay builds.

Audio category — optimizing for long sessions

Audio apps win on CarPlay when they reduce decision fatigue. A driver starting a 90-minute commute doesn't want to scroll through dozens of categories. Use CPListTemplate sections to expose "Continue Listening," "New Releases," and "Recommended for This Drive" at the top, with the user's full library accessible but not prominent. Apple specifically rewards apps that prioritize resumption over discovery — drivers pick up where they left off far more often than they explore.

Another Audio pattern worth adopting is contextual playlists. If your app knows the user's current location and speed, you can auto-suggest playlists tuned to the context — "Highway Drive" for high-speed stretches, "City Traffic" for stop-and-go. Implementing this requires access to CoreLocation in the background, which CarPlay explicitly permits. Users who discover this feature tend to become heavy advocates because it feels like magic.

Navigation category — the real bar is higher than it looks

Navigation is the hardest CarPlay category to qualify for. Apple expects a complete, independent turn-by-turn implementation with offline capabilities, lane guidance, and voice instructions. Just fetching directions from a Google Maps API and drawing a line on a map doesn't cut it. Before you commit to Navigation as a category, ask yourself whether you have the engineering capacity for a 6–12 month specialized project.

If you do proceed, invest heavily in the voice instruction quality. CarPlay reviewers specifically test whether voice guidance is clear enough to follow without looking at the screen. Voice that's too quiet, clipped, or unnaturally spaced leads to rejection.

Communication category — hands-free is non-negotiable

For messaging and calling apps, the defining constraint is zero-keyboard interaction. The entire send-a-message flow must work through Siri voice dictation. You don't build a text field in the CarPlay UI — Siri handles composition via its system UI. Your code is responsible for presenting received messages, selecting contacts, and triggering Siri's message-composition flow.

This constraint confuses developers coming from iPhone messaging apps, where text input is central. In CarPlay, text input doesn't exist. Embrace that model early to avoid rework.

Post-Launch Playbook — What to Do in the First 30 Days

Shipping a CarPlay-enabled build is the milestone, but the first month post-launch determines whether you see the retention lift or not. Here's a 30-day playbook I use.

Week 1: Monitor crash reports specifically filtered to CarPlay scenes. Apple's CarPlay-specific crashes look identical to iPhone crashes in Xcode, but the context is different — a crash in the car is far more disruptive than a crash during app browsing. Treat every CarPlay crash as P0.

Week 2: Instrument session durations before and after CarPlay launch. Compare cohorts who use CarPlay vs. those who don't, controlling for tenure on the platform. If the CarPlay cohort doesn't show significantly longer sessions, something is wrong with the UX flow.

Week 3: Run voice feedback tests. Most CarPlay UIs under-use voice feedback even when they technically support it. Users confirm selections more confidently when they hear "Episode 42 selected" rather than seeing a silent visual highlight. Add voice feedback where it's absent.

Week 4: Solicit feedback from drivers directly. Run a post-session survey inside the iPhone app (not CarPlay itself) asking specifically about in-car usability. The insights from this kind of direct feedback are more actionable than analytics, because drivers can describe context that logs never capture.

Frequently Encountered Scenarios

What happens when the entitlement is denied? Apple provides a generic denial message without specifics. Treat the denial as a signal that your "why" wasn't clear enough. Rewrite the request from scratch, emphasizing the three dimensions covered earlier, and resubmit. Most successful CarPlay developers were denied at least once.

Can I use CarPlay without joining Apple's dedicated program? No. CarPlay entitlements are separate from regular developer program membership. You don't pay extra, but you do need explicit approval per app per category.

Is CarPlay available on CarPlay Android Auto or other platforms? Android Auto is a completely separate platform maintained by Google. The APIs are different, the review process is different, and the UI conventions are different. If you want both, plan two independent implementation tracks. Do not assume code reuse is straightforward.

What about the new CarPlay Ultra that replaces the entire vehicle display? That's an even stricter subset requiring explicit partnership with automakers. Individual developers cannot currently build for CarPlay Ultra. Focus on standard CarPlay, which reaches the vast majority of CarPlay-equipped vehicles.

A Note on Long-Term Maintenance

One aspect of CarPlay work that doesn't get enough attention is ongoing maintenance. CarPlay specifications evolve with each iOS release, and new templates or capabilities become available every one to two years. Staying current matters because Apple tends to showcase apps that adopt new CarPlay features, and that showcase placement drives meaningful installs. Set up a quarterly review of the CarPlay documentation to spot new opportunities.

Maintenance also covers responding to CarPlay-specific crash reports quickly. A user who experiences a CarPlay crash is far more likely to uninstall than a user who experiences an iPhone crash, because the driving context amplifies frustration. Treat CarPlay reliability as a first-class product metric separate from your overall crash-free rate.

The good news is that once the initial implementation is in place, the ongoing maintenance burden is relatively modest — perhaps 10–20 hours per quarter for a well-architected CarPlay integration. That's a small price for the retention and differentiation you get in return, and one of the reasons I recommend CarPlay to indie developers whenever their app category qualifies.

Finally, keep an eye on your review responses. Users who discover CarPlay support tend to leave enthusiastic App Store reviews mentioning it by name, which lifts your conversion rate for new users browsing reviews. Responding to those reviews reinforces the positive feedback loop and tells Apple's algorithms that the CarPlay experience is working.