Automotive app development: app types, vehicle data, process, and cost

Automotive app development is building the software that drivers, car owners, and fleet managers use around a vehicle: phone apps, web dashboards, and apps on the car screen. With us, a phone app that runs on iOS and Android and reads vehicle data starts at $5,000with the design, the backend, and the vehicle data integrations. A fleet management platform with real-time tracking starts at $20,000.

In an automotive app project, three things are usually harder than the screens: getting data out of the vehicle, following the rules Google and Apple set for in-car apps, and keeping the driver's eyes on the road.

What is automotive app development?

Automotive app development covers apps that run on a phone, in a web browser, in the cloud, and on the car's infotainment screen through Android Auto, Android Automotive OS, or Apple CarPlay. The people who order them are carmakers, fleet operators, rental and car-sharing companies, charging networks, dealers and service centers, and navigation, parking, fuel, and media services.

It is different from embedded automotive software, the code in a car's control units that runs the engine, the brakes, or driver assistance. Carmakers and their suppliers write that code under their own safety processes. We do not build it.

Types of automotive apps

Most automotive apps fall into six types: connected car companion apps, fleet management and telematics, car rental and car sharing, EV charging, dealer and service apps, and in-car apps. They differ in who pays for them and where the vehicle data comes from, and these two things shape the budget more than the number of screens does.

A charging app also depends on how the stations talk to their management system. OCPP, the Open Charge Point Protocol, is widely used for that link. Three versions are available at the moment: 1.6, 2.0.1, and 2.1. Versions 1.6 and 2.0.1 are not compatible, so find out which one the network runs before you plan the integration.

One product often mixes several types. A car-sharing service needs a customer app, a dashboard for its operations team, and sometimes an in-car screen, so plan it as one backend with several apps on top. Our car rental dashboard design concept shows what the customer side of such a product can look like.

Where does the vehicle data come from?

Vehicle data can reach an app in four ways: the carmaker's cloud API, a telematics device in the vehicle, an OBD-II adapter in the diagnostic port, or the driver's phone. Choose your sources before you design any screens. They set what the app can show, how fresh the data is, and what each connected vehicle costs you.

• Carmaker API: connected cars send data to their maker's cloud, and some carmakers open part of it to other companies through a developer program. You get data such as location and fuel or charge level without extra hardware, and sometimes remote commands. Access, data fields, and fees differ by brand, and the car owner may have to give consent.
• Telematics device: a GPS tracker or telematics unit installed in each vehicle. It works across makes and models, which makes it the usual choice for fleets. The device vendor gives you an API or a data feed and sets the price of the hardware and the data.
• OBD-II adapter: a small device in the car's diagnostic port that sends engine data and trouble codes to the phone over Bluetooth or to the cloud over a mobile network. It is cheap, but drivers can unplug it, and the data it can read differs by make and model.
• Driver's phone: GPS and motion sensors give location, speed, and trips with no device in the car. It is the cheapest source and the least exact, because it knows where the phone is, not the car.

Many products combine two sources, for example telematics devices in company vans and the phone for the driver's shift. Each source sends its own format, so the backend converts their data into one data model before any app reads it. Our guide to logistics API integration covers the same problem for carrier data.

“Expect the data provider to change at some point, for example when a carmaker updates its API or a fleet moves to another device vendor. If the backend is the only part that knows each provider's format, such a change is usually backend work, without a new release of every app.”

Evgeny Leonov, CTO at Ronas IT

Apps on the car screen: Android Auto, Android Automotive OS, and CarPlay

An app can reach the car's own screen in three ways. Android Auto runs from the driver's Android phone and shows a driver-optimized version of your app on the car display. Android Automotive OS is Android built into the car, and your app is installed on the car instead of the phone. Apple CarPlay puts iPhone apps on the car display.

None of the three is open to every kind of app. According to Google's Android for Cars documentation, the car supports only certain app categories, including media, messaging, navigation, points of interest such as parking, charging, and fuel, internet of things, and weather. Games can be used only while parked, and video apps primarily while parked. Apple's list includes audio, messaging, navigation, EV charging, fueling, parking, public safety, quick food ordering, voice-based conversational, and driving task apps, plus video apps in supported cars when parked. To bring an app in one of these categories to CarPlay, you request a CarPlay app entitlement from Apple. Small widgets and Live Activities are the exception: if your iPhone app has one, it appears in CarPlay automatically, with no changes required.

For most apps used while driving, both platforms give you a fixed set of templates, such as lists and grids, and the platform draws them with your content. That keeps the apps usable in a moving car. The car version can share the backend and the business logic with the phone app, but its screens are designed again for the templates.

A fleet dashboard, a rental app, or a companion app may not need an in-car part at all. Build one when the driver needs the feature while driving: turn-by-turn directions for delivery drivers, finding and paying for parking, or starting a charging session.

How to design automotive apps for drivers

Design every screen a driver may use while the car moves so that short glances are enough to read it. NHTSA's voluntary driver distraction guidelines from 2013 recommend that a driver can finish a task with glances away from the road of 2 seconds or less and 12 seconds or less in total. They are written for screens built into cars, but they are a useful test for any driver-facing feature.

• Driving and parked modes: while the car moves, show only what the driver needs, and leave sign-up, settings, and long lists for when it stops.
• Short paths: one or two taps for the main action, large buttons, and contrast that works in daylight and at night.
• Voice instead of typing: Android Auto can read messages aloud and take replies by voice, so a driver-facing app should not ask for a keyboard.
• Status first: the charge level, the next stop, or the booking time is the first thing on the screen.
• Separate apps for separate roles: a fleet manager at a desk works with tables and filters, and a driver in the cab needs one next action.

