Put your own systems on the radio, without building an app
Every operation has something the radio ought to talk to — a job board, a defect log, a gate register. A mini app puts one on the handset as a screen your crew can actually use. You describe the screen you want; we draw it.
You describe the screen. We build it.
You list what should be on the screen — some words, a table, a few boxes to fill in, a button — and the handset draws it like any other part of the app. Nothing anyone else writes ever runs on your crew’s phones.
- Opens instantly, even on the cheapest rugged handset, because it is a real screen and not a web page in disguise
- There is no way for it to reach the microphone, the camera or anything else on the phone
- An administrator sees the complete list of what an app can do before enabling it — complete because there is no escape hatch to leave off the list
What a mini app can do
Enough for the things a radio actually needs: log something, dispatch something, check a status, start a transmission.
- Send what somebody typed to your own system. It goes through us, so it is logged and cannot be hammered, and the handset never talks to your servers directly
- Start a transmission into a named channel, waiting its turn and locked away exactly as a person’s would be
- Post a message, optionally with an alert tone, under the name of the person who pressed the button
- Open a conversation the app already has
And what it deliberately cannot
The limits are the product. An integration can drive the radio; it cannot listen to it.
- It cannot read message or voice content. No widget binds to it and no action returns it
- It cannot reach an arbitrary host — endpoints are registered up front and resolved on our side, so the handset never talks to a stranger and its address never leaks
- It cannot transmit in a way a person could not, because it uses the same floor and the same keys
Some of ours are built the same way
Mail, World Phone and the aviation and maritime screens are mini apps in every way that matters to an administrator: turned on per organisation, carrying permissions you approve, appearing in the same list, hidden by the same switch.
- Only the drawing differs — a few of ours are native screens because a spec cannot express an inbox or a map, and we would rather admit that than grow the format into a small programming language
- Hidden means the handset is never sent the app at all, not just told to leave the icon out
- Which means the machinery is exercised daily by us, not just by a test suite
Why this is a security feature, not a limitation
The promise this product makes is that our servers carry conversations they cannot read, and the handset is the only place they exist in the open. Letting somebody else’s code run right next to them would be the biggest hole in the whole product, and no permission pop-up really closes it.
- Every data flow is declared, so what an app can see is a list an administrator can read rather than a promise
- The cost is honest: integrators build from a fixed widget set instead of shipping arbitrary interfaces
- For logging an incident, dispatching a job or checking a status, that has been enough — and it is why we can tell you what an app cannot do and mean it
What would you put on the handset?
Tell us the system and the screen you picture, and we will tell you whether the format covers it today — and build the first one with you if it does.