CarPlay vs Android Auto App Development: The Complete Guide 2026

If you have built mobile apps before, you might assume that CarPlay and Android Auto are just another screen to target. That assumption will cost you months. In-car platforms are not miniature phones. They are heavily restricted environments where Apple and Google dictate what categories of apps are allowed, what UI templates you can use, and how many interactions a driver can perform before the system cuts you off.

As of 2026, roughly 98% of new vehicles sold in the US support at least one of these platforms, and most support both. That is a massive addressable market. But the opportunity comes with guardrails that would frustrate any team accustomed to building freeform mobile UIs. You cannot render custom views. You cannot use arbitrary animations. You cannot build a feed that scrolls indefinitely. Every design decision passes through a distraction-prevention filter enforced at the OS level.

The reason for all of this is straightforward: people die in car accidents. The National Highway Traffic Safety Administration (NHTSA) and equivalent international bodies have published driver distraction guidelines that both Apple and Google have adopted as baseline requirements. Your app will be rejected if it takes the driver's eyes off the road for more than two seconds at a time, or if it requires complex input sequences while the vehicle is in motion. These are not suggestions. They are enforced through template constraints and review processes that will block your release.

This guide covers both platforms from the ground up. We will walk through allowed app categories, the template and UI systems, design constraints, approval and review requirements, testing with simulators and real hardware, and the market opportunity that makes all of this effort worthwhile. If you are evaluating whether to build for one or both platforms, this is everything you need to make that call.

CarPlay development starts with a hard truth: Apple only allows a small set of app categories on the platform. As of iOS 17 and continuing through iOS 19, the approved categories are navigation, audio, messaging, VoIP calling, EV charging, fueling, parking, quick food ordering, and driving task apps. If your app does not fit one of these categories, it cannot appear on CarPlay. Period. There is no general-purpose app category and no way to petition Apple for a new one outside of WWDC announcements.

The technical foundation is CPTemplateApplicationScene, introduced as part of Apple's scene-based lifecycle. Your CarPlay app runs as a separate scene from your iPhone app, meaning it has its own lifecycle, its own window, and its own UI hierarchy. You declare CarPlay support in your Info.plist with the appropriate entitlement, and Apple must grant you that entitlement before you can even test on a real car. During development you can use the Xcode CarPlay Simulator, but for App Store submission you need the entitlement approved.

The UI is built entirely from templates. CPTabBarTemplate, CPListTemplate, CPGridTemplate, CPMapTemplate, CPSearchTemplate, CPNowPlayingTemplate, CPPointOfInterestTemplate, and CPInformationTemplate are your building blocks. You do not create custom UIViews for the car display. You instantiate a template, populate it with data, and push it onto the template stack. Apple controls the rendering, the font sizes, the spacing, and the interaction model. Your job is to provide content, icons, and callbacks.

Navigation Apps

Navigation apps get the most flexibility because they use CPMapTemplate, which allows you to render a custom map view on the car's display. You handle the MKMapView (or your own map renderer) and overlay CPManeuver objects for turn-by-turn directions. Apple provides CPNavigationSession for managing active routes, and CPTrip for representing route options. The map is the one place where you have pixel-level control, but even here you must follow Apple's guidelines for contrast, icon sizing, and information density.

Audio Apps

Audio apps (music, podcasts, audiobooks) use CPListTemplate for browsing content and CPNowPlayingTemplate for playback controls. The now-playing screen is standardized: album art, play/pause, skip, and up to four custom buttons. You surface your content hierarchy through nested list templates, but Apple limits the depth to five levels and the number of items per list section. If your library has 50,000 songs, you need smart categorization and search, not endless scrolling.

Messaging and VoIP

Messaging apps use SiriKit intents (INSendMessageIntent, INSearchForMessagesIntent) rather than templates directly. Siri handles the voice interaction, reads incoming messages aloud, and transcribes the driver's dictated replies. You provide the messaging backend and intent handlers. VoIP apps similarly integrate through CallKit and use CPCallTemplate for the in-call UI. In both cases, the driver never types. All input is voice-driven.

The entitlement process deserves emphasis. You request a CarPlay entitlement through your Apple Developer account, specifying your app category. Apple reviews the request manually, and approval can take days to weeks. Without it, your CarPlay code compiles and runs in the simulator but will not function on actual CarPlay hardware or pass App Store review. Plan for this in your timeline.

