Last Updated 10/10/2025
Choices provide flexibility which often leads to confusion. Add outdated technology to the mix and you have a perfect storm of confusion within the Workspace ONE UEM (UEM) Console. Here are my thoughts on how to tackle this mess as Omnissa continues to work through how to update the UEM Console to support Apple’s backend changes while they continue to try and support older devices.
There are 3 options to manage OS updates on Apple Devices:
- Use UEM Profiles
- Use UEM Device Updates
- Use 3rd party integrations
Option 1 of 3: Configure UEM Profiles to support OS updates
Note: This blog references UEM Console 2506 Patch 8 with Modern SaaS Architecture Enabled
UEM uses Profiles to configure the behavior of the Apple Devices when Apple sends the device an OS update. Imperative Profiles are what we’ve been configuring for a decade. Declarative Profiles are the new kid on the block. Apple has dictated that, when available, Declarative Profiles are the correct and supported method to manage software updates for version 26 and above. To provide flexibility Omnissa continues to allow both profile methods to be configured and deployed via UEM as many customers hold on to very old Apple hardware for a very long time.
What confuses many is that Imperative Profiles on iOS do not trigger an OS update to happen. UEM Imperative Profiles do not download or install Apple updates. UEM’s role in the software update process is to send a command to Apple telling Apple to download and install the update on the device. Declarative Profiles include the trigger for the OS update to begin while still relying on Apple to do all the heavy lifting. At no point does the OS update pass through UEM infrastructure.
iOS/iPadOS Imperative Profile
In UEM under Imperative Profiles > Restrictions > OS Updates there are 3 choices:

Notice that these settings only apply to Supervised devices.
Delay OS Update (Days), Allow Rapid Security Response Installation, Allow Rapid Security Response Removal. In the screenshot above I have configured a value of 3 for the Delay OS Updates. This means that when Apple releases version X on Monday, the end users will not be prompted to install that update until Thursday.
Rapid Security Responses were supposed to be a big deal to allow Apple to do out-of-band updates, but thus far have been mostly unused; but you should still decide if you want them in your environment.
Not much to work with or configure here, which is by Apple Design because they do not want you using this method. Neither do I.
If you deploy this profile to the device, you are relying on your end users to respond to Apple notifications that updates are available and hoping they will install them.
iOS/iPadOS Declarative Configuration Device Profiles
By switching to Declarative Profiles, now IT Administrators have more control to ensure the updates get installed. There are two options available:
Option A: I don’t care HOW just send the damn update and make sure it is installed by a specific date. UEM named this profile “Software Update: Enforcement: Specific”
Option B: I want more control over HOW the update is deployed but install it by a specific time. UEM named this profile “Software Update Settings”
UEM lets you deploy both of these options, separated by UEM SmartGroup Assignments, just make sure you do not target the same devices with both options.
Here is an example of Option A:

Define the Target OS Version. Define the Target Local Date Time. And notice that it can be down to the millisecond. Yes, it really can. Crazy but true. This is LOCAL DEVICE time, so keep that in mind when setting this. And annoyingly you must specify the time in this exact format or the payload will fail to install.
Target Build Version is another one of those flexibility decisions. It can be defined if you are so inclined, but I’ve yet to find a use case where this makes any real sense to include.
Details URL is used if you want to provide additional information to the end user about the update they are being forced to install.
That’s it. With this profile UEM passes this request to Apple, and Apple handles the rest. Here is Apple’s visual of what is going to happen on the users device after this payload lands:

If you wish to geek out on more details I refer you to these two Apple articles:
https://support.apple.com/guide/deployment/install-and-enforce-software-updates-depd30715cbb/web
There is only one problem with this approach: It’s only good for the specific OS update you picked when it was originally built. To update it, either create a new one and deploy it, or update the Target OS Version and re-deploy it. Make sure if you choose this update option that you also update the Target Local Date Time as well otherwise devices will use the original date, which is past due and they will immediately install the update.
For a less hands on approach Option 2 might be preferred.
Here is an example of Option B:

If you used Option A, the end user got nagged with update messages until the device beat them into submission or the deadline passed and they lost the ability to choose to delay any longer. By switching to using Software Update: Settings, Apple has included a method to stop most of the end user device notifications referenced in the Apple graphic above.
Software Update Recommended Cadence is a drop down box to configure how you handle the end user confusion that just happened where Apple released iOS 18.7.1 and 26.0 at the same time. On the device, the OS prefers to tell the user to install 18.7.1 and only if the user scrolls to the bottom of the software update screen do they see the option to install 26 instead. You can eliminate this scenario by choosing Oldest, Newest or keep the behavior and choose All.
For organizations that require more control over bandwidth, the Automatic Software Update Settings come in handy. Your choices are Allowed, AlwaysOn, AlwaysOff for each of the options in this section.
There is a bug in the current profile builder that is displaying a beta feature that should not be visible here. Ignore all of this section completely as it is broken and should be removed in a future UEM Console 2506 Patch.
Now that you have configured the device behavior, continue to the next section about macOS Profiles, or scroll down to learn a bit more about triggers.
macOS Imperative Profiles
As you might expect, you have more choices and more flexibility on macOS compared with iOS/iPadOS with the Imperative Profiles.

