Lock the handset down to the job it was issued for

Enrol company devices, replace the launcher, decide which apps exist at all, lock a handset to push.tt alone, push settings, and wipe one that walks out of the depot. For fleets where the phone is equipment, not a personal device.

Tell us what you need See white label

In beta. Android is built and in beta: work-profile enrolment for BYOD, and a separate Device Manage app for company-owned handsets that does kiosk lock-down, launcher replacement, app hiding, policy push and disclosed location reporting. What is NOT done: iOS, which needs Apple push certificates, and Android Enterprise EMM registration with Google — both other companies' approvals rather than our engineering. Two Android gaps are also still open and reported honestly by the device itself: on-shift gating for location, and indoor beacon positioning.

One app or two? The platforms answer this for us

The obvious instinct is to put device management inside the push.tt app people already have. On Android that would be actively harmful, and on iOS it is not a thing that exists. So the shape is decided by the platforms, not by preference.

Android needs a SEPARATE app. Locking a device down means holding the Device Owner role, and a device has exactly one Device Owner — granted only during setup on a factory-reset handset. Bundling that into the PTT app would mean every user factory-resets to install a walkie-talkie, and would permanently collide with any MDM the customer already runs
iOS needs no app at all. Apple MDM is a server protocol plus an enrolment profile; an app cannot restrict an iPhone no matter what permissions it asks for. The work there is a server endpoint and supervision, not an install
So: a small dedicated Android DPC, no iOS app, and the real product in the console — one place to enrol, set policy and see compliance across both

Which also means the push.tt app you already have stays what it is. Device management never becomes a reason your walkie-talkie needs intrusive permissions.

What it would actually do

Scoped to what a frontline fleet needs, which is narrower and more useful than a general enterprise MDM.

Kiosk mode. The handset boots into push.tt and nothing else — the common ask for issued radios-that-are-phones
App control. An allow-list of what can be installed, and silent install of what the job needs
Restrictions. Camera, screenshots, USB transfer, factory reset, adding accounts, tethering
Network and eSIM. Push Wi-Fi and APN settings, and deliver a bought eSIM straight to an enrolled device instead of emailing a QR to somebody
Lost device. Locate, lock, or wipe — and revoke its push.tt keys in the same action, which is the part a generic MDM cannot do
Zero-touch enrolment. Ship a device to a depot and have it configure itself out of the box

You do not have to wipe the fleet to start

The strongest controls need a factory reset, and that single fact stops most device management projects before they begin. So the tier we would ship first deliberately does not need one: a work profile, set up by the person tapping through a prompt on a phone they already own and are already using.

A separate, badged work profile. push.tt and whatever else you nominate live inside it; their photos, messages and accounts sit outside it and are unreachable
Wipe the work profile alone. Somebody leaves, or loses the phone, and the company's data goes while their personal life is untouched. This is the whole argument for BYOD
Screenshots and screen recording blocked for work apps, and the camera disabled inside the profile if the site requires it
Permissions decided by policy rather than by whoever taps fastest — granted or hard-denied for managed apps
All work traffic through a VPN, always on, with no way to route around it from inside the profile
Password rules and lock timeouts that apply to the work side
Copy, paste and contact sharing across the boundary can be blocked, so corporate data cannot be walked into a personal app

What it deliberately cannot do: touch the personal side, disable the status bar, run a kiosk, or replace the launcher. Those need the tier below, and the tier below needs a factory reset. If somebody tells you they can do all of it on a phone your staff already own, one of those two claims is not true.

Locking the launcher: what "kiosk" really buys you

This is the company-owned tier, and it is a different product from the work profile above — it arrives as a separate device-management app and it is granted only during factory-reset setup. In exchange, the device stops being a phone with rules on it and becomes a single-purpose terminal that happens to be phone-shaped. On Android we can get almost all the way there. On iOS we cannot, and the gap is structural rather than a matter of effort.

