App Design
The app is the part of your device people think they are using — and almost all of the difficulty sits in the layer where it meets the hardware.
![](data:image/svg+xml,<svg display="block" id="4238997430" role="presentation" viewBox="0 0 973 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 49.383 0 923.497 0 970.991 0 C 972.097 0 973 0.903 973 2.009 C 973 2.009 973 2.01 973 2.01 C 973 3.109 972.109 4 971.01 4 C 923.73 4 49.389 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="hRZSFU08U" width="973px"/></svg>)
Most companion apps are built by people who have never seen the firmware. That holds up until the connection drops halfway through a reading, or the device goes to sleep while the phone is in a pocket, or someone walks out of range with a session half‑finished. The screens were never the hard part.
The hard part is underneath: deciding what to show when the app has not heard from the device for ten seconds, whether a partial reading is worth displaying at all, and what to tell a user when something has gone wrong at the other end of a radio link. Answering any of that means knowing what the firmware is actually doing.
We write the firmware, so we do.
Developing an app to be useable by everyone
OnaWave came to us needing to move quickly from a concept to something that worked. Endometriosis takes an average of seven to ten years to diagnose, and EndoSolve exists to shorten that, which meant the fastest route to real data mattered more than a polished first version.
We worked across the whole system: the electronics, the firmware, the mechanical design and the companion app, along with the prototype units that went out into their field studies. Because one team held all four, the app was built against firmware we had written rather than against a document describing it, and both moved together as the device changed.
"IMME Design supported us from early proof of concept through to full product development, including electronics, firmware, mechanical design, app development, and the prototypes used in our field studies. Their ability to deliver across these disciplines as a single, integrated team made a significant difference."
John Hegarty, COO, OnaWave Medical
The data question that gets asked too late
A companion app for a health device handles some of the most sensitive information a person has. Under GDPR, health data is special category data, and those obligations do not wait politely for a device to be formally classified.
The questions worth settling early are unglamorous and cheap to answer at the start. What is actually stored on the phone, and what is sent onward. Who can read it. How long it is kept. Whether the app needs to hold identifiable data at all, frequently it does not, and a design that never collects a name is far easier to defend than one that collects it carefully. The expensive version is discovering during a funding round or a hospital procurement review that nobody wrote any of it down.
We raise these at architecture stage, because the answers change the firmware and the backend as much as they change the app.
What we do
![](data:image/svg+xml,<svg display="block" id="2331059170" role="presentation" viewBox="0 0 262 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 24.892 0 237.077 0 259.996 0 C 261.101 0 262 0.899 262 2.004 C 262 2.005 262 2.005 262 2.005 C 262 3.107 261.107 4 260.005 4 C 237.136 4 24.895 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="hcyQGd7cR" width="262px"/></svg>)
Bluetooth pairing that a patient or a nurse completes without instructions, and reconnection that handles the ordinary realities — the device asleep, the phone in a pocket, the user briefly out of range. iOS and Android behave differently here, and both are tested.
Deciding what to show when the device goes quiet
Every connected product spends some of its life not connected. We decide in advance what a partial reading is worth, when data becomes too old to display, and what the user is told when something has failed at the far end — rather than leaving a screen showing a number that stopped being true four minutes ago.
Interfaces for the person actually holding the phone
A patient using a therapy device at home is not at a desk and may be in discomfort. A clinician has thirty seconds and possibly gloves. We design for the moment the app is opened and the thing the person needs then, rather than building a dashboard that suits an engineer.
Updating firmware over the air
Delivering firmware updates through the app, with versioning, verification and a way back if an update fails. Getting this right is what lets you fix something after the product has shipped; getting it wrong turns a device in someone's home into a brick.
Where a companion app becomes a regulated device
An app that displays a reading is one thing. An app that interprets it, recommends an action or drives therapy may be Software as a Medical Device, with the documentation burden that implies. We will tell you early which side of that line a feature sits on, because it is far cheaper to know before it is built.
Built with the firmware, not against a document describing it
The protocol between device and app is designed once, by the people writing both ends of it. When something needs to change, both sides change together in the same week — instead of becoming a negotiation between two suppliers with different release cycles.
Talk to whom you will be working with
![](data:image/svg+xml,<svg display="block" id="3466557371" role="presentation" viewBox="0 0 730 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 42.569 0 687.328 0 727.991 0 C 729.097 0 730 0.903 730 2.009 C 730 2.009 730 2.01 730 2.01 C 730 3.109 729.109 4 728.01 4 C 687.529 4 42.575 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="j7DaIfjlS" width="730px"/></svg>)
Garrett Brennan
Software Engineer
Garrett is a Vancouver based software engineer who has been writing embedded software since 1990, and who builds the apps that talk to it — iOS and Android, alongside C, PLC and structured text, and SQL. On a connected product that means the person deciding what the firmware sends is the same person deciding what the app does with it, so the protocol between them gets designed once rather than negotiated between two suppliers.
Frequently Asked Question
Do you design apps on their own, or only alongside hardware?
We do both, but our strength is designing apps that connect closely with hardware. That includes companion apps, control interfaces, and data visualisation for connected devices. We make sure the app and the product feel like one coherent system.