In the example above this uses Apple’s Servers as the download source. If Corporate SUS is selected you must provide the Software Update Server URL.
Install behavior options include automatic installation, background download, check for updates, or don’t check for updates which provides a method to pre-stage the downloads before triggering the installation based on the schedule defined further down in the profile.
On macOS Apple also includes updates to macOS applications like Safari, the Command Line tools, Xcode, and more as part of this same framework. This behavior can be turned off by disabling the “Install app updates” but doing so means you must then source the updates and deploy them via UEM Software Deliver or Product Provisioning.
The “Check for updates every” option allows for 30 minutes, 1 hour, 2 hour, 4, hour 8 hour, 12 hour, or 24 hour.
Probably the most important part of the payload is the Restart behavior. In the example above Force Restart is enabled with a 10 minute grace period but users can defer the time by 1 hour for a max of 3 deferrals. Grace periods can be defined for 10 minutes, 15 minutes, 30 minutes, 1 hour, or 2 hours. Defer time is the same as the Grace period intervals but extends to 4,8,12,24 hour. The max number of defers allows for 1 through 10 or Unlimited. I feel like Unlimited defeats the purpose so I do not recommend it.
It is important to find the balance with these settings between IT Security and corporate productivity.
macOS Declarative Configuration Device Profiles
macOS Imperative Profiles are identical to the iOS profiles discussed in the previous section so I will not be repeating them here.
Option 2 of 3: UEM Device Updates
In many cases the Profile is the only thing necessary to support keeping Apple devices updated. In other cases you can skip configuring any Profiles and rely solely on UEM Device Updates, but I do not recommend anyone do this. Let’s discuss why this is a bad idea.
In the UEM Console under Devices > Device Updates there are two tabs for iOS and macOS. Device Updates builds the grid using Apple’s Software Lookup Service (https://gdmf.apple.com/v2/pmv). This ensures the grid remains updated as Apple releases new updates. A sample of this page is below.

The idea here is to pick the OS update you want to deploy and Assign it to a Smart Group for installation. Assignments allow for timing of the update with exactly 3 deployment methods:
Download & Install
Download Only
Install Only

The tool wizard completes with basic end user notification options for the device.

And therein lies the problem with this tool. These are the only three options for deployment because what this tool relies on is the now Deprecated Apple MDM Command ScheduleOSUpdateCommand. This MDM command is notorious for being flakey and prone to failure which is not something you want to rely on for a function as important as installing OS updates. And this year Apple agreed it was a disaster and officially deprecated the command. Remember Deprecated does not mean REMOVED, so it can still be used on devices, but Deprecated means Apple is finished updating this command and when its broken you will be told by Apple Support to move to Declarative Profiles for better success.
As new updates are released from Apple each individual update must be configured for deployment. There’s no real cleanup necessary for the previous builds as the ScheduleOSUpdateCommand framework includes timeout/retry logic that expires long before the next update shows up.
It is possible to have profiles configured AND assign updates to devices, but this is where we find devices get into messy situations so it is best not to configure the product in this fashion.
There is a hidden gem to this feature that you might find useful even if you never use this tool to deploy updates. Check out this awesome dashboard it uses to track deployment status (sample below). The dashboard provides a number of excellent details that come straight from Apple. These details are not available in Workspace ONE Intelligence, so it’s useful to know that the dashboard exists. In the example below I assigned iOS 18.2.1 and each device provides a status and a reason to help figure out if the command made it to the device.

If you do not create assignments, the dashboard will not reader the right-side Device Status graphic and will not render any devices under the Devices section.
I expect Omnissa to re-architect the Device Updates feature between now and whenever Apple decides to remove the deprecated MDM commands this thing relies.
Option 3 of 3: Third-party integrations
There are multiple 3rd party tools available for managing updates to Apple devices, both paid and free and I’m not even going to scratch the surface at covering them all. Instead I’ll call out one in particular:

For managing macOS updates, a complete replacement for the Omnissa Device Updates feature is a fantastic tool that Matt Zaske authored and published out on GitHub called mUU. https://github.com/euc-oss/euc-samples/tree/main/UEM-Samples/Utilities%20and%20Tools/macOS/macOS%20Updater%20Utility This tool also uses the now deprecated MDM commands, so it too will need to undergo code change or retirement, but if you need a more reliable method to update your existing devices to macOS 26.1 this tool is worth a look. It uses a combination of UEM Scripts and UEM Profiles to trigger the updates and provides a custom front-end for end users.
Reporting
Omnissa Intelligence is the best place to look to track installation status. The built-in OS Updates section provides several charts to track number of devices by OS version, OS Update Events and OS Update Trends, helping to highlight the speed at which the updates are being installed.