Our own launcher becomes Home. As Device Owner we register it as the persistent preferred home activity, so there is no launcher picker and no way back to the stock one
You choose the icons and their arrangement. The grid is ours to draw, so it shows the apps you nominated, in the order you set, and nothing else — no drawer, no widgets, no adding to the home screen
Single-app or short-list kiosk. Lock Task Mode pins the device to push.tt alone, or to an allowlist — a scanner, a forms app, a browser at one URL. Apps outside the list cannot come to the foreground even if something tries to launch them
Third-party apps are genuinely removed. Uninstalled, not hidden, and blocked from returning: no Play Store, no unknown sources, no sideloading
Status bar, notification shade, keyguard and Safe Mode can each be disabled, along with factory reset, adding users and USB file transfer

One word on that list needs correcting before a procurement team reads it as a promise. Google and other system apps cannot be uninstalled — they live on a read-only partition and no MDM on any platform can delete them. What is achievable is that they are disabled and hidden: absent from the launcher, unlaunchable, running nothing. On a fully managed device we go further and leave system apps disabled from provisioning onward, enabling only the handful you ask for, so they are never active in the first place. The practical result matches what you want; the word "removed" would still be false, and the storage they occupy is not recoverable.

Why iOS cannot match this, and what it does instead

Android lets an app be the home screen. iOS has no third-party launcher and never has — so a locked-down iPhone is a different, weaker shape, and any vendor showing you one screenshot for both platforms is eliding this.

Supervision is the price of entry — Apple Business Manager or Apple Configurator. An unsupervised iPhone can do almost none of what follows
Icon layout is set, not replaced. A Home Screen Layout payload dictates pages, folders and order, but it is still Apple's home screen underneath
Apps are allowlisted, which hides everything not on the list, Apple's own apps included
Autonomous Single App Mode is the real kiosk equivalent, and it is genuinely strong — the device stays in one app until policy releases it
No equivalent of Device Owner. Restrictions are enforced by the OS at Apple's discretion, not by software you control

So the honest summary: Android can become a push.tt terminal. iOS can become an iPhone that only runs push.tt. Those sound alike and are not, and for a fleet that must be identical across both, Android is the platform that will satisfy the requirement.

The tension, stated rather than glossed

push.tt exists because a provider should not be able to listen to your crew. An MDM is the opposite kind of power: it can locate a device, control what it runs, and erase it. Selling both without saying so would be dishonest.

It does not weaken the encryption. Channel keys stay on member devices and our servers still relay ciphertext — MDM manages the hardware, not the conversation
But it does give the ORG real power over the handset, and that power is only legitimate on a device the organisation owns and issued
So enrolment will be explicit and visible on the device, the person carrying it will be able to see what is being managed, and BYOD will use a work profile that cannot touch the personal side
And every administrative action will be audited, the same as every other privileged action in the console

We do not build covert location tracking of staff. Locate-on-lost is a deliberate, audited action against a specific device, and it is not a tracking feature. GPS fleet tracking is the separate, deliberate feature that shows a live map now — optionally limited to on-duty use, visible on the device the whole time, and with no covert mode. The line is simple: we ship tracking that the person being tracked can see, and refuse the kind they cannot.

What it costs to get there

The engineering is the smaller half. Being an MDM vendor means dependencies on Apple and Google that no amount of code shortens.

Apple: an MDM push certificate, and devices supervised through Apple Business Manager or Apple Configurator. Unsupervised iPhones can only be lightly managed
Google: registration as an Android Enterprise EMM to use the management APIs, plus a published DPC app
Ongoing: both platforms change their management surface every major release, so this is a commitment to maintenance, not a one-off build
Hardware: zero-touch needs devices bought through a participating reseller, which affects procurement before anything is installed

If you have a fleet and a timeline, tell us the platform split and whether the devices are company-owned. That answer decides whether this starts with the Android DPC, the iOS server, or neither.