Cross Platform App Development for Connected Devices, Delivered With the Backend

• Companies whose product includes a device and needs a companion app - sensors, cameras, controllers, instruments. The app is the device's remote control and its display.

• Clients who do not want generic app outsourcing. The hard parts of a device app are provisioning, reconnection after a dropped link and push delivery, not applying a UI template.

• Teams caught between an app vendor and a device vendor. The app side says the device sent nothing, the device side says the app never connected, and nobody can inspect the whole chain.

• Clients who need iOS and Android together, with matching features and release cadence. Cross platform development is the natural fit.

XTELL does not sell mobile app development as a front end on its own. The app and the server behind it are designed, built and integrated by one team. The Flutter app and NestJS backend of the 433MHz security linkage system were delivered this way: every app feature has a matching API and message path on the backend, and pairing, device state and alarms are defined as a whole at the design stage. The reason is practical. Most device-app problems sit on the boundaries between the app, the backend and the device, and when front end and back end belong to different vendors, a boundary problem is an orphan nobody can fix alone.

For most cross platform app development companies the phrase means one thing: one codebase across iOS and Android. At XTELL it means a second thing too - the device your app talks to runs firmware written by the same team. Cross platform on the software side, and across the hardware boundary as well. A mobile app development company can build the screens; how they behave depends on the device.

The mobile side of the 433MHz security linkage system is a Flutter app for iOS and Android. go_router handles routing, provider handles state and dio handles networking. QR code provisioning binds the device, WiFi scanning guides it onto the network, video plays RTSP and HLS streams through VLC, and alarms are pushed in real time. The project structure and plugin choices are organised around identical behaviour on both platforms, so the same business logic behaves the same on iOS and Android and needs one test standard, not two.

The ultrasound touch control system uses Android for touch interaction on a medical device. It talks to the equipment over the M8 Touch communication protocol, a systematic set of UI mockups and slice assets keeps the interface consistent, and TouchControl handles touch input. The challenge was a stable, responsive ultrasound imaging interface with reliable touch on medical hardware. This is native Android work: medical use sets a higher bar for interface stability and response determinism than a typical consumer app.

The Apollo2 low-power display terminal is the other end of the link. The device uses an Apollo2 MCU as main controller, sleeps in low-power standby, uses an optimised SMX layout for its display, and supports different feature sets through multi-version BSPs built across Keil, IAR and GCC. What the terminal shows locally and what the phone app shows were divided at the design stage - including how each behaves when the network drops - and decided by the same team. In a connected product, the app is never an island.

XTELL defaults to Flutter for cross platform work: one codebase for iOS and Android, shared business logic and consistent behaviour on both, which is how the 433MHz system app was delivered. The limits are clear too. Interfaces that depend heavily on platform capabilities, or need very high response determinism, are better native - the ultrasound touch system uses native Android for exactly that reason. The choice is made on feature requirements and maintenance cost rather than preference, and the reasoning is written down at the design stage.

Provisioning decides whether users keep a device. If a customer cannot get it online within ten minutes of unboxing, nothing else matters. The 433MHz system app binds devices by scanning a QR code and guides network setup with WiFi scanning, removing the error-prone step of typing an SSID and password by hand. The design rule for provisioning: every failed step must give clear feedback and a way forward. The app should tell the user whether a failure is on the device or the network, and the logs should pinpoint it.

Video in a camera product's app is not a matter of calling a player. The 433MHz system app plays RTSP and HLS streams through VLC, with ZLMediaKit relaying the streams on the backend. The real problems are start-up latency, whether to resume a stream after returning from background, how to drop resolution on a weak network, and whether the video or the push notification arrives first at the moment of an alarm. Video experience is the core metric of a security product, and because every link from camera through server to app is ours, problems do not have to be traced across vendors.

The value of a device alarm equals the probability that it reaches the user. In the 433MHz system, the device reports to the backend over MQTT through an EMQX broker, and the backend triggers the app push once it has confirmed the device state. The backend guarantees the ordering between push and device state, avoiding the mismatch where the notification arrives before the state has updated. Delivery rate is threatened mainly by system power-saving policies and permission settings, so the in-app guidance flow and the backend retry strategy are designed together - another way a connected-device app differs from an ordinary one.

XTELL does. Firmware, app and backend sit with one team, so when the app cannot reach a device we open the firmware and check what the device actually advertised and whether the backend received its registration. A symptom like "the device didn't report" gets narrowed to a specific message and timestamp. On device-app projects, integration often takes longer than development itself, and whether integration can cross layers directly sets the delivery pace.

The foundational choices in a Flutter project set its long-term maintenance cost. The 433MHz system app uses go_router for routing and deep links, provider for state and dio for requests and interceptors. The rule is mainstream, stable and replaceable - no maintenance risk taken on for a niche library's newest feature. The codebase is organised by business domain, so a new engineer can read the feature breakdown from the directory structure.

1. Requirements review: share the device type, communication method and app feature list, and we confirm whether the route is cross platform or native.

2. Proposal and contract: screen flows, interface definitions and milestones are written down. Whether app and backend source code is delivered, and under an open or closed model, is agreed item by item in the contract. Nothing on this page constitutes a blanket commitment.

3. Development and integration: app, backend and device side progress in parallel, and provisioning, video and push are verified end to end.

4. Delivery: scope follows the contract. Timeline and price are given after assessment; this page does not fix numbers.

XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the ten years since, it has delivered more than 100 projects, with clients predominantly western B2B companies. Its work covers every layer from circuit board to cloud: PCB design, FPGA, embedded firmware, Linux BSP, device interfaces, mobile apps, backends and IoT platforms.