CarPlay
from Zero.

Building Your First In-Car Experience

SwiftLeeds 2026

From the first idea
to the car.

Speakers

Eyad Kelleh
Kassel, Germany
Indie App Developer

Maurice Pfurr
Kassel, Germany
Indie App Developer

Friendships.
Dream.
Development.
Applications.

We built something together.

The two friends together at an Aral pulse charging station, holding the phone app

We had
an iPhone app.

Find a charger.
Compare prices.
Choose a stop.

Charge a Smile

Illustration of a phone lying on a passenger seat

“Where can I
charge next?”

The question changes when the drive begins.

Illustration

The phone should
stay in your pocket.

Your iPhone app.
On the car’s screen.

Actual Charge a Smile iPhone screenshot showing charging stations on a map of Berlin

Your app runs
on the iPhone.

Apple’s point-of-interest template: selectable places beside a map — CarPlay presents an interface built for the car.

The driver’s attention
sets the rules.

Eyes on the road.

Keep one useful driving task.
Leave unrelated features out.

Not the whole iPhone app.

Different car controls.

Use familiar templates.
iOS handles layout and input.

Not a custom SwiftUI screen.

The phone stays away.

Every CarPlay flow must work
without touching the iPhone.

No “pick up your phone” step.

We choose the content and actions. Apple defines the interface boundaries.

For each column, say the reason first, then the rule, then one thing we leave out. The audience needs the why before the API names.

The car changes the design problem. A driver has limited attention. Apple asks us to focus on the app’s primary driving task, rather than reproduce every feature from the phone.

Vehicles have different screens and input controls. We fill supported templates with content and actions; iOS renders the layout and handles the car’s input hardware. A charging app cannot mount its existing SwiftUI view on this screen.

Apple requires CarPlay flows to work without iPhone interaction. Complete account setup before driving; if a login is missing, explain that state without telling the driver to pick up the phone. This is a design requirement, not something a successful build proves.

Our explanation of the reasons is a design summary of Apple’s guidance, not a claim that each limit has a separately published safety measurement. Templates reduce what we need to design; they do not remove our responsibility to test.

So what do those templates look like?

Sources: Apple CarPlay Developer Guide, June 2026, printed pages 4 and 11–14; Apple’s CarPlay design principles. Requirements and design responses are separated in CARPLAY_IMPLEMENTATION.md.

Apple defines
the layouts.

Apple information template — Information

Apple point-of-interest template — Point of interest

Keep this visual and short. Point across the six layouts. Name that the category decides which layouts you may use, then move on.

CarPlay does not give us a blank canvas. Apple supplies templates: tab bar, list, grid, information, point of interest, map, and others such as Now Playing, alert, and search.

We fill a template with content and actions. iOS draws the layout for the car display. That is why the next decision is which category we are allowed to use—not which custom screen we prefer.

Match the driver’s primary task to a category: audio needs Now Playing, navigation needs Map, charging gets Point of interest and Information—not Map. Search and Voice control reach charging apps in iOS 27.

Next, what an entitlement actually is—and how we got charging approved.

Diagrams: Apple CarPlay Developer Guide. Template catalog: CarPlay documentation.

An entitlement
is permission.

Apple approves the app’s purpose.
A key in a file is not enough.

1
Join the developer program.
A paid Apple Developer account.
2
Request the right category.
For our app: EV charging.
3
Configure the approved capability.
App ID, signing profile, entitlements.

developer.apple.com/contact/carplay ↗

Three beats. Advance once for the request, once for project setup. Say once how we chose EV charging before the approval steps.

Start from the driver’s task: “My app helps the driver to…” Audio plays something. Navigation gives turn-by-turn. Our app helps choose a charging stop, so we requested EV charging—not navigation. Apple’s June 2026 guide also permits charging with fueling, and audio with video; do not teach a universal one-category rule.

We needed the paid developer program and Apple’s approval for the charging category. The request explains the app’s use case. Approval does not happen because the Swift compiles.

After approval, the capability has to match the App ID, provisioning profile, and entitlements in the project. We used tooling to help with setup, but checked that configuration.

For our app, that choice draws a clear line between finding a charger and navigating to it.

