iPad Kiosk Mode for Multiple Apps (ASAM + Allowlist)

A front-desk iPad needs to do two things: greet a visitor through your sign-in app, then drive a Brother QL-820NWB to print a name badge. Many badge printers ship with a vendor utility — Brother iPrint&Label, for example — that handles low-level driver setup, label calibration, and firmware. That utility is a second app. The iPad still has to be a kiosk. This is what iPad kiosk mode for multiple apps is for.

This post is the deep-dive on what the iPad kiosk mode pillar covers briefly in its multi-app section. It expands two patterns — an allowlisted Home Screen via a Restrictions payload, and Autonomous Single App Mode with a hand-off — into the full configuration, the .mobileconfig keys, and a worked end-to-end deployment. If you have not already locked one app cleanly, start with our iPad Single App Mode guide and come back here.

9:41

Reception · Building 1

Welcome

Tap below to check in or check out. We’ll let your host know you’re here.

Sign in Sign out

Returning visitor

When you actually need multiple apps in kiosk mode

Single App Mode is the right answer for 90% of kiosk deployments. One bundle ID locked, one experience surfaced, one exit path. Most visitor sign-in iPads never need more than that.

The 10% looks like this. A supervised iPad runs the InstaCheckin iPad app for sign-in and prints visitor badges to a Brother QL-820NWB. Most of the time the printer “just works” because the sign-in app talks to it directly. But once or twice a quarter the printer needs a calibration run or a firmware update — and the only way to do that is Brother iPrint&Label, the vendor utility, on the same iPad.

You have three options. Take the iPad off the lock entirely during the maintenance window — fine for a small office, painful for a fleet. Ship a second iPad just for the printer utility — wasteful. Or run multi-app kiosk mode and surface both apps on a curated Home Screen, with everything else hidden. Pattern A and Pattern B below are the two ways.

The same shape applies to a self-service ordering iPad that needs a separate payments app, a museum exhibit with a video-playback app and a survey app, or a classroom iPad in testing mode with a primary app and a calculator. Mechanism identical; bundle IDs change.

Pattern A: Allowlisted Home Screen via Apple Configurator or MDM

Pattern A pushes a Restrictions payload to a supervised iPad with an explicit list of bundle IDs the user is allowed to see. Every other app — Settings, Safari, Photos, Mail, the App Store — is hidden from the Home Screen and Spotlight entirely. Single App Mode is off. The user sees a curated Home Screen with only your allowlisted apps and can switch between them by tapping.

The relevant key in the Restrictions payload is allowlistedAppBundleIDs (Apple’s current naming; older docs use whitelistedAppBundleIDs). It is an array of bundle ID strings. Apple Configurator’s profile editor exposes the same control under Restrictions → Apps → Allow only the following apps. The list you build there is the list of apps that survive on the iPad.

A minimal profile that allowlists InstaCheckin and Brother iPrint&Label looks like this:

<key>PayloadType</key>
<string>com.apple.applicationaccess</string>
<key>allowlistedAppBundleIDs</key>
<array>
  <string>io.instacheckin.app</string>
  <string>com.brother.iPrintLabel</string>
  <string>com.apple.Preferences</string>
</array>

Notice com.apple.Preferences is in the list. If you omit Settings entirely, staff cannot reach Settings → Bluetooth to repair the printer. For a maintenance-tolerant kiosk include Settings; for a hardened kiosk where staff have a separate admin path, leave it out.

What the user sees: a Home Screen with two icons (or three, if Settings is allowlisted) and nothing else. No App Library, no Safari icon, no Photos. Spotlight returns nothing for hidden apps. Notification Center and Control Center are still reachable unless you pair this allowlist with the same hardening Restrictions you would use for any kiosk.

To deploy through Apple Configurator 2: build the profile in File → New Profile → Restrictions → Apps, save it, then connect the supervised iPad over USB and install it through Add → Profiles. To deploy through an MDM: upload the profile or build it in the MDM’s Restrictions UI and scope it to a smart group filtering on Supervised = Yes. Apple’s Apple Configurator User Guide walks through the profile-editor side; the MDM-specific clickpaths are vendor-specific but follow the same shape.

Pattern B: Autonomous Single App Mode (ASAM) with hand-off

Pattern B is for kiosk apps that need a true Single App Mode lock — Home indicator gone, app switcher gone, swipes blocked — but also need to programmatically release that lock to hand off to a second allowlisted app. ASAM is how you build that.

Two ingredients are required. First, an MDM-deployed com.apple.app.lock payload with an EnabledApps array listing the bundle IDs that are allowed to enter ASAM. Second, the apps themselves call UIAccessibility.requestGuidedAccessSession(enabled: true) { success in ... } to engage the lock and UIAccessibility.requestGuidedAccessSession(enabled: false) { ... } to release it. Apple’s API reference for the call lives in the UIAccessibility documentation. The API returns success only if the app’s bundle ID is on the allowlist; otherwise it fails silently and the lock never engages.

The allowlist payload looks like this:

<key>PayloadType</key>
<string>com.apple.app.lock</string>
<key>EnabledApps</key>
<array>
  <string>io.instacheckin.app</string>
  <string>com.brother.iPrintLabel</string>
</array>

Note the difference from a static Single App Mode profile. A static lock has an App.Identifier key naming exactly one bundle ID, and the iPad locks to that one app. ASAM uses EnabledApps (array) and lists every bundle ID that is permitted to call into the API. The iPad does not lock until an app actually makes the call.