Android Auto takes a similar philosophical approach to CarPlay but implements it through a different technical stack. Google's Car App Library (part of Android Jetpack, under androidx.car.app) provides the template system, and the allowed app categories closely mirror Apple's: navigation, parking, EV charging, and media. Google also supports messaging through Android Auto's notification-based system rather than templates.

The Car App Library uses a host-client architecture. Your app runs on the phone (the client), and Android Auto on the car's head unit acts as the host. The host renders the templates your app provides. You never draw directly to the car's screen (except for navigation map rendering). This architecture means your app works across every Android Auto-compatible vehicle without you writing vehicle-specific code.

The template types in the Car App Library are ListTemplate, GridTemplate, PaneTemplate, MessageTemplate, SearchTemplate, PlaceListMapTemplate, NavigationTemplate, and TabTemplate. If you have worked with CarPlay templates, the conceptual overlap is obvious. Google enforces a template stack depth limit (typically five or six levels), a maximum number of list items per screen, and restrictions on how quickly you can push new templates (to prevent rapid UI changes that distract the driver).

Navigation Apps on Android Auto

Navigation apps use NavigationTemplate combined with a SurfaceContainer that gives you a drawing surface for your map. You render your map using the Surface API, similar to how you would draw on a SurfaceView in a regular Android app. Google provides TurnByTurnNavigationManager and NavigationManagerCallback for managing active navigation sessions. You supply Step objects with lane guidance, distance information, and maneuver icons. The framework handles rendering the turn card overlay.

Media Apps

Media apps on Android Auto use a different path. Instead of the Car App Library, they implement MediaBrowserServiceCompat and MediaSessionCompat from the standard Android media APIs. Your app exposes a browsable content tree through the MediaBrowserService, and Android Auto renders it using its own UI. You control the content hierarchy, metadata, and playback state. Android Auto controls the visual presentation. This is actually simpler than the Car App Library approach for pure media apps, since MediaBrowserService is a well-established pattern that also powers Android TV, Wear OS, and Google Assistant media integration.

Messaging on Android Auto

Messaging on Android Auto works through notifications with Android Auto extensions. You post a MessagingStyle notification with a RemoteInput for replies. Android Auto detects the notification, reads it aloud via text-to-speech, and captures voice replies through the car's microphone. You handle the reply in your notification's PendingIntent. There are no custom messaging templates. The entire UX is driven by the notification system, which keeps driver interaction minimal.

Unlike CarPlay, you do not need a special entitlement from Google to develop for Android Auto. You declare <uses-feature android:name="android.hardware.type.automotive" /> in your manifest and add the appropriate Car App Library dependencies. Testing is available immediately through the Desktop Head Unit (DHU) tool that ships with Android Studio. This lower barrier to entry is a significant advantage for teams that want to prototype quickly, though Google's review process at Play Store submission is still rigorous.

Both Apple and Google enforce driver distraction guidelines that fundamentally shape what your app can do. These are not vague design recommendations. They are hard rules encoded into the template systems, and violating them will get your app rejected.

The NHTSA Visual-Manual Driver Distraction Guidelines form the basis for both platforms. The core principles are: a single glance at the screen should take no more than two seconds, a complete task should require no more than 12 seconds of total eyes-off-road time, and the number of interactions (taps, swipes) required to complete any task should be minimized. Both Apple and Google interpret these guidelines through their template constraints.

On CarPlay, Apple enforces these rules by limiting list item counts (typically 12 items visible per section), restricting template stack depth, and controlling text length on buttons and list items. Long strings get truncated automatically. You cannot override this behavior. If your navigation app generates verbose route descriptions, CarPlay will cut them off. Design for brevity from the start.

On Android Auto, Google enforces a "task flow limit" that restricts how many template transitions a user can perform before the system shows a "try again later" message. This prevents apps from creating deep interaction chains. Google also limits the number of items per list, the number of actions per template, and the complexity of grid layouts. The Car App Library documentation specifies these limits per template type, and they vary slightly between API levels.

What This Means for Your UX