Source: Requesting CarPlay Entitlements. No approval-time promise is implied.

Charging is our category.

Find a charging stop.

We refresh the chargers.
CarPlay manages the map.

com.apple.developer.
carplay-charging

Provide turn-by-turn.

Requires turn-by-turn guidance.
Not an extra map permission.

com.apple.developer.
carplay-maps

Refresh charger pins: yes. Build our own navigation map: not with charging.
Our “Navigate” action opens Apple Maps for driving directions.

Separate three things: updating chargers, moving the map view, and giving directions.

Finding a charger and giving driving directions are two different jobs. We chose charging: we supply the places, and CarPlay supplies the point-of-interest map.

Those places can refresh as the location or visible region changes. That is different from drawing and controlling our own navigation map.

Why can’t we just add the navigation entitlement? An entitlement is Apple’s approval for a qualifying app category, not a switch that unlocks any UI we want. A navigation app must actually provide turn-by-turn directions. Even then, its custom window is for map content—not arbitrary controls or SwiftUI screens.

Apple documents charging + fueling and audio + video as permitted pairs. It does not document charging + navigation as a general pairing. Do not teach a universal ban on two entitlements or promise that a second key fixes map-following behavior.

Our Navigate action opens Apple Maps. We did not need to build turn-by-turn navigation to help the driver choose the next charging stop.

For Q&A: Apple describes refreshing places after panning, zooming, or movement. Our code also reloads nearby stations after a location-distance threshold. Charging does not provide the navigation window for drawing our own map.

For Q&A: Do not say that a missing navigation entitlement freezes the map or the stations. A specific map-following problem needs its own runtime check. Entitlement approval and map-following behavior are separate questions.

So which building blocks could we use for our own interface?

Sources: Apple’s point-of-interest walkthrough; CPWindow. Local implementation: CarPlayTabManager.handleLocationUpdate, pointOfInterestTemplate(_:didChangeMapRegion:), and CarPlayNavigationHelper.startNavigation; CarPlayConstants.hasCarPlayMapsEntitlement is false.

Four starting points
for our tabs.

Design the next decision.

Point-of-interest template for nearby chargers — FindNearby chargers

List template for the station detail screen — ChooseStation details

We worked out the flow in Figma before asking for Swift.

“Hey Siri,
show fast chargers
in Charge a Smile.”

App Shortcuts give the task a voice entry point.

Read the phrase as a driver would, then pause.

The goal was for the phone to stay in the pocket. A voice entry point belongs in that design, because the car screen can still demand attention.

This English phrase is registered in our App Shortcuts. It triggers the fast-charging intent. App Intents sit alongside the CarPlay templates; they are not a special Siri row inside our charging list.

Do not promise that every phrase works in every situation or that voice removes all distraction. Rehearse the behavior on the exact device and language you will demonstrate.

We now had the driver task, the platform rules, and the flow. Here is how we turned that into an implementation.

Source: local AppShortcuts.swift, CASAppShortcuts and FastChargingIntent.

We built it
with an agent.

We defined the experience.

The agent wrote Swift.

We reviewed, tested, and iterated.

Give the agent
something it can trust.

Current docs.

Apple’s rules,
captured in a skill.

A clear flow.

Figma mockups
and written requirements.

A firm boundary.

Charging templates.
Navigation via Maps.

The prompt came after the preparation.

Build.
Inspect.
Fix. Repeat.

The agent calls Xcode itself.

Build project
Run tests
Debug

CarPlay Simulator
Check the interaction.

Human review
Compare with the intended flow.

One app.
A second scene.

1
Declare the
CarPlay scene.
Configuration tells iOS
which delegate to call.
2
Open the app
in CarPlay.
iOS creates the scene
and calls our delegate.
3
Receive the
UI controller.
It manages templates.
It does not load chargers.
4
Install the
first template.
Our tab bar + POI view.
Then populate the content.

CarPlay can launch without the phone interface opening first.

On disconnect: remove observers and release the controller.

Four clicks tell a sequence, not four disconnected API names. Start with the already-approved app and a paired car. Explain that a scene is a separate interface lifecycle within the same app.

First, declare the CarPlay scene and delegate in the app’s scene configuration. This is how iOS knows which object should handle the car interface. It does not replace the entitlement or the phone’s scene.