The hand-off flow: the InstaCheckin iPad app launches at boot, calls requestGuidedAccessSession(enabled: true), and locks itself. A staff member taps an admin gesture and authenticates. The app calls requestGuidedAccessSession(enabled: false) to release the lock and asks the user to tap Brother iPrint&Label. iPrint&Label on launch calls requestGuidedAccessSession(enabled: true) itself and re-engages the lock. When the staff member exits iPrint&Label, control returns through the same path in reverse.

There is a real subtlety here. The window between one app releasing ASAM and the next app engaging it is unlocked. If your Home Screen is hardened with Pattern A’s allowlist, the only icons visible during that window are your two allowlisted apps. Stack Pattern A under Pattern B for the cleanest hand-off.

Pattern A vs Pattern B — when to choose which

The two patterns solve overlapping problems but feel very different in production. The deciding factor is whether you need a true single-app lock at any moment.

Pattern A is the right answer when the kiosk is staff-facing or semi-attended — front-desk, back-of-house, an iPad where staff tap between two apps. The user experience is “iPad with a stripped-down Home Screen.”

Pattern B is the right answer when the kiosk is visitor-facing and needs the full single-app feel — no Home Screen visible, no app switcher, no swipes. The two patterns also stack. A visitor-facing iPad can run Pattern B on top of Pattern A so the brief moment when ASAM is released between hand-offs still does not expose anything outside the allowlisted apps. That is what we recommend for the InstaCheckin + badge-printer scenario.

Worked example: deploying InstaCheckin + a Brother iPrint utility

End-to-end flow for a supervised iPad that runs InstaCheckin in ASAM with Brother iPrint&Label as a hand-off target. The bundle IDs used here are io.instacheckin.app for the visitor sign-in app and com.brother.iPrintLabel for the printer utility.

1. Supervise the iPad. New iPads through an Apple Business Manager-enrolled reseller auto-supervise on first boot. Existing iPads get supervised through Apple Configurator 2 (which factory-erases the device — back up first). Confirmation lives at Settings → General → About as “This iPad is supervised.”
2. Install both apps from the App Store, or push them as managed apps from your MDM. The InstaCheckin iPad app is on the App Store; Brother iPrint&Label is published by Brother International.
3. Pair the Brother QL-820NWB over Bluetooth at Settings → Bluetooth before engaging any lock. Pattern A’s allowlist will hide Settings if you choose to leave it out, so do all initial pairing first.
4. Push the Pattern A Restrictions payload with allowlistedAppBundleIDs listing io.instacheckin.app, com.brother.iPrintLabel, and (optionally) com.apple.Preferences. Scope it to a smart group filtering on Supervised = Yes.
5. Push the Pattern B com.apple.app.lock ASAM allowlist with EnabledApps listing the same two bundle IDs. The InstaCheckin iPad app will call into the API on launch and lock itself.
6. Pair Pattern A with a hardening Restrictions payload — block screenshots, AirDrop, AirPrint changes, Siri, iCloud backup, App Store, and pasteboard sharing. Defer iPadOS updates so the kiosk app version is always validated.
7. Document the exit path. ASAM exits when the app calls requestGuidedAccessSession(enabled: false) from the staff override flow. The Pattern A allowlist exits when the MDM removes the profile. Write down both, including which admin holds the MDM credentials.

Once deployed, the iPad boots, launches the sign-in app, and locks itself via ASAM. Visitors check in. When the printer needs maintenance, a staff member taps the admin gesture, releases ASAM, taps Brother iPrint&Label, performs the maintenance, taps InstaCheckin to relaunch, and the lock re-engages. The visitor never sees the Home Screen except in the brief hand-off window, which is itself locked to two icons.

For the product-level overview of what InstaCheckin actually does once it is locked into kiosk mode, see our office visitor management system page. The Intune iPad kiosk mode walkthrough covers the exact Microsoft Intune clickpath for both payloads if that is your MDM.

Troubleshooting multi-app kiosk mode

Three failures dominate the support inbox for multi-app kiosks. They share root causes you can diagnose in minutes if you know what to look for.

An allowlisted app launches but the user can still see other apps. The iPad is unsupervised. Restrictions payloads install on unsupervised iPads but the allowlistedAppBundleIDs key is silently ignored — Apple gates allowlisting behind supervision. Check Settings → General → About for the supervision banner. If it is missing, re-prepare the iPad through Apple Configurator 2 or re-enroll through Apple Business Manager.

ASAM hand-off does not transfer. The second app’s bundle ID is not on the EnabledApps allowlist. The first app’s release call succeeds, but the second app’s requestGuidedAccessSession(enabled: true) returns a failure callback and the lock never engages. Verify both bundle IDs in the com.apple.app.lock payload — profile typos here are common.

The lock breaks after an iPadOS update. Three sub-causes. The kiosk app’s SDK target was below the new minimum and the app refuses to launch — update the app. A new Settings toggle exposed a control the kiosk now leaks — check the iPadOS release notes and tighten the Restrictions payload. The Configuration Profile signing certificate expired — re-sign the .mobileconfig with security cms -S and re-push. The mitigation in all three cases is to defer iPadOS updates through your MDM until you have validated the kiosk app on a single test device.

If a kiosk iPad ends up in a bad state and you cannot reach the MDM, the recovery path is Recovery Mode in Apple Configurator 2 — factory restore, then re-enroll. Document that path alongside the MDM admin contact.