Modernizing an IoT Suspension Control App: Native Rebuild on BLE

BLE suits short-range control from a phone. It draws little energy. WiFi suits devices that move a lot of data, need longer range, or have to reach the cloud without a phone in the loop. Some products use both: BLE for setup and control, WiFi for bulk data. The ASC app originally reached its hardware over WiFi alone, and moving it to BLE brought its energy consumption down.

Native code talks to each platform’s Bluetooth APIs directly (Core Bluetooth on iOS, the Android BLE stack), which makes connection handling, background behavior and OS-specific quirks easier to control. Flutter and React Native can work when the Bluetooth logic is simple and the app is mostly screens, but a BLE plugin adds a layer you have to debug through when a connection drops. Cross-platform wins when one shared codebase matters more than fine control and the hardware protocol rarely changes. ASC was built natively, in Swift for iOS and Java and Kotlin for Android.

Start with an audit, because the answer depends on where the problems sit. If they are in screens and features, refactoring usually costs less. If they are in the core, such as how the app connects to the device, patching tends to move the problem around, and a rebuild can cost less over the life of the product. For ASC, the code review and the client’s requirements fed into the plan, and both apps were rebuilt natively.

Emulators and mocked devices cover app logic. Bluetooth timing, signal loss, reconnection and device power states only show up with the real device. A test plan for a hardware-controlled app should include the device itself, the phones and OS versions customers actually use, and the conditions the device works in. Automation helps with app-side regression. ASC was tested manually with the client’s hardware mounted in a car.

Code quality and architecture, how the app talks to the device, current Apple and Google platform requirements, and a gap check against what the business needs the app to do next. The output should be a plan: what to fix, what to rebuild, in what order, and on which platform first. For ASC, our engineers checked the code against the client’s requirements and produced a plan ranking platforms and features.

One at a time lowers risk. The team proves the device connection and the new architecture on one platform, ships, then carries what it learned to the second. Working in parallel makes sense when both platforms have large user bases that can’t wait and the budget covers two teams. Usage data and release pressure should drive the choice. On ASC, iOS went first and the Android app followed after the iOS launch.

Users need to read the state at a glance: whether the device is connected, which setting is active, and whether the last command applied. An audit checks that first, then the main flows and how errors are explained, and ends with concrete proposals. For ASC, our designer assessed the existing app and proposed improvements before moving on to new features.

Yes, and it can shorten ramp-up on each new app. The team already knows the connection patterns, the release process with both app stores, and the client’s hardware. Each device still has its own protocol and behavior, so the second app isn’t a copy of the first. After ASC, MobiDev upgraded Cete Automotive’s Active Sound Gateway app and built a new Active Valve Control app.

At minimum: mobile engineers for each platform, QA with access to the hardware, and a designer if the interface is changing. Someone on the vendor side has to own the device protocol and work directly with the client’s hardware or firmware people. A tech lead usually runs the audit at the start. For example, ASC is handled by a small dedicated team, with a designer who ran the UX/UI audit.

Yes. What has to be in place first depends on the feature. AI built on existing models predominantly needs a reliable command layer. The recognised 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, yes, if the code can’t be changed safely or the device connection drops often enough to corrupt the data. If the app is stable and maintainable, AI features can go on top, usually through a backend service rather than inside the app. An audit tells you which case you’re in, the same way the ASC audit set the order of the modernization.

Realistic: spotting unusual sensor readings, suggesting settings from a driver’s own history, and a support assistant that answers from the product’s manuals. Promised more often than delivered: the car adjusting itself to road conditions with no driver input, which raises safety, liability and certification questions, and “AI” that turns out to be a few fixed rules. Anything that changes vehicle behavior without the driver’s action needs far more validation than a recommendation. ASC is EU-certified, so a feature that changes what the app does to the hardware would need checking against that certification.

Yes. But it’s worth discerning the two. In vibe coding, AI generates code; however, there’s no in-depth review by a human. It works best for creating prototypes and demos, when you need to test an idea or show a concept in days instead of weeks.

However, development of IoT apps is different. The AI-generated code fails when it comes to Bluetooth edge cases, platform permission rules, and firmware update flows (e.g., a failed transfer can cause malfunction of the device).

If you want to build an IoT application that performs consistently and smoothly, you need to engage developers with domain knowledge to control the AI code generation process. Have AI to speeds up screens, boilerplate, and first drafts of tests. Leave the decisions on what’s correct, code revision, and tests on real devices to human experts.