When the driver opens our app in CarPlay, iOS creates the scene and calls the delegate’s didConnect method. For our charging app, it passes a CPInterfaceController. That object controls which template is shown; it is not a network connection or a charging-data service.

Our delegate keeps the controller and starts CarPlayTabManager. The manager creates the Charge and Route tabs and installs the tab bar with setRootTemplate. It also observes location updates so the charging template can be populated.

The CarPlay scene must initialize what it needs without waiting for the phone screen. On disconnect, our code stops its observers and clears its manager and interface-controller references. Ongoing asynchronous work needs lifecycle handling too; do not treat disconnect as automatic cancellation of every task.

For Q&A: navigation has a different didConnect variant that also supplies a CPWindow for map drawing. A charging scene receives the interface controller, not a blank canvas for arbitrary views.

Where does the content come from? From the same app services we already use on the phone.

Sources: Displaying Content in CarPlay; CPInterfaceController; Apple’s scene lifecycle walkthrough. Local evidence: Info.plist, AppDelegate, CarPlaySceneDelegate and CarPlayTabManager.start/stop.

Same app. Shared services.
Separate interfaces.

Our app runs on the iPhone.

Shared services & saved preferences

Chargers · prices · location
Selected charging tariffs

iPhone interface

SwiftUI views for exploring.

CarPlay scene

Our code builds templates.
It keeps its own screen state.

Templates → Apple point-of-interest template illustrating the interface presented on the car display

Car display

iOS renders it.

← Driver actions

Share the services—not the SwiftUI view. No second app installed in the car.

Trace the border: both interfaces and the services are inside the app running on the iPhone. Only then point to the car display. The border explains more than an API name.

CarPlay support is part of the existing iPhone app, not a second app installed on the car. The CarPlay scene can start even when the phone interface has never opened, so do not make it depend on a phone view loading first.

In our code, the phone’s map manager and the CarPlay manager both use ChargingDataService.shared. Both surfaces also use the pricing service and UserPreferences.shared. The selected charging tariffs are reused when CarPlay calculates the displayed price.

Shared services do not mean identical screens or automatically synchronized selections. The CarPlay manager has its own station cache, filter, and selected station. It loads data and turns it into templates instead of reading pixels or SwiftUI state from the phone screen.

For Q&A: in this app, these scenes can access common services in the same application process. There is no need to introduce an App Group merely for the CarPlay scene. Separate extensions are a different architecture question. Changes still need explicit reads, observation, and template updates where appropriate.

Let’s follow one charger from the data service to a pin on the car screen.

Sources: Apple guide, printed pages 11 and 14: existing app, templates, and rendering responsibilities; Apple: CarPlay can launch without the iPhone scene. Local evidence: ChargingStationMapManager, CarPlayTabManager, CarPlayPricingHelper, UserPreferences, and casApp. See CARPLAY_IMPLEMENTATION.md.

From a charger record
to a pin.

Our app loads.

Station name

Coordinates + power

Price for our tariff

Data service + preferences

Our code adapts.

Name → title

Coordinates → pin

Power + price → subtitle

Build the point of interest

Apple template illustration: the system renders a place picker and map pins — Update the POI template.
CarPlay draws the list + map.

Driver taps Details → our handler runs → we build the detail template.

New location or data? Our app must refresh the template.

Start with the record. Reveal the mapping, then the rendered template, then the return arrow. The point is the two-way loop: data out, actions back.

Our app asks its charging-data service for stations in an area. It combines those records with saved tariffs and pricing information. CarPlay does not query our backend for us.

Our CarPlay code filters and ranks the results, then creates a CPPointOfInterest for each visible charger. The station’s name becomes a title; its coordinates become a map location; power and price become a short subtitle. This adapter is our code, not an automatic conversion of a SwiftUI view.

We update the template on the main actor. iOS presents the picker, pins, and supported controls. When a driver taps our Details action, its handler calls our station-detail builder and pushes the resulting list template through the interface controller.

Location or map-region changes trigger fresh work in our implementation. Loading, empty results, errors, and selected-item state need explicit handling. A shared service is not an automatic live binding between its data and every CarPlay template.

