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")
        resolver(nil)
    }
 
    @objc static func requiresMainQueueSetup() -> Bool { false }
}

Two things worth calling out about that snippet.

There's no synchronize() call. Manual synchronization has been discouraged for years, and writes land on their own. Calling it isn't harmful, but it gives you a false sense that the data definitely arrived — the real inconsistency lives on the read side, in the other process.

The second is registration. Without it, NativeModules.SharedStorage comes back undefined and the failure surfaces in JavaScript rather than anywhere near your App Group configuration. One bridging file covers it.

// SharedStorage.m
#import <React/RCTBridgeModule.h>
 
@interface RCT_EXTERN_MODULE(SharedStorage, NSObject)
 
RCT_EXTERN_METHOD(saveEpisodes:(NSArray *)episodes
                  resolver:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
 
@end

Read from the same suite in the CarPlay scene. The most common mistake there is using UserDefaults.standard, which maintains separate stores for the iPhone and CarPlay processes. Always use UserDefaults(suiteName:).

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.

Image sizing deserves the same treatment. My first version of this code baked in the number I'd found while reading around. That didn't work out: the cap varies by app category, so artwork that rendered fine in one vehicle went missing in another, and I spent a while chasing reports I couldn't reproduce.

Apple exposes the limit itself as CPListItem.maximumImageSize — a resolution-independent value in points, returned for the category your app actually runs under. Asking is safer than remembering.

extension UIImage {
    /// Returns a copy clamped to the runtime CarPlay list image limit
    func fittedForCarPlayList(scale: CGFloat) -> UIImage {
        let limit = CPListItem.maximumImageSize
        guard size.width > limit.width || size.height > limit.height else { return self }
 
        let ratio = min(limit.width / size.width, limit.height / size.height)
        let target = CGSize(width: size.width * ratio, height: size.height * ratio)
 
        let format = UIGraphicsImageRendererFormat.default()
        format.scale = scale
        format.opaque = false
        return UIGraphicsImageRenderer(size: target, format: format).image { _ in
            draw(in: CGRect(origin: .zero, size: target))
        }
    }
}

An oversized image simply doesn't appear. No exception, no log line — one of the quietest bugs in CarPlay development.

List length fails just as quietly. CPListTemplate caps both the number of sections and the total number of items, and anything past the cap is dropped without an exception or a log line. Those caps can shift between OS releases, so read them from the API at runtime instead of hardcoding numbers.

extension CPListTemplate {
    /// Build a template clamped to the runtime limits
    static func clamped(title: String, sections: [CPListSection]) -> CPListTemplate {
        let maxSections = min(sections.count, CPListTemplate.maximumSectionCount)
        var remaining = CPListTemplate.maximumItemCount
        var safeSections: [CPListSection] = []
 
        for section in sections.prefix(maxSections) {
            guard remaining > 0 else { break }
            let items = Array(section.items.prefix(remaining))
            remaining -= items.count
            safeSections.append(CPListSection(items: items, header: section.header, sectionIndexTitle: nil))
        }
        return CPListTemplate(title: title, sections: safeSections)
    }
}

The subtlety is that maximumItemCount applies to the template as a whole, not per section. Assume it's per-section and you get a bug where only the trailing sections vanish — and only on device, where your content set is larger than your test fixture. That one cost me a full day of hunting a "last category doesn't appear" report.

Rendering speed is the other simulator blind spot. The CarPlay window runs on your Mac's hardware, so a heavy list build feels instant there and sluggish on a real head unit. I budget 16ms for template construction, load artwork asynchronously, and return a placeholder item first so the list is never blocked on network I/O.

Disconnect behavior is testable too: closing the CarPlay window in Xcode fires sceneDidDisconnect. Cycle through connect, play, disconnect, reconnect a few times before you submit. Reviewers do check that flow, and a stale interface controller reference is an easy way to crash on reconnect.

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. In my case the entitlement was the problem. My development profile carried the CarPlay capability, but I'd never regenerated the distribution profile, so the archived build shipped without it. Now I run codesign -d --entitlements :- YourApp.app against the built product and read the keys with my own eyes before uploading. The simulator never checks signing, so this is exactly the gap it can't cover for you.

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, Building Production-Ready iOS Apps with Rork and Rork Max App Store Approval Guide pair well with this article.

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.

Before any of it works, you need to be able to separate in-car activity from phone activity. Tag every event with the surface it came from, driven by the scene lifecycle — retrofitting this later means the first month of data is unrecoverable.

final class CarPlaySessionTracker {
    static let shared = CarPlaySessionTracker()
    private(set) var isConnected = false
    private var connectedAt: Date?
 
    func markConnected() {
        isConnected = true
        connectedAt = Date()
    }
 
    func markDisconnected() {
        defer { isConnected = false; connectedAt = nil }
        guard let start = connectedAt else { return }
        Analytics.log("carplay_session_end", params: [
            "duration_sec": Int(Date().timeIntervalSince(start))
        ])
    }
 
    var surface: String { isConnected ? "carplay" : "phone" }
}

Attach surface as a global parameter on every event you emit. With that in place, the playbook below becomes measurable rather than anecdotal.

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.

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.

It's worth deciding early whether Android Auto is in scope. It's a separate Google platform with its own APIs, review process, and UI conventions, so treat it as a second implementation track rather than a port. Committing to both without budgeting for that doubles the maintenance surface you just signed up for.

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.

Your First Step — Pick One Category and Write the Request

For a long time I treated CarPlay as an implementation problem. Looking back, the part I kept getting stuck on came earlier than any code. I was choosing templates and answering review questions before I'd decided which category I was shipping under, so every answer moved.

So the first step I'd suggest isn't code — it's opening Apple's CarPlay developer page, picking the single category closest to what your app already does, and writing roughly 500 characters on the three criteria: in-drive necessity, safety consideration, category fit. If you can write it, the implementation will wait for you. If you can't, what's missing probably isn't Swift — it's the value that only exists while someone is driving.

If the request doesn't fit in one paragraph, the feature isn't ready for the car yet. That's the one line I try not to cross, even on days when the code is already running.

Thank you for reading this far. The in-car context is still unfamiliar ground for me, and I'll keep writing down what I find.