You need to design for glanceability. Every screen your driver sees must communicate its purpose in under two seconds. That means large touch targets (minimum 76x76dp on Android Auto, similar on CarPlay), high-contrast text, simple iconography, and ruthless content prioritization. If your phone app shows 50 items in a list, your car app shows 5 to 8 with smart defaults and voice search for the rest.

Voice interaction is not optional. Both platforms strongly encourage (and in some categories require) voice as the primary input method. CarPlay uses Siri. Android Auto uses Google Assistant. Your app should handle intent-based voice commands for its core functionality. For messaging apps, voice is the only input method. For navigation apps, voice search for destinations is expected. For audio apps, voice commands for playback control and content selection are table stakes.

Night mode is another requirement both platforms enforce. Your app must support a dark color scheme that activates when the car's headlights are on. CarPlay handles this automatically through its template rendering. On Android Auto, you need to handle the day/night callback from the Car App Library's ScreenManager and adjust your map rendering and any custom surfaces accordingly. Failing to support night mode is a common rejection reason.

Getting your CarPlay or Android Auto app approved requires understanding the distinct review pipelines for each platform. Both are stricter than standard mobile app review, and both can add weeks to your launch timeline if you are not prepared.

Apple CarPlay Review

Apple's process has two gates. First, you must apply for a CarPlay entitlement through your developer account. You select your app category, describe your app's functionality, and explain why it belongs on CarPlay. Apple reviews this manually. Approvals typically take one to three weeks, though we have seen them take longer during peak submission periods (around WWDC and September iPhone launches). Without the entitlement, your app cannot access CarPlay APIs on real hardware.

Once you have the entitlement, you build and submit your app through the standard App Store Connect process. The review team tests your CarPlay implementation specifically, checking that you use templates correctly, that your app responds appropriately to lifecycle events (connecting, disconnecting, backgrounding), and that your content adheres to the distraction guidelines. Common rejection reasons include excessive list item counts, non-functional buttons, missing artwork for templates, and audio apps that do not properly implement CPNowPlayingTemplate.

Google Android Auto Review

Google does not require a separate entitlement application. You build your app with the Car App Library, include the appropriate manifest declarations, and submit through Google Play Console. However, Google does require you to fill out a "Car app quality" declaration during submission, confirming that your app meets their design and quality guidelines.

Google's review checks are thorough. They verify that your app handles the host-client lifecycle correctly, that templates render properly across different screen sizes and aspect ratios, that your app recovers gracefully from connection interruptions, and that the overall interaction flow stays within the task complexity limits. Google also runs automated distraction compliance checks that flag apps with too many template transitions or overly complex navigation structures.

For both platforms, plan on at least two review cycles for your first submission. Your initial attempt will almost certainly surface issues you did not catch during local testing. This is normal. Budget the time for it. If you are working with a development partner, make sure they have direct CarPlay and Android Auto shipping experience, not just mobile experience. The review requirements are specific enough that general mobile expertise is not sufficient. For a deeper look at budgeting for projects like this, our mobile app cost breakdown covers the planning process in detail.

Testing in-car apps is more involved than standard mobile testing because you are working with two screens, two interaction models, and a connection layer between them. Both platforms provide simulator tools, but real-hardware testing is essential before submission.

CarPlay Simulator (Xcode)

Xcode includes a CarPlay Simulator that runs alongside the iOS Simulator. You enable it through the I/O menu in the Simulator window. It provides a secondary display that mimics a car head unit, with support for different screen sizes and resolutions. You can test template rendering, lifecycle events (connect, disconnect), and user interactions. The simulator supports all CarPlay template types and accurately represents the constraints Apple enforces.

However, the simulator does not perfectly replicate real-world behavior. Audio routing, Siri integration, and Bluetooth connectivity quirks only surface on real hardware. Map rendering performance in the simulator may differ significantly from actual car displays, which vary in resolution from 800x480 to 2560x720 depending on the vehicle. Test early and test often on at least one physical CarPlay head unit.

Android Auto Desktop Head Unit (DHU)

Google provides the Desktop Head Unit (DHU) as part of Android Studio. The DHU runs on your development machine and connects to your app running on a physical Android phone or emulator via ADB. It simulates the car's head unit display with configurable resolution, DPI, and input modes (touchscreen, rotary controller, touchpad). The DHU is more flexible than Apple's simulator in terms of configuration options, which is important because Android Auto runs on a much wider variety of car displays.

