--- title: What are the technical challenges of automotive app development? description: Automotive app development is shaped by hardware limits, legacy APIs, offline design and security constraints that have no equivalent in mobile work. image: https://weareaffective.com/hubfs/learning-centre-images/what-are-the-technical-challenges-of-automotive-app-development.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-are-the-technical-challenges-of-automotive-app-development#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What are the technical challenges of automotive app development? Table of Contents Building an app for a car is not like building one for a phone. The phone sits in your pocket, runs a known operating system, connects to the internet through established protocols, and lives entirely in software. A vehicle is different. It is part mechanical system, part computer network, part legally regulated safety device, and the app has to work across all three of those realities at once. The constraints are real and they compound quickly. > Automotive app development means working across hardware, software, and regulation all at once, and the constraints compound quickly. By 2030, [TMA Solutions](https://www.tmasolutions.com/insights/automotive-application-development) estimates that nearly 95% of new vehicles will be connected, up from around 50% in 2020. That is a fast-moving shift, and the development challenges have not slowed down to match. Hardware contracts, legacy systems, third-party access restrictions, offline behaviour, security without an API layer, and cognitive load during high-stress moments: these are the work. What follows is an account of where those challenges actually live, drawn from projects we have worked on across connected hardware, safety-critical interfaces, and apps that have to function in places where the internet does not. ## Hardware and Software Contracts When an app connects to a physical device, someone has to define exactly how those two things talk to each other. That definition is the hardware-software contract, and getting it wrong early means expensive rewrites later. The temptation is to assume the hardware team and the software team will figure it out as they go. They will not. We worked on a baby monitor product where the client was building both the physical hardware, including cameras and sensors, and the companion app. The original assumption was that integration would use standard Bluetooth protocols. When we got into the detail, it turned out to be far more complex than that. We had to formally define a contract that specified exactly how the app would communicate with the device, covering turning things on and off, retrieving sensor data, and accessing camera feeds, all in a format the app could consume. The contract had to cover three things clearly. - What commands the app would send to the hardware, and in what format - What data the hardware would return, and when - What happens when the connection drops or a command fails Without that document, both teams default to their own assumptions, and those assumptions diverge. The app team builds for one data structure, the hardware team implements another, and the mismatch only surfaces during integration, which is the worst possible moment to discover it. Define the hardware-software contract before either team writes a line of code. It is a communication document as much as a technical one, and it saves more time than it takes to produce. ## Legacy API Constraints A clean API is not something you can take for granted. Many existing products were built without one, or with one that was never intended to support a mobile client. When a new app needs to connect to an existing system, the state of that system's backend determines what is actually possible, regardless of what was planned. We ran into this directly on a buying and selling platform for bottles of alcohol, a product similar in structure to wine trading. We had already started building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by another developer in a way that made it too complex to expose cleanly via an API. We ended up having to embed web elements from the existing site directly into the mobile product instead. That decision had a direct cost. Embedding web elements rather than building against a proper API added approximately 20% uplift in work across the entire length of the project. Because the client wanted to keep the budget the same, we had to drop features towards the end to compensate. The final solution was not as scalable or robust as we would have liked, but it was the only realistic path given the state of the existing code. The lesson is not that legacy systems are always a problem. The lesson is that the state of the existing backend has to be assessed before scoping the mobile product, not after. Discovering constraints mid-build forces compromises that would not have been necessary with earlier visibility. ## The design layer your *developers* need We deliver complete UX/UI design and technical specifications your development team can build from immediately. No guesswork, no back and forth, no mid-project surprises. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Third-Party Platform Access When a product depends on integrating with external platforms, the assumption is that access will be granted once the project starts. That assumption fails more often than most briefs account for. Platforms are locked down for legal, security, and commercial reasons, and the level of access you expect is frequently not the level you receive. We experienced this on a production management product for the motion picture industry. The plan was to integrate directly with existing platforms used for storing production documents, and to ingest data via email integrations. When we finally gained access to those systems, we found they were far more locked down than anticipated. The access we needed simply was not available. > Discovering that a third-party platform is locked down mid-build forces compromises that reshape the entire product. We had to pivot to an alternative approach, ingesting emails tied to specific roles within a production to process data indirectly, without a direct API integration into the third-party platforms. It worked, but it was a [significantly different architecture from the one scoped](https://weareaffective.com/app-architecture-design-we-are-affective) at the start. The practical response to this is to build access validation into the earliest stage of a project. Before the design process runs ahead of itself, someone needs to confirm what each external system will actually expose, in writing, with a test environment to verify it. Plans built on assumed access are plans built on assumptions. Treat third-party platform access as a risk item to resolve in week one, not something to confirm when development begins. Assumed access and confirmed access are different things. ## Security Without an API Layer A traditional API layer does a lot of security work that goes unnoticed until it is absent. It acts as a controlled intermediary between the client and the database, validating requests, filtering inputs, and preventing direct exposure of data structures. When you build without one, all of that work falls back onto the app itself and the database rules. On a performance coaching survey app, we made a deliberate early decision to skip a traditional API for the MVP. It was the right call for speed and budget at that stage, but it meant that locking down Firebase security rules became the biggest technical challenge on the project. With no API acting as a gatekeeper, we had to scrutinise [every security rule very carefully](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) to ensure that neither the app nor the web response page could be exploited. The exposure surface is wider without an API. Every rule that would normally be enforced server-side has to be replicated in the database configuration, and any gap is a direct vulnerability. We had to think through every possible query path and ensure that users could only read and write exactly what they were supposed to, nothing more. Cyber-attack incidents affecting connected vehicles have risen fivefold over four years, according to [TMA Solutions](https://www.tmasolutions.com/insights/automotive-application-development), which puts the security question in sharper relief for automotive applications specifically. When the product controls physical systems, the cost of a security gap is not just data exposure. Skipping the API layer is a legitimate architectural decision in the right circumstances. It needs to be made with a clear understanding of what security work it transfers to other parts of the system. ## Multi-Device Design Logic Designing for a second screen is not the same as adapting a design for a smaller one. Each device type has its own [interaction model, its own constraints](https://weareaffective.com/learning-centre/can-cross-platform-apps-access-all-phone-features-like-native-apps), and its own context of use. Treating a watch interface as a compressed version of a phone interface produces something that works on neither. We worked on a water tracking app that was originally phone-only, then added an Apple Watch component. The native phone app was tactile and engaging, built to take advantage of a large screen. The Apple Watch offered very limited real estate and a completely different interaction pattern. We had to rethink the navigation and the interaction model from the ground up, not shrink the existing one. We were not able to achieve the same fluidity as the phone experience, and that was the right outcome. Trying to replicate it would have produced a worse watch app and would have misread what a watch is for. The meaningful features we incorporated worked because they were designed for how someone actually uses a watch, [glancing at a wrist for a moment](https://weareaffective.com/learning-centre/10-micro-interactions-that-will-transform-your-apps-user-experience), not reading a screen. In an automotive context, this logic applies with greater force. The in-car screen, a companion phone app, and a cluster display are three different devices with three different interaction contexts and three different safety implications. A navigation pattern that works on a phone requires physical manipulation that is genuinely dangerous on a dashboard display. Design for each device's context of use, not its screen size. The question to ask is what a user needs from this device in this moment, not how to fit the existing design into a smaller space. ## Offline Architecture Connectivity cannot be assumed. A product that only works with a reliable internet connection is a product that fails at the exact moment its user is somewhere interesting, remote, or difficult. For automotive apps in particular, coverage gaps are regular use conditions on long routes, in tunnels, in underground car parks, and in rural areas. We built a travel product aimed at younger backpackers visiting off-grid locations, and unreliable connectivity was a core design constraint from the start. We [rethought the architecture around four principles](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). 1. Deciding what information could be stored offline and what had to remain online 2. How to queue offline actions and replay them once the user reconnected 3. Minimising the data sent between the app and the server to use limited bandwidth efficiently 4. Baking content directly into the product wherever it did not need to be dynamic The result was a product that could function offline where feasible and made sensible use of limited or intermittent connectivity when it was available. Enterprise developers have reached a similar conclusion independently: according to a [LinkedIn Pulse survey](https://www.linkedin.com/pulse/survey-results-developers-weigh-ideal-rapid-mobile-groden-morrison#:~:text=Of%20primary%20importance%20by%20a,%20of%20all%20developers%20surveyed), 78% consider offline functionality very important when choosing a mobile development platform. Offline architecture has to be decided at the start. Retrofitting it once the app is built means restructuring how data flows through the entire product, which is substantially more expensive than designing for it from the beginning. ## Cognitive Load Under Stress The context in which an automotive app gets used is often not a calm one. Users are navigating in unfamiliar places, dealing with traffic, managing time pressure, or in the worst cases, recovering from an accident. An interface that works perfectly in a quiet room can fail completely when the user's attention and emotional state are under pressure. We worked on a fleet vehicle app for BMW where the interface asked accident victims to record damage and fill in forms. Users were not completing the tasks properly. The interface simply said 'upload your photos' without guidance, expecting users to know which angles to capture and to work through detailed forms while in a highly stressful post-accident state. The cognitive demand was too high for the situation. The redesign used the device's accelerometer to detect a sudden stop after movement, then [proactively asked 'Have you been in an accident?'](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) rather than waiting for the user to navigate to a reporting function. From there, the process used voice memos for witness statements and visual diagrams showing exactly which photo angles to take, removing the need for memory or judgement in a moment of trauma. The principle here goes beyond accident reporting. Any automotive app that asks users to process information, make decisions, or complete multi-step tasks while driving or immediately after a stressful event is asking too much. The design has to do the cognitive work that the user cannot. ## Applying a New Design Layer to Existing Code When a product has been built functionally but needs a new emotional or interaction layer, the instinct is to treat it as a design problem with a design solution. The technical reality is more complicated. The existing code has its own structure, its own constraints, and its own assumptions about what the interface will do. A new design layer has to work within those constraints or the implementation will diverge from the intent. We were brought in to work on a wellness genetics product to improve its emotional layer. The product was data-heavy, the brand was premium and wellness-focused, and the existing build did not reflect any of that. When we handed our designs to the development team, a third-party designer sitting between us and the developers created something that looked very luxurious. The development team then struggled to understand how to implement it on top of their existing codebase. There was considerable back and forth to reach something that actually worked. The gap between what a design looks like and what an existing codebase can support is real and it creates rework. The further the handoff chain, the wider that gap tends to get. An intermediary who is optimising for visual quality rather than technical feasibility will produce work that looks right and builds badly. The fix is early technical review of any new design layer against the existing system, before the design is finalised. Finding out that a specific interaction pattern cannot be implemented on the current code is useful information at the design stage. It is expensive information at the development stage. ## Scope Decisions That Create Technical Debt Scope decisions made early in a project for good reasons, speed, budget, focus, create constraints that arrive later with interest. Every choice to skip discovery on a component, defer a feature, or accept a temporary workaround is a loan against the future, and like any loan, it costs more than the original amount. We worked on a dating app where the client chose to skip discovery for the messaging component and focus only on the onboarding process. The reasoning was understandable: the verification and onboarding work was the core of the product, and messaging felt more standard. The problem was that messaging was not standard for this product. The app's entire premise depended on verified, authentic interactions. Skipping discovery on messaging meant [what was built allowed automated and fake messages](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one), directly contradicting everything the onboarding had established. The entire messaging section had to be rewritten, costing approximately £15,000 in additional budget and two months of extra work. Scope decisions on the sports club app we worked on created a different kind of pressure. Two [co-founders, both deeply embedded in the world](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi) the app was built for, consistently pushed to add more features throughout the project. Each addition felt obvious to them because they lived in the environment the app served. Holding scope against that pressure was genuinely difficult, and the risk of launching nothing was real. Projects that try to ship everything at once, rather than iterating from a smaller foundation, are the ones most likely to never ship at all. | Scope decision | Short-term gain | Long-term cost | | --- | --- | --- | | Skip discovery on a component | Faster start | Rewrite when the component contradicts the product | | No API layer for MVP | Lower initial build cost | Manual security work, limited scalability | | Embed web elements instead of API | Unblocked delivery | 20% uplift in work, dropped features | | Add features without iterating | Broader launch scope | Risk of not launching at all | ## Conclusion Automotive app development concentrates technical challenges that exist across software development generally, then adds the physical, safety-critical, and connectivity-constrained realities of a vehicle. Hardware contracts, legacy backends, locked-down platforms, security without API protection, multi-device logic, offline architecture, stress-state interfaces, design layers over existing code, and scope decisions that accumulate debt: each of these is manageable. Together, they require a methodical approach that starts with the constraints rather than the features. The projects described here share a pattern. Where the constraint was identified early, a workable solution existed. Where it surfaced mid-build, the cost was always higher than it needed to be. The baby monitor contract document saved an integration crisis. The travel product's offline architecture was designed in from the start. The BMW accident app redesign removed cognitive load by working with accelerometer data rather than asking users to navigate while distressed. None of those outcomes happened by accident. Good automotive app development means knowing where the hard problems live before the build starts, and structuring the early work around surfacing them. If you are working through any of these challenges on a connected vehicle or companion app project, [let's talk about your automotive app](https://weareaffective.com/get-started). ## Frequently Asked Questions Why is building an app for a car more complex than building one for a smartphone? A car is simultaneously a mechanical system, a computer network, and a legally regulated safety device, so an app must work across all three realities at once. A smartphone, by contrast, runs a known operating system and lives entirely in software, which makes the development environment far more predictable. What is a hardware-software contract and why does it matter? A hardware-software contract is a formal document that defines exactly how an app and a physical device communicate, covering what commands are sent, what data is returned, and what happens when the connection fails. Without it, the app team and hardware team will make separate assumptions that only clash during integration, which is the most costly moment to discover a mismatch. When should a hardware-software contract be written? It should be defined before either team writes a single line of code. It functions as a communication document as much as a technical one, and producing it early saves significantly more time than it takes to create. What happens when an existing backend was not built to support a mobile app? The state of the existing system determines what is actually possible, regardless of what was originally planned. In some cases, a clean API layer cannot be built on top of a legacy system, forcing developers to find workarounds such as embedding web elements directly into the mobile product. How widespread will connected vehicles be by 2030? TMA Solutions estimates that nearly 95% of new vehicles will be connected by 2030, up from around 50% in 2020. This is a rapid shift, and the technical development challenges have not slowed down to keep pace with it. What are some of the key technical challenges specific to automotive app development? The main challenges include managing hardware-software contracts, working around legacy system constraints, handling offline behaviour, implementing security without a clean API layer, and designing interfaces that do not overload drivers during high-stress moments. These constraints are real and they compound quickly when combined. Why is offline behaviour a particular concern for automotive apps? Vehicles frequently travel through areas where internet connectivity is unreliable or entirely absent, so an app cannot assume a constant connection the way a typical mobile app might. Developers must plan carefully for how the app behaves when the network drops, ensuring it remains functional and safe to use. What makes cognitive load a unique challenge in automotive app design? Drivers interact with apps during high-stress moments, often while managing speed, traffic, and navigation at the same time. An interface that is perfectly usable in a calm environment can become dangerous in a vehicle if it demands too much attention, so automotive app design must account for this in a way that standard app development does not. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.