But do we need to sit in the car for every change? No. Here is the desktop setup.

Sources: Apple guide: app supplies model and controller, iOS renders the view; Updating points of interest. Local evidence: CarPlayTabManager.loadStationsForRegion, createPointOfInterest, applyLadenMapPOIsNow, and pushStationDetail; CarPlayStationDetailBuilder. Diagram is explanatory, not a live connection.

Test CarPlay
at your desk.

A real iPhone. A simulated dashboard.

Setup illustration · not a Simulator capture.

Actual Charge a Smile map screenshot inside an illustrative iPhone frame — Setup illustration · not a Simulator capture.

1
Download.
Additional Tools for Xcode
Apple Developer · More Downloads
2
Connect.
iPhone → Mac by USB.
Open CarPlay Simulator.
3
Run.
Launch the app on iPhone
from Xcode.

Setup: approved entitlement · development-signed app · Developer Mode

Xcode 27: Device Hub supports USB-connected iPhones, not simulated iPhone CarPlay.

Download Additional Tools ↗

Point to iPhone → USB → Mac. Use three clicks: download, connect, run. Leave details here for questions, rather than reading the footnote aloud.

You do not need a car for every development check. The iPhone still runs our app; the Mac runs CarPlay Simulator and acts as the dashboard.

Sign in to Apple Developer More Downloads and get Additional Tools for Xcode. Open CarPlay Simulator from the Hardware folder. Connect the iPhone to the Mac with a USB data cable.

Use an approved CarPlay entitlement and a development-signed build. Enable Developer Mode on the iPhone. Run the app on that phone from Xcode, then open it in CarPlay Simulator on the Mac.

In Xcode 27, Device Hub also supports CarPlay for USB-connected physical iPhones. It does not support CarPlay on a simulated iPhone. The Additional Tools Simulator is another useful desktop setup; this slide does not claim it is the only route.

Developer Mode is for development-signed apps; ordinary App Store and TestFlight installs do not require it. Follow the pairing and trust prompts on your own devices. This diagram is an illustration, not a Simulator capture or proof of a live connection.

Next, test the whole journey: launch, lock, refresh, reconnect.

Sources: Apple CarPlay Developer Guide, June 2026, printed page 8; Apple staff: CarPlay in Device Hub; WWDC26: CarPlay Simulator; Developer Mode. Checked 25 September 2026. Full setup: CARPLAY_SIMULATOR.md.

Test the journey.
Not just the build.

Cold launch.

Lock.

Refresh.

Reconnect.

Simulator first. Then the real car, with a safe test setup.

We tested in the simulator and in a real car. This is the expanded checklist we recommend; it is not a claim that every lifecycle case shown here was verified while preparing this deck.

Launch from CarPlay without opening the phone screen first. Check the experience with a locked phone, including access to the data it needs. Refresh with changed results, an empty response, or an error. Disconnect and reconnect: observers, loading work, and selection state must remain correct.

Also exercise selection and the navigation handoff, different displays, input controls, and day/night appearance. Use a parked vehicle for interactive testing, or have a passenger operate and record during a drive.

We can show the experience through screenshots. The presentation does not depend on a live simulator.

Now let’s follow the flow we have been building toward.

Sources: planning meeting on simulator and real-car testing; Apple: independent CarPlay launch; Displaying Content in CarPlay. Additional lifecycle checks are recommendations, not newly performed device tests.

Illustrated car interior framing the real app screenshots

Now, into the car.

Charge a Smile CarPlay screenshot showing nearby chargers, prices, distances, and map pins around Kassel

Find nearby chargers.

Actual Charge a Smile screenshots in an illustrated car interior.

Begin with the screen in the car. Three advances enlarge the selected station, details, and trip summary. On the Bremen frame, say aloud: trip summary, not turn-by-turn in our app—Start Navigation hands off to Apple Maps. Advance once more for the closing statement. Pause for three seconds; this is the payoff, not another technical explanation.

These are screenshots of Charge a Smile in CarPlay. First, the driver sees nearby chargers. Choosing a station opens its actions, and Details shows the information needed to decide.

