The iPad answer for Home Assistant kiosks that the Android-only options cannot give

Every kiosk app worth reading about for a Home Assistant wall panel is Android-only. Fully Kiosk is Android. The strongest new entrant in the category, Kiosk Satellite, requires Android 7 or newer and has no iOS build at all. If the tablet you were planning to put on the wall is an iPad, the entire comparison you have been reading does not apply to you.

Under that project's launch thread on r/homeassistant, one user wrote: "I'm Sad to only be into apple environment, your software seems to kick ass!" That is a fair summary of the situation, and it is not a marketing problem — it is a platform one. iOS gives you a smaller set of hooks than Android does, and no amount of app engineering changes that. What follows is what an iPad can do as a Home Assistant panel, what it cannot, and where the line is drawn by the OS rather than by anyone's roadmap.

I build HAkiosk, one of the two or three iPad options, so the "can" list is self-interested. The "cannot" list is longer, and it is the one worth your time.

What the iPad actually gives you

A current rendering engine on hardware that is not current. A Home Assistant dashboard is a heavy modern web app — custom elements, a WebSocket connection, live-updating cards — and the thing that decides whether it feels good is the WebView, not the CPU. On iPadOS, that is WKWebView, which is Safari's engine and moves with the OS. On Android it is the System WebView, which updates independently through Play on a Google-certified device — and does not update at all on the devices people actually repurpose for wall panels: de-Googled tablets, old Fire tablets, LineageOS installs, second-hand hardware stuck on an OEM image. That is the single most common reason a cheap Android wall tablet renders HA badly, and an iPad from five years ago is generally still taking OS updates when a €120 Android tablet from two years ago is not.

A device lock the OS enforces, if you are willing to supervise. This is the part that is genuinely easier on Apple's side, and it is worth being precise about the mechanisms because the names collide.

On Android, startLockTask() without device-owner provisioning gives you screen pinning, which the person standing at your wall can leave by holding Back and Overview together. Getting the real lock — the one that cannot be exited — means provisioning the app as device owner, which is an adb shell dpm set-device-owner ... on a freshly wiped device or an EMM enrollment. Kiosk Satellite documents exactly that path for its own silent-update feature.

On iPad the equivalent is Single App Mode: supervise the device once with Apple Business Manager or Apple Configurator, designate one app in the profile, and the iPad boots into it and stays there. A reboot changes nothing. There is no exit until the management server releases the device, and no passcode for a colleague to fumble. If you already run Apple hardware in a small business, this is one enrollment and it is done.

The division of labour is worth stating plainly, because kiosk apps on iOS get credit for something they do not do: the OS provides the lock; the app provides the display. HAkiosk makes exactly one call for the lock — UIAccessibility.requestGuidedAccessSession(enabled:) — and iOS decides what that becomes. On an unsupervised iPad it is a Guided Access session, which needs a Guided Access passcode set in Settings first and fails visibly if it is not. On a supervised iPad whose management server has authorised the app, the same call is an Autonomous Single App Mode request, with no passcode in the loop. Everything the app adds around that is its own: a PIN over its settings and refresh gestures, and the fact that it re-requests the lock every time it returns to the foreground, so a session iOS dropped overnight comes back.

One place to manage a mixed household. If some of your panels are Android and some are iPads, they enrol into the same workspace and take the same pushes: URL, zoom, dark mode, refresh, wake, a live screenshot pulled from wherever you are standing.

What it cannot do, mechanism by mechanism

Home Assistant cannot drive an iPad panel. This is the big one, and it is the difference that decides most setups. On the Android build there is a command topic an automation can publish to. On iOS there is no MQTT client in the app at all — the only remote path is our own enrolled service, which your Home Assistant instance has no way to call. So the pattern the HA crowd actually wants — motion sensor fires, automation swaps the dashboard, room empties, screen goes dark — is not something an iPad panel does today. If that flow is your requirement, buy an Android tablet. I would rather you read that here than discover it on a wall.

There is no timed auto-refresh. The page reloads when the URL changes, when you swipe in from the right edge, or when you trigger a refresh remotely. Nothing reloads on an interval. A Home Assistant dashboard does not care — it holds a WebSocket and updates itself — but if you point the panel at a static page or a Grafana render, put the refresh in the page.

The screensaver is a clock or a black rectangle. Those are the options. No photo album, no weather, no schedule, no web page. And "blank" takes the brightness to zero rather than sleeping the panel, because the app holds isIdleTimerDisabled the whole time it is running. If your requirement is that the display genuinely sleeps at night and wakes on motion, iOS does not do it today, and I am not going to pretend a brightness-zero screen is the same thing.

One URL at a time. A single stored string, on both platforms. No tab set, no rotation timer, no switcher. Changing the URL replaces it.

No microphone, in either direction. Home Assistant ships Assist as a browser feature, so in principle the dashboard could ask for the mic itself. It cannot: the iOS app declares no microphone usage description, so the request is refused before anyone is asked. A panel running HAkiosk on iOS is deaf. That is also true of the Android build for a different reason, and it is why voice-first panels are a different product category rather than a setting.

Two thin black bars. Ten points of horizontal padding, applied unconditionally on every iPhone and iPad. It is a known bug with a fix pending, and it is visible if your dashboard has a full-bleed background.

Nothing restarts after a power cut unless the iPad is supervised. iOS does not let an app relaunch itself after a reboot — that is the platform, not the app. Supervision solves it because the device boots into the designated app. Everything else means someone walks over and unlocks the iPad.

So which one should you put on the wall?

Reduced to the three questions that actually decide it:

• Do you want Home Assistant to control what the panel shows? Then Android, today. The command path exists there and does not exist on iOS.
• Must the screen genuinely sleep and wake on presence? Android again, for the same kind of reason — iOS gives an app much less room here, and our own iOS screensaver is honestly just a clock.
• Do you have iPads, want a locked, always-on dashboard, and manage it from a browser rather than from an automation? Then an iPad is a good panel, and a better-aged one than most cheap Android hardware. Supervise it if the lock has to survive reboots; otherwise Guided Access and a PIN take about two minutes.

Everything in the second list is tracked, and several of the items have more people behind them than I expected when I started counting. If you are the person in that thread who is "sad to only be into apple environment", the useful thing you can tell me is which of those blockers is your blocker — that ordering is the roadmap. hakiosk.com/support reaches me.