“Hiding a feature while the car moves is simple. The harder design task is to make the wait until the car stops feel normal: the driver should still see that the feature is there.”

Elizaveta Denisova, Lead designer at Ronas IT

Security and privacy in connected car apps

A connected car app handles two sensitive things: where a person drives and the power to open or start their car. Plan how the product protects both from the first sprint.

• Location is personal data: collect only what the feature needs, tell users why, and in fleet apps let drivers stop tracking outside working hours. Privacy laws such as GDPR in the EU and CCPA in California may apply; a lawyer should confirm which ones cover your product.
• Remote commands need a second check: ask for a PIN or biometrics before unlocking or starting the car, log every command, and put a time limit on digital keys shared with other people.
• Vehicle credentials stay on the server: the phone app talks to your backend, and only the backend holds the tokens for the carmaker or device API.
• Weak signal is normal: parking garages often have poor coverage, so a digital key or a trip log has to keep working, or fail safely, without a connection.

Our stack and a driver app we built

We usually build phone apps in React Native with Expo, so one codebase serves iOS and Android, and the backend in Laravel. When a client chooses native apps, we write them in Swift and Kotlin. Sentry tracks errors in production, so crashes on real devices reach the team with their context.

Hamperapp is a laundry pickup and delivery service from Florida. We built native iOS and Android apps, a web app, and interfaces for four types of users, drivers among them. Some drivers did not know the area well, got lost, and wasted fuel, so we built a route optimization feature with Mapbox and used Ably to show new orders to drivers in real time. It was not a car project: its apps did not read vehicle data or run on a car screen.

Automotive app development process

An automotive app goes through six stages, from a data and platform check to support after release. Many app projects can skip the first stage; automotive projects cannot.

1. Data and platform check: before design starts, find out which vehicle data the app can read and on what terms, and whether the product needs an in-car app in a supported category.
2. Discovery and design: map the user roles, the key flows, and the driving and parked states of every driver screen.
3. Development: our sprints usually run one to three weeks, and each ends in something you can open, such as a dev-server update or an interface ready to test.
4. Testing: automated tests gate every commit, then come code review, a team lead review, a manager's review against the scope, and your review on a staging build. Vehicle features also need testing with real devices and cars, so agree early on who provides them. For car screens, Google provides a Desktop Head Unit and an Android Automotive OS emulator.
5. Release: we publish to the App Store and Google Play; Android in-car apps also have to meet Google's car app quality guidelines, and CarPlay apps are subject to additional App Store Review guidelines.
6. Support: the team ships OS and SDK updates and store compliance releases.

How much does automotive app development cost?

The price depends on the app type, the number of user roles, and the vehicle data sources. A companion, EV charging, or dealer app for iOS and Android starts at $5,000 as a basic MVP, and that price already covers its design, the backend, and the vehicle data integrations it needs. More roles and more data sources move it to an extended MVP, from $10,000. A web dashboard next to the phone app is a second platform and adds from 50% of the app price; an in-car version for Android Auto or CarPlay is estimated separately by its scope.

These are our starting prices and minimum timelines. Each one includes design, project management, testing, and the backend and integrations the product needs:

• Analysis phase, where we assess technical feasibility and write the scope with its budget: $1,000-$2,000, 1 week. It is optional, and a rough estimate is free.
• Companion, charging, or dealer app for iOS and Android as a basic MVP: from $5,000, at least 2 weeks, with a carmaker API, a telematics vendor feed, or a charging station system connected.
• Extended MVP with more roles and data sources: from $10,000, at least 5 weeks.
• Travel booking platform for a car rental company, with web and mobile apps and payments: from $30,000, at least 8 weeks: from $20,000 for the first platform and from $10,000 for the second. Keyless access through a telematics unit is part of the same estimate.
• Logistics platform for fleet or transportation management: from $20,000 for the web platform, at least 8 weeks. A driver app adds from $10,000.
• Marketplace, such as peer-to-peer car sharing: from $20,000 for one app that serves owners and renters, at least 8 weeks. A web version adds from $10,000.

After launch, technical support for the whole system, the phone app and its backend included, starts at $2,000 per month. If only the phone app needs care, choose app maintenance instead of it, from $1,000 per month: monitoring, bug fixes, and OS, SDK, and store updates. We estimate new features separately, as development work. Whether a provider's API update fits your plan depends on the change, so ask us to estimate it when the provider announces it.

Our prices do not include two costs: telematics hardware and the fees a carmaker, data platform, or device vendor charges for data access. The provider sets them, so get them in writing before you finalize the budget.

What to do next

1. List who uses the product, such as drivers, owners, fleet managers, or support, and what each must do.
2. Choose which of the four vehicle data sources the product needs, and ask each provider for its access terms in writing.
3. Decide whether you need an in-car app; if you do, check the Google categories and ask Apple about a CarPlay entitlement early.
4. Set a first budget: take the starting price of your product type above, such as $5,000 for a companion app, add from 50% of it for each extra client platform, such as a web dashboard, then add the providers' hardware and data fees.

First published 2024-06-07 by Evgeny Leonov, CTO at Ronas IT. Rewritten by Alexander Storozhevsky.

Planning an automotive app? Send us your brief, with the vehicle data sources and any in-car part if you know them, and get an estimate.

Get a project estimate