The DHU supports day/night mode toggling, microphone input for voice testing, and media playback controls. For navigation apps, it can simulate GPS location input. One limitation: the DHU does not perfectly replicate the rendering performance of actual car head units, which range from budget infotainment systems with limited GPU power to high-end units with dedicated graphics processors.

Real-Hardware Testing

Both platforms require real-hardware testing before you submit. For CarPlay, you need a Lightning or USB-C cable and a CarPlay-compatible head unit (aftermarket units from Pioneer, Kenwood, or Sony work well for development). Wireless CarPlay testing requires a compatible head unit that supports the wireless protocol. For Android Auto, you need a USB cable and an Android Auto-compatible head unit, or a vehicle with built-in Android Auto support.

If you are building a cross-platform in-car app, our advice is to maintain a small fleet of test devices and at least two aftermarket head units. The investment pays for itself in avoided review rejections. Test across multiple screen sizes, test connection and disconnection scenarios, test audio interruptions (incoming calls, navigation prompts from other apps), and test with the vehicle actually in motion if possible. Many distraction-related bugs only appear when the vehicle speed triggers the platforms' enhanced driving-mode restrictions. For teams evaluating their cross-platform strategy, our Apple vs Android cross-platform guide covers shared architecture decisions that apply to in-car development as well.

The in-car app market is still surprisingly underbuilt. While hundreds of thousands of apps compete in the iOS App Store and Google Play, the number of apps available on CarPlay and Android Auto is in the low thousands. Most categories have a small number of dominant players and significant room for competition. If you are building in the navigation, audio, EV charging, or parking space, you are entering a market with far less competition than any equivalent phone app category.

The addressable audience is enormous and growing. Over 600 million vehicles worldwide now support CarPlay, Android Auto, or both. New vehicle sales are approaching universal support. Drivers spend an average of 51 minutes per day in their cars in the US, and a growing percentage of that time involves interaction with the infotainment system. Apps that reduce friction for common in-car tasks (finding a charger, paying for parking, playing audio content, getting directions) have a captive audience with high engagement and low tolerance for poor UX.

Real-World Use Cases Worth Building

EV charging apps are one of the fastest-growing categories. As EV adoption accelerates, drivers need apps that find nearby chargers, show real-time availability, and initiate charging sessions from the car's screen. ChargePoint, PlugShare, and a handful of others dominate, but the category is far from saturated, especially for regional networks and fleet operators.

Parking apps represent another strong opportunity. Apps that let drivers find, reserve, and pay for parking from the car display solve a genuine daily problem. The interaction model is simple (search, select, pay), which maps perfectly to the template-based UI constraints. SpotHero and ParkMobile lead, but coverage gaps exist in most mid-size cities.

Quick food ordering was added as a CarPlay category in iOS 16, and the space is still early. Apps that let drivers place orders from familiar restaurants and arrive for pickup are a natural fit for the in-car context. The template UI works well for menu browsing with limited options, and payment can be handled through the phone app's stored credentials.

Audio apps beyond music are another compelling category. Podcast apps, audiobook apps, language learning apps, and news briefing apps all benefit from the in-car context where audio is the dominant content format. If you are building an audio-first product, CarPlay and Android Auto support should be part of your v1 roadmap, not a future nice-to-have.

Building for Both Platforms

If your app category is supported on both CarPlay and Android Auto, build for both. The incremental cost of supporting the second platform is roughly 30-40% of the first, because the design constraints, content architecture, and backend are shared. The template models are different in implementation but similar in concept, so your information architecture and content hierarchy translate directly. The driver-facing UX will look nearly identical across platforms because both platforms enforce similar visual standards.

For native development, you will write Swift for CarPlay and Kotlin for Android Auto. There is no cross-platform framework that abstracts both in-car platforms today. React Native and Flutter do not support CarPlay or Android Auto templates natively. You will need platform-specific code for the car display while potentially sharing business logic, networking, and data layers through your existing cross-platform approach for the phone app.

The in-car app space rewards teams that ship polished, focused experiences. The template constraints actually work in your favor here: they force simplicity, which is exactly what drivers need. If you have a use case that fits the allowed categories and you can execute on the distraction guidelines, the market is waiting. Book a free strategy call to discuss your in-car app concept and get a realistic assessment of timeline, cost, and platform strategy.