Almost every new connected product ships with a companion app, and the first question is which technology to build it in. Flutter is a popular answer because one codebase runs on both iOS and Android with an identical look, which cuts app cost and calendar time substantially for a first product. The honest summary: Flutter is an excellent fit for setup, monitoring, and data display, and a poor fit when the app must do continuous background sensor work or heavy real-time media processing. This article explains where the line falls and how to decide.
What Flutter gives a hardware project
The main advantage is economic. Instead of two teams, two codebases, and two schedules, there is one. For a founder building a first product, that is a material difference in budget, time to market, and ongoing maintenance cost. The practical benefits:
- Its own rendering engine. The interface looks the same on every device, which simplifies design and drastically reduces visual QA across screen sizes.
- Hot reload. Code changes appear on the handset within seconds — unusually valuable when you are sitting next to a physical prototype and iterating on how the app talks to it.
- Mature packages for wireless communication, charts, maps, and permissions that would otherwise cost weeks.
- One team that understands the whole product rather than knowledge split across two platform silos.
There is a less obvious benefit that matters most over time. When a connected product ships, every firmware fix or protocol change forces a matching app change. With a single codebase that change is made once and tested once instead of twice in two environments. Across a couple of years of maintenance that is usually the largest saving of all — the ongoing side of the cost is discussed in app maintenance cost after launch.
Where the limits start
The limits begin precisely where the app touches hardware. Bluetooth Low Energy behaves differently on each operating system: permission models, background behavior, reconnection after a dropout, and long scans all differ. Bridge packages handle the common paths well, but edge cases still require platform-specific code written by someone who knows that platform. Budget for it rather than being surprised by it — the same tension exists in the React Native ecosystem, compared in React Native with BLE.
- Background operation. Continuously collecting sensor data while the app is closed requires separate native implementation on each OS, and both platforms actively restrict it.
- OS feature lag. New platform capabilities reach the bridge layer some time after they ship natively.
- App size. The install package is larger than an equivalent native app.
- Heavy real-time media. Live video or audio processing is still better served by native code.
- Certified integrations. Anything that requires an Apple-specific accessory framework, such as MFi certification, still involves native work regardless of your UI framework.
None of these blocks a project, but all of them require planning. On our projects we allocate time up front for testing on a spread of real handsets, because a simulator does not reproduce radio behavior or the operating system's battery management.
When to choose Flutter, and when not to
Choose Flutter when the app's job is configuration, monitoring, and presentation: initial pairing, showing readings, sending commands, managing an account, pushing a firmware update. That describes the majority of consumer and industrial companion apps, and the cross-platform savings are real. The typical BLE workload and its cost are covered in BLE app development cost, and first-time onboarding in Wi-Fi provisioning from an app.
Lean native when the app is the product's core experience rather than its remote control: continuous background biometric capture, deep integration with platform health or home frameworks, real-time video, or an unusually demanding interface. The broader tradeoff is laid out in native vs cross-platform app development.
The architecture that ages well
Whichever way you go, isolate the hardware layer. Put all BLE and platform-specific behavior behind one interface, and keep the rest of the app — screens, state, data, cloud sync — ignorant of how the device is reached. Three practical reasons:
- Platform quirks are contained in one file you can hand to a specialist.
- You can swap or add a transport (BLE to Wi-Fi, or a cloud path) without touching the UI.
- You can build a fake device to develop against, which means app work does not stall every time the prototype hardware is on someone else's bench.
Also define the device-to-app protocol as a written document before either side is coded. Most companion-app schedule slips are not app bugs; they are two teams interpreting an undocumented packet format differently.
Store review realities
Cross-platform frameworks do not change store requirements. Both stores expect a clear explanation of every permission you request, a privacy policy, and justification for background activity. Apps that request Bluetooth or location access without an obvious user-facing reason get rejected regardless of framework — see publishing an app to the app stores.
Get the app and the device designed together
Projects House develops connected products for US clients end to end — firmware, protocol, and companion app designed as one system, in Flutter or native depending on what the product actually needs. Describe your product through the contact form, or read more in our app development guide.