Why the Car Became the Hardest Place to Ship an App

Why the Car Became the Hardest Place to Ship an App

A phone app can be built quickly and distributed to millions of devices almost overnight. The same app, running on the screen in a car, has to answer a question no phone ever asks: is the vehicle moving, and if it is, should this exist at all? That question turned the dashboard into one of the most constrained software environments in consumer technology, and it arrived just as the automobile itself became a software product. The software-defined vehicle market is projected to grow from $447.55 billion in 2026 to $1,707.36 billion by 2035, a 16% compound annual rate. Automakers are betting the next decade of their business on what runs inside the cabin. For years, only a small set of tightly controlled applications did.

Neha Heera spent that period on the other side of the problem. Now a Senior Engineering Manager at Toast, where she leads the mobile platform behind restaurant operations, she previously led core user-experience work for Android Automotive OS at Google, after earlier engineering roles at Amazon, Etsy, and Yelp across 18 years. She is also the co-author of Advanced LLM Engineering for Non-Latin Languages, a technical guide to building language systems that work outside an English-first frame. At Google she led the Car-Ready Apps program, the effort to take the ordinary Android app catalog, written for phones by developers who had never thought about a moving vehicle, and make it work inside one.

The Screen That Cannot Be Trusted

The constraint is not arbitrary. In 2024, 3,208 people were killed in crashes involving a distracted driver in the United States, and an estimated 315,167 more were injured. 13% of all injury crashes were distraction-affected. Every one of those numbers is a reason a car does not behave like a tablet. Android Automotive OS enforces driving-state restrictions at the platform level, which means that when the vehicle is in motion, whole categories of interaction are simply not permitted to render. The screen is not a canvas. It is a regulated surface.

That regulation is precisely what made the app problem hard. A developer who built a video app or a game for phones never wrote code that asks the operating system whether it is safe to display. Their app assumed a user with free hands and full attention. Porting that assumption into a car does not work, and asking millions of Android developers to rewrite their applications for automotive was never realistic. The gap between the phone app ecosystem and the vehicle was not a matter of taste. It was structural, and it sat inside the platform.

“You cannot ask the entire Android developer community to learn automotive,” Neha Heera says. “The platform has to absorb that complexity, or the apps never arrive.”

Bridging Two Versions of the Same Operating System

The scale of what was waiting on the other side of that gap was substantial. By May 2025, Google said cars with Google built-in were live in more than 50 vehicle models, and the company had worked with over a dozen car brands, spanning Polestar, Volvo, Renault, Honda, Acura, Nissan, Ford, Buick, Mitsubishi, and Mazda. The vehicles were already on the road. What they lacked was a broad application ecosystem. In-car catalogs had been limited to a narrow set of native automotive apps, mostly navigation, media, and charging, while the Play Store next door held millions of Android applications that could not run.

Heera led the team responsible for the Android Automotive framework work that closed the distance. The technical strategy was to bridge the gap between Android Automotive OS and core Android at the platform layer, without requiring developers to redesign their applications specifically for automotive. That meant handling driving-state restrictions, input model differences, and UX consistency inside the framework rather than pushing them onto app teams. She drove the work across Android platform groups, partner teams, OEMs, product, and UX, coordinating requirements that frequently disagreed. Different automakers had different requirements, and the platform had to satisfy all of them without fragmenting.

“Every OEM had its own view of what belonged on the screen,” Heera explains. “Our job was to build one foundation that could hold all of those opinions without shattering into a dozen incompatible platforms.”

The Car Is Parked More Than It Moves

The insight that unlocked the program was temporal. A vehicle is not in a single state. It drives, and then it stops, and while it is stopped the safety calculus inverts completely. Charging an electric vehicle, waiting in a school pickup line, sitting through a delivery window: in all of these the driver is a passenger in their own car, with the same free attention that any phone app assumes. Recognizing that vehicles operate in different states has also influenced broader investment in software-defined vehicle technologies. The advanced driver assistance market alone is projected to grow from $38.1 billion in 2023 to $150.2 billion by 2032, at more than 17% annually, and much of that spend is aimed at systems that understand what state the vehicle and its occupant are actually in.

Car-Ready Apps was built on the parked state. Starting in February 2025, eligible video, game, and browser apps began distributing through Google Play to cars running Android Automotive OS with Google built-in, expanding the ecosystem beyond traditional automotive applications to include supported video, browser, and gaming experiences when the vehicle was parked. Heera’s interest in how people actually behave around ambient computing extends past the platform. She is a peer reviewer for the UbiComp/ISWC 2026 workshop program, the leading venue for ubiquitous and wearable computing research, where the questions are less about what a device can display and more about what a person will absorb in a given context.

“A parked car is a room,” Heera notes. “Once you accept that, a whole class of experiences becomes obvious, and the engineering question stops being whether to allow them and starts being how to detect the moment they are safe.”

The Interface Is the Safety System

Automotive interaction is where safety engineering and interface design stop being separate disciplines. Over-the-air updates in most vehicles today remain restricted to non-critical systems, affecting less than 30% of a vehicle’s functional domains, and semi-software-defined architectures hold roughly 60% of the market in 2026. The industry is moving carefully, and the caution is warranted: in a car, an interface decision is a safety decision. A menu that takes 3 taps instead of 1 has a measurable cost that no phone app ever has to account for.

This is why Heera treats interaction research as core to platform work rather than adjacent to it. She reviews papers for ICMI 2026, the ACM International Conference on Multimodal Interaction, the field’s primary forum for research on how systems combine voice, gesture, gaze, and touch. The car is the most demanding multimodal environment in consumer computing. It has to accept input from a person whose eyes belong somewhere else, and it has to know when that person is free to look. The work she led on Android Automotive depended on the platform making those judgments correctly, at the framework level, for apps that had no idea they were in a vehicle.

“On a phone, a bad interface wastes someone’s time,” Heera observes. “In a car, a bad interface takes their eyes off the road. Those are not the same category of mistake, and you cannot design for the second one by borrowing habits from the first.”

The Vehicle Becomes a Platform

The commercial logic is now unmistakable. Revenue from software-defined vehicle features is forecast to grow at a 30% to 34% compound annual rate through 2035, and central compute platforms are projected to generate roughly $755 billion in hardware revenue by 2029. Automakers that once sold a car once are building recurring relationships through the screen. That model only functions if there is something worth returning to, which puts the app ecosystem at the center of the business case rather than at its periphery.

What the Car-Ready Apps work established is that the ecosystem does not arrive by persuading developers. It arrives when the platform does the hard part on their behalf. The same pattern is now repeating in the systems Heera builds at Toast, where mobile software has to make real-time operational decisions inside restaurants that cannot pause to accommodate it. The environments differ. The engineering discipline is identical: absorb the complexity of the context into the platform, and let the application stay simple.

“Platforms win when they make the hard thing invisible,” Heera reflects. “Nobody who streams a show in a parked car thinks about driving-state restrictions or framework bridges. They think the app just works. Getting to that sentence took years, and that sentence is the entire product.”