The final screenshot is a separate trip-planning example for Bremen. It shows a route summary and a charging stop. It does not show turn-by-turn navigation inside our app. Start Navigation hands navigation to Apple Maps.

One useful task, now in the car. That brings us back to the goal: help someone choose a charging stop without reaching for their phone. These screens show the experience we built, not a claim that in-car interaction removes all distraction.

That is the journey from our phone app to CarPlay. What is the one useful task in your app?

Screenshots supplied by the speakers: IMG_9477.PNG, IMG_9479.jpg, IMG_9481.PNG, IMG_9483.PNG. Original capture text and values are unchanged. The car interior is generated imagery; these are still screenshots, not a video recording.

Your implementation
checklist.

1
Check the task and the rules.
Category → approval → supported templates and limits.
2
Connect a scene to shared services.
Declare → receive controller → set root → populate.
3
Direct and verify the agent.
Document → design → build feedback → human review.
4
Test the whole lifecycle.
Cold launch · locked phone · refresh · disconnect.

developer.apple.com/carplay ↗

Make this an invitation, not a second summary of every API. Name the four checklist items briefly. Finish on one concrete action.

Our starting point was a driver who needed a charger. That led us to a category, a small set of templates, and a flow we could explain.

We used documentation, skills, an agent, and XcodeBuild MCP to implement it. Document the rules, design the flow, then direct and verify the agent. We still had to check the behavior and iterate.

Before opening Xcode, finish this sentence: “My app helps the driver to…” That answer is your starting point for the category, the templates, and the first screen.

Thank you. We would love to hear what you want to bring into the car.

Starting point: Apple’s CarPlay developer resources.

Thank you

Stay connected

Eyad Kelleh

Kassel, Germany

Indie App Developer

Maurice Pfurr

Kassel, Germany

Indie App Developer

CarPlayfrom Zero.

Speakers

Eyad Kelleh

Maurice Pfurr

Friendships.Dream.Development.Applications.

We hadan iPhone app.

“Where can Icharge next?”

The phone shouldstay in your pocket.

Your iPhone app.On the car’s screen.

The driver’s attentionsets the rules.

Eyes on the road.

Different car controls.

The phone stays away.

Apple definesthe layouts.

An entitlementis permission.

Join the developer program.

Request the right category.

Configure the approved capability.

Charging is our category.

Find a charging stop.

Provide turn-by-turn.

Four starting pointsfor our tabs.

Design the next decision.

“Hey Siri,show fast chargersin Charge a Smile.”

We built itwith an agent.

Give the agentsomething it can trust.

Current docs.

A clear flow.

A firm boundary.

Build.Inspect.Fix. Repeat.

One app.A second scene.

Declare theCarPlay scene.

Open the appin CarPlay.

Receive theUI controller.

Install thefirst template.

Same app. Shared services.Separate interfaces.

Our app runs on the iPhone.

Shared services & saved preferences

iPhone interface

CarPlay scene

Car display

From a charger recordto a pin.

Our app loads.

Our code adapts.

iOS presents.

Test CarPlayat your desk.

iPhone

Mac

Download.

Connect.

Run.

Test the journey.Not just the build.

Now, into the car.

One useful task.Now in the car.

Your implementationchecklist.

Check the task and the rules.

Connect a scene to shared services.

Direct and verify the agent.

Test the whole lifecycle.

Thank you

Eyad Kelleh

Maurice Pfurr

CarPlay
from Zero.

Friendships.
Dream.
Development.
Applications.

We had
an iPhone app.

“Where can I
charge next?”

The phone should
stay in your pocket.

Your iPhone app.
On the car’s screen.

The driver’s attention
sets the rules.

Apple defines
the layouts.

An entitlement
is permission.

Four starting points
for our tabs.

“Hey Siri,
show fast chargers
in Charge a Smile.”

We built it
with an agent.

Give the agent
something it can trust.

Build.
Inspect.
Fix. Repeat.

One app.
A second scene.

Declare the
CarPlay scene.

Open the app
in CarPlay.

Receive the
UI controller.

Install the
first template.

Same app. Shared services.
Separate interfaces.

From a charger record
to a pin.

Test CarPlay
at your desk.

Test the journey.
Not just the build.

One useful task.
Now in the car.

Your implementation
checklist.