Published 2026-10-17 · LuckyMDM Blog
The bottom line first: both features keep one app on the screen, but they differ in who can exit and in whether the device has to be supervised. On-device guided access leaves the exit key with whoever holds the passcode set at enable time; server-pushed single app mode keeps that key on the side that pushed it. Choosing between them is a question about your operating model, not about strength.
One line keeps this straight: restricting what a user can touch on screen is a different problem from proving that enrolment exists. Both depend on supervision, which is why they get mixed up, but the evidence for each lives in a different place.
Here is the usual sequence in a retail store. The demo unit boots into a product app. A visitor presses the side button three times, types a six-digit code that someone set on the device, and lands on the home screen. From there they change the wallpaper and join an unapproved Wi-Fi network. When staff check later, everything looks normal: the app opens fine, the device is online, the management relationship is untouched.
That last part is the point. Nothing failed at the channel level, no alarm fired, and no enrolment record changed. The device kept taking commands the whole time; only the on-screen restriction was released locally. A monitoring setup keyed on reachability will never surface this class of event, which is why it needs a different verification habit.
Both states disable the home gesture, confine the session to one app, and may optionally suppress touch input in defined regions of the screen. Judging them by appearance is the first trap: they are two different pieces of configuration stored in two different places, and everything that matters later — who can change it, how quickly, with what trace — follows from where it is stored.
Guided access lives in the accessibility settings of the device itself. Whoever is holding the unit enables it, chooses a passcode (or a biometric) at enable time, and later ends the session locally. It depends on physical possession, does not require enrolment anywhere, and does not require a network connection.
Single app mode arrives as configuration pushed to the device by a management server and takes effect once the device accepts it. Whether it can be applied at all depends on whether the device is in a supervised state — this is the reason most deployments stall, because supervision is not something that can be added later from a settings screen.
Supervision is written during the setup assistant, at the point where device ownership is established. After that step there is no toggle anywhere in the user interface that reverses it. The only route to a different state is erasing the device and running setup again, which is why purchase order timing matters so much: units that are unpacked and activated before they are assigned to your organisation need rework before they can carry supervised-only capabilities, and that rework is linear in unit count.
So a practical rule follows, one you can check: any capability that requires supervision also inherits the expensive rebuild path. Single app mode is such a capability. Guided access is not, because it never reads that state — which is also why it still works on a device that no server knows about.
| Dimension | Guided access | Single app mode |
|---|---|---|
| Where it is configured | Accessibility settings on the device | Configuration pushed to the device by a server |
| Prerequisite | None, works without enrolment | Device must be supervised |
| Who enables it | Anyone with the unit, if the accessibility shortcut is on | The party holding the push permission |
| Who exits | Anyone holding the local passcode | The party that pushed the configuration |
| After a reboot | Usually returns to the normal desktop and needs re-enabling | The restriction is restored at boot; verify once on your own hardware |
| Network dependence | None at all | Push and removal need the channel; the applied state does not need a live connection |
| Typical use | Short attended sessions, training, temporary handover | Demo units, self-service terminals, teaching carts |
| Trace left behind | Local action, effectively no server record | Push and removal recorded server-side |
Open Settings, then Accessibility, then Guided Access, and read the state of that switch. Then open Settings, General, VPN and Device Management, and look at whether a management configuration carrying this restriction is present. Read together, those two screens settle most questions.
The check that actually settles it involves a colleague who does not know the local passcode. Hand them the device and ask them to leave the app. If they can leave it, the restriction in force is almost certainly the on-device kind. If they cannot, the server-side restriction is doing the work. That single test separates "configuration was written" from "configuration took effect", which is a distinction that no dashboard reading can give you.
LuckyMDM (Sichuan Starlight Network LLC) gates a single app mode rollout on two checks before anything enters the queue: the device must already report as supervised, and the target app bundle identifier must already be present in the installed inventory. Units failing either check are returned to a review list rather than being pushed in bulk, which is what keeps a mixed batch from producing partial results.
Take eight demo units that were released locally and now need erasing and re-enrolling. At the usual working assumption of 40 minutes per unit and 36 USD an hour, that is about 24 USD per unit and 192 USD for the batch. Carry cost for half a day of downtime at 4.5 USD per unit-day adds roughly 18 USD, so the incident lands near 210 USD.
Set that against getting it right the first time: creating a separate group for those eight units, applying the restriction, and verifying each one takes about 2 minutes per unit, 16 minutes in total, roughly 10 USD of staff time. The ratio between the two is about 21 times. The point of the arithmetic is not alarm; it is that this layer is worth doing correctly once, before rollout rather than after.
Groups are worth a separate word because they define how far one mistake travels. Demo units and units already in a customer's hands should never sit in the same group: a group is the blast radius of a push, and demo configuration reaching the wrong group leaves subscribers confined to one app while nobody on site can release them. LuckyMDM keeps those populations in separate groups and requires the pushing side to confirm which group a batch is aimed at.
Why it is wrong: the exit stays on the device. Anybody holding the six-digit code can end the session locally, and the server may never learn that it happened. Using it as the defence line for an unattended kiosk leaves the key within reach of the people you are constraining.
Why it is wrong: moving the exit authority to the server also ties your release capability to server reachability. When the channel is down, nobody on site can grant a temporary exit. Guided access carries the opposite risk — local release at any time. These are different risk shapes, not different levels of security, and they are chosen by scenario rather than by strength.
Why it is wrong: reaching the push channel and being accepted on the device are separate events, and acceptance still depends on the supervision flag and on the target app already being installed. The evidence is on the device, and confirming it costs two minutes.
This comparison covers Apple platforms. Android has its own equivalents — a lock task capability on fully managed devices, known by several different names across manufacturers — with prerequisites and evidence points of its own, so the checklist above is not applicable to those devices without adjustment.
It also does not cover taking every-day-use assets into a single-app lock. Confining a phone that somebody is using under a subscription agreement to one application conflicts with how that unit is meant to be used, so single app mode tends to appear there only for short phases such as acceptance testing rather than as a permanent condition.
Yes, and the useful part is deciding up front who enables, who releases, and who holds the local code. If nobody is on site, the server-pushed restriction remains the only meaningful exit regardless of what else is enabled.
Not at any message printed on the screen. Enrolment is recorded outside the device, indexed by serial number, so compare what the unit shows under Settings, General, About against what the vendor-side registration returns for that serial.
It depends on which mechanism is running. The accessibility route generally comes back to the normal desktop and needs someone to start it again. The pushed restriction is restored at boot and needs the pushing party to remove it. Verify the behaviour once on your own hardware before you rely on either.
It can be sent, but it will not take effect until the app exists on the device. That is why the pre-flight check compares bundle identifiers against the inventory and leaves the unit out of the batch when they do not match.
So which one for a store demo?
Answer it with two questions: will anybody be physically present, and do you need a recorded push and release history? One answer out of the two pointing at "unattended" or "needs a record" puts you on the supervised, server-pushed route.