iPad apps not updating in Hexnode with iOS allowlist policySolved

Hello @ryker ,

For supervised iPads, there are two separate factors that can cause app updates to appear stuck in Hexnode UEM:

• Pending device check-ins: If actions remain in a “Pending” state, verify the device’s last check-in time. Even if the iPad currently has internet access, iOS may not process queued MDM commands until it re-establishes communication through APNs and checks in with the portal.
• Allowlist kiosk-style restrictions: If your policy allows only selected apps (an Allowlist), iOS treats the device as being in a restricted kiosk environment. If the app you are trying to update is currently open and running in the foreground, iOS will not update it silently.

Here are the recommended checks:

• Confirm the app is correctly assigned in your Required Apps policy.

• Re-save the policy after the newer app version syncs from Apple Business.

• Restart a test iPad if it has not checked in recently.

• Navigate to Manage > Endpoints, select the test iPad, click Actions, and run a Scan device command to force a check-in.

• Ensure the target app is not running in the foreground during the update attempt.

If the app updates immediately after a successful device check-in, the issue is likely a delayed connection rather than the app assignment itself.

Regards,
Simon Soctt
Hexnode UEM

Ah, now I see it. The iPad is online, but the portal showed it had not checked in for hours. After running multiple actions, they sat in Pending. Eventually, after a scan completed, the app updated. But I still don’t understand why the device looks like in kiosk and not showing the apps which I didn’t allow.

On iOS, an Allowlist policy and Kiosk Mode are not strictly identical, but their behaviors heavily overlap.

• Kiosk Mode strictly locks the device to a single app or a specific set of apps.

• An Allowlist restricts system visibility so only approved apps can be accessed.

Because both configurations restrict the usable app environment, iOS treats the device as if it is in a kiosk-style restricted state. This is expected behavior when an Allowlist is actively applied.

In our case the bigger issue seems to be remote iPads going idle during app updates. Some devices updated after a bulk Scan Device action, but others didn’t because they had not checked in for a while. These iPads often disconnect from Wi-Fi when they are locked and unused.

Wi-Fi disconnection behavior directly affects MDM command delivery. To preserve battery life, iPads that are locked and idle for extended periods will automatically drop their active Wi-Fi connection. If the device drops off the network, it cannot be reached by APNs and will not check in, meaning Hexnode UEM cannot immediately deliver the app update commands.

A practical workflow to handle this for your deployment is:

1. Define a regular maintenance window when the iPads are expected to be idle.

2. Ensure the iPads remain connected to Wi-Fi during that window (keeping them plugged into power helps prevent Wi-Fi sleep).

3. Run a bulk Scan device action from Manage > Endpoints before waiting for the app updates to process.

4. To automate this, use Hexnode Automation (via the Automate tab) to schedule a recurring Scan device action during your maintenance window.

5. Once the scheduled scan wakes the devices and forces them to check in, all queued actions including your required app updates will process sequentially.

For large iPad fleets using Allowlist restrictions, the most reliable approach is combining scheduled off-hours updates, closed apps, stable Wi-Fi, and automated Scan Device actions.