iOS device remains non-compliant after removing blocklisted apps and scan stays pendingSolved

For iOS and iPadOS devices, these are two separate compliance considerations:

1. Blocklisted apps
   If the device has apps that are blocklisted by policy, Hexnode will mark the device as non-compliant until the apps are removed and the updated app inventory is reported back to the portal. After triggering app deletion, run Actions > Scan Apps to refresh the app list.
2. Data protection and passcode
   On iOS, data protection is tied to the device passcode. If no passcode is configured, iOS reports data protection as disabled. However, if the passcode/encryption compliance rules are unchecked in the assigned compliance policy, this status should be treated as informational and should not affect the device’s overall compliance.

If Scan Apps or Scan Device remains Pending/In Progress for an extended period, the delay is usually due to the device not completing an MDM check-in cycle. Keep the device powered on, connected to the internet, and awake. A restart can also force a fresh check-in and help queued commands process.

That makes sense about data protection being informational. In my case the UEM app is not installed on the iPad by design. We do not want the app visible because the devices are locked down for a specific workflow. Does Hexnode require the UEM app for scans to complete?

The Hexnode UEM app is not mandatory for managing a supervised iOS device through MDM. Your setup can work without it.

However, without the local UEM app, actions such as Scan Device and Scan Apps rely only on Apple’s native MDM communication/check-in behavior. Because of that, command processing may take longer, and actions can remain in Pending or In Progress until the device completes the next successful MDM check-in.

In deployments where the UEM app is intentionally excluded, the practical workaround for stubborn queued commands is to restart the device and keep it awake/active after it comes back online. Once the device checks in again, the queued scan should complete and the compliance status should refresh.

In Android kiosk mode, the Keep screen On setting under the kiosk policy can override the standard Android screen timeout restriction. Check the following first:

1. Go to Policies and edit the kiosk policy applied to the device.
2. Navigate to Kiosk Lockdown > Android Kiosk Lockdown > Peripheral Settings.
3. Under Display, make sure Keep screen On is disabled.
4. Then go to Android > Restrictions > Basic.
5. Under Allow Device Functionality, set Screen Timeout to the required value, such as 3 minutes or 5 minutes.
6. Save the policy and sync the device.

If Keep screen On is active, the device display is forced to remain awake and the Android screen timeout value will not take effect.

If the checkbox is already unchecked but the issue continues, remove the Keep screen On command row from the policy completely. While editing the same kiosk policy, look for the Keep screen On row in the active policy configuration and use the delete/remove option beside that row. After the row is removed:

1. Confirm the Screen Timeout value is still configured under Android > Restrictions.
2. Save the policy.
3. Sync the Android kiosk device again.

This clears the kiosk-level display override. Once the command row is no longer present in the policy, the device should follow the configured Android screen timeout.

This is expected behavior. Keep screen On is designed as a kiosk-level master override for deployments where the screen must remain available continuously. If the setting has been added to the policy, removing the command row fully clears the override. After that, the standard Android Screen Timeout restriction can control when the display turns off.