Rebuilding an IoT Car Tailpipe Sound App for iOS and Android
Cete Automotive GmbH, a German vehicle electronics manufacturer, builds custom hardware for premium cars that lets drivers adjust their vehicle’s exhaust sound through the app.
In 2017, they were looking for a Tech Partner with expertise in IoT to improve their application and chose MobiDev. The upgraded version quickly became popular among users, resulting in 50K+ downloads on Google Play alone.
The Story Behind an IoT Car Sound App
Cete Automotive GmbH was founded in 2012 and specializes in IoT solutions for adjusting car settings via their app. They built both custom hardware for the vehicle and the application. In 2017, the company engaged MobiDev to improve its Active Sound Gateway (ASG), the system that enables users to control and customize the engine sound.
Initially, the client’s request was to improve user experience. However, after an audit, we suggested rebuilding the application from scratch, as it had several constraints that otherwise wouldn’t allow us to optimize its performance and ensure scalability and adaptability.
Business Value of the IoT Car Sound App Rebuild
The business value of the updated ASG System includes:
- Over 50,000 Google Play downloads after the updated app launched on iOS and Android, among owners of Audi, BMW, Mercedes-Benz, Porsche, Range Rover, Volkswagen, and Tesla cars.
- Improved user experience due to the UX/UI redesign and improved performance.
- Meeting modern industry standards by adding new features to the application.
Never for a second did I have any doubt about the success of my project. I found their development team very competent and exceedingly motivated in the first place. In the end, everything was fulfilled according to my requirements, and I could proudly present the apps to my clients. I can truly recommend collaboration with MobiDev to anyone who needs a competent and responsive partner in app development. We have three more apps on the list, and we will certainly entrust MobiDev with them.
Alexander Savinykh
Executive Director and Owner at Cete Automotive GmbH
Project Scope of the IoT Car Sound App
MobiDev worked as a dedicated development team of 4-6 experts (depending on the project needs).
Stage 1. Design audit and redesign. Our design experts audited the existing ASG design to improve user experience and transparency. We used the findings to redesign the UX/UI in full.
Stage 2. Tech strategy. Because of existing product constraints, we wrote a strategy for a complete rebuild, choosing the stack for performance, scalability, and adaptability.
Stage 3. Native re-engineering. We rerebuilt the iOS app in Swift and the Android app in Kotlin, using the design assets from our initial collaboration. Native code was chosen for performance in firmware-related features like BLE communication and Over-the-air (OTA) updates, and we added new features to bring the app in line with
Deliverables of the IoT Sound App Rebuild
- Design audit of the original ASG app, with findings used for the redesign
- Redesigned UX/UI for ASG
- Tech strategy for the rebuild, including stack selection
- Native iOS app in Swift
- Native Android app in Kotlin and Java
- BLE communication between the app and the vehicle hardware
- Over-the-air firmware update flow
- Settings for additional speakers
- Downloadable car sounds
- Manual QA coverage for both apps
Tech Stack
Modernize Your IoT Application
Fill out the form and share your app modernization needs. Our experts will get back to you within 1 business day.
FAQ
Native (Swift and Kotlin) wins when the app does heavy device work: firmware transfers, background connections, tight timing. Cross-platform frameworks such as Flutter or React Native win when the interface is the main job and BLE use is light, since one codebase costs less to maintain. The trade-off is two codebases against less control over the device link. ASG went native because its firmware features needed the performance and stability using platform-specific features.
Refactor when the architecture can carry the features you need and the problems are local. Rebuild when the existing product’s constraints block the roadmap, which an audit and tech strategy should show before anyone commits a budget. Reusing design work across the rebuild keeps the cost down. For ASG, a design audit and tech strategy came first, then a rebuild of both apps using the existing design assets.
The app downloads the firmware package, checks it matches the device, sends it over Bluetooth in small pieces, and the device verifies it before switching over. The app has to handle dropped connections, low battery, and users closing the app mid-transfer without leaving the device stuck. Done right, users update hardware without a cable or a dealer. ASG gained over-the-air firmware updates in the rebuild.
Users judge a device by the app they control it with, so interface problems read as hardware problems. An audit shows which flows confuse users and what the redesign must fix, before code is written. It also produces design assets the rebuild can reuse. ASG’s audit led to a full UX/UI redesign that the native apps were then built on.
On real devices, across phone models, OS versions, and firmware versions, because Bluetooth behaves differently on each. Manual testing catches pairing and real-world issues, and automated tests cover regressions in app logic as the product grows. Firmware updates need their own test cases for interrupted transfers. ASG releases were tested manually on both platforms.
A small dedicated team usually covers it: a designer, iOS and Android engineers who know BLE, QA, and someone who owns the tech strategy and works with the firmware side. A team that stays on the product learns the hardware, which pays off with every later release.
Yes, and it tends to cost less over time, because device communication patterns, design work, and testing setups carry over between apps. The first app is the expensive one. After ASG, MobiDev upgraded Cete’s suspension control app and built its valve control app from scratch.
Yes, and what you need depends on the feature. AI built on existing models, such as voice control or natural-language commands, mainly needs a reliable command layer: every recognized intent has to reach the device and be confirmed, or users will blame the AI for a connection problem. AI that learns from the user, such as personalized settings or anomaly detection, also needs usage data: event and settings logging, user consent, and a backend to process it. This data can be collected offline and synced later, as long as transfers over BLE are complete and recover cleanly from dropped connections. ASG’s native rebuild delivered the reliable connection and firmware handling that both types of AI features depend on.
Often it does. If the code is hard to change safely, or device data cannot leave the phone in a usable form, AI work stalls on plumbing. An audit answers the question quickly: some apps can take new features on top, others need a rebuild first. For ASG, existing product constraints led to a full rebuild before new capabilities were added.
The realistic ones work with data the app already has: recommending presets or sounds based on what similar users pick, a support assistant that walks users through pairing and troubleshooting, and spotting device errors in logs before users report them, and voice control.
Enough consistent, labeled events to see a pattern: which settings users choose, when they change them, which firmware version the device runs, and what errors occur. A few weeks of clean logging from real users beats a large but messy dataset. Collection has to be designed in, with consent, because companion apps rarely log this by default. In ASG, the BLE link between phone and device is where that data would originate.
Yes. But it’s worth separating the two. Vibe coding, where AI generates code with little review, works well for prototypes and demos: you can test an idea or show a concept in days instead of weeks. Production IoT apps are different. Bluetooth edge cases, platform permission rules, and firmware update flows, where a failed transfer can leave a device unusable, are exactly where generated code tends to fail quietly. Good results come from engineers with domain knowledge working alongside an AI assistant: the AI speeds up screens, boilerplate, and first drafts of tests, while the expert decides what’s correct, reviews every line, and tests on real devices.