Contributor II

As you’ve probably heard, Declarative Device Management (or, for less of a mouthful, DDM) is making significant changes to the way in which managed devices go about their business in some key ways - most notably how managed software updates work. We’re going to take a look at this in detail, as it’s been a particularly hot topic in the Apple Admin community over the last couple of years.


What is DDM, anyway?

Firstly, it’s not a typo of ‘MDM’! In a nutshell, gone is the notion that the MDM server needs to constantly check-up on how a device is getting on with a certain command it’s been asked to do; instead, the device has much more independence and tells the MDM server when something has been done. This majorly cuts down on the stream of commands issued to devices (particularly when performing remote software updates, which we’ll loop back to shortly) and means that a growing number of attributes, such as OS version, can be updated on the MDM without an inventory update command being sent. In time, it may very well be the case that inventory updates become totally unnecessary, with devices instead sending real-time data back to the MDM as things change.

Of course, Jamf Pro and Jamf School have support for DDM, so your organisation is already primed to take advantage of it. Being so new, however, Apple are regularly adding to DDM’s capabilities with every major OS release, so it’s important to keep eligible devices updated to ensure full support of the latest features.

You can learn much more about the latest updates to the DDM specification on Apple’s WWDC video. 


OK, so what’s changed with managed software updates?

Much has been made in the Apple Admin community about how remotely updating devices - Apple Silicon Macs in particular - hasn’t been a smooth ride lately. There are solid reasons for this, mainly around the concept of volume ownership in macOS on the latest Macs, which are grounded in security and that is fundamentally a good thing. However, we do need the ability to easily keep our Apple estates updated so that we can stay secure and enjoy the latest software features (plus, the main reason we all update - new emoji!).

Handily, Apple saw fit to overhaul the managed software update workflow across all their operating systems and tie it into DDM. This puts the emphasis on the device to perform the update when instructed, and to report back to the MDM server once it’s been done. While that may sound like a small change, it makes a world of difference to the reliability of macOS updates and the amount of strain on the MDM server, since it doesn’t have to ‘babysit’ the Mac and check-up on it every 15 minutes. It also offers a new option to set an installation deadline, a point in time at which the Mac will forcibly update itself by if the user hasn’t accepted the numerous prompts to do so beforehand (very handy in both lab and 1:1 environments).

These changes are the same across iOS and iPadOS too, and here we can see a screenshot of what that looks like to the end-user, side-by-side before and after the download:

What the user sees during the download What the user sees after the download.What the user sees during the download What the user sees after the download.


Note the prompt to install on both pictures, empowering the user to run the update at their convenience but ensuring a safety net deadline that will force the update for them at that time. This opens up a great new workflow for updating Apple devices overnight as a failsafe mechanism if the user maybe forgets to run the update during their break. It’s important to note, though that a network connection is required at the point of installation, otherwise users will see this:

‘Unable to Install’ message - and the use of Light Mode!‘Unable to Install’ message - and the use of Light Mode!

As you can see, the user is advised that they have a managed software update pending and, as we chose the Schedule option in Jamf Pro, the installation deadline is shown too. The user will also receive periodic notifications that prompt them to perform the update earlier, increasing in regularity as the deadline looms larger (particularly in the hour before installation). Again, this user experience is exactly the same on macOS.

A logical question is, ‘What happens if a device is offline at the scheduled time?’. In this scenario, the device would simply update within the next hour of being online and the user would again receive full prompting throughout that time. This may be an issue if your users sleep their MacBooks overnight, so the pre-existing Deferral software update method may be a better alternative in that situation (whereby the user can delay the update a set number of times before it being forcibly applied). Personally, I really like scheduled for lab desktops and mobile devices, as these have a more predictable uptime compared to laptops, but every organisation is different and it’s important to decide which works best for you from the options available. See Apple’s Platform Deployment guide for more info regarding deferral behavior, etc.


This is AWESOME! So, how do I do it?

Well, the workflow is exactly the same if you’ve been using Jamf’s new software update experience (currently in beta, but can be enabled in your instance under Computers (or Devices) > Software Updates). Simply pick a group (or groups) of devices, click ‘Update’ in the top-right, and you’re done!

However, you will need a few things: 

  • A mobile device running iOS 17/iPadOS 17 or later
  • A Mac running macOS 14 (Sonoma) or later 
  • Jamf Pro 11 or later (hosted in Jamf Cloud)
You can find more information on pre-requisites and further documentation on Jamf’s Learning Hub pages for Updating macOS Groups Using Beta Managed Software Updates and Updating iOS and iPadOS Groups using Beta Managed Software Updates.



As you can see, the UI in Jamf Pro 11 makes it really clear to identify the groups you’re updating and the update method you’re applying to them.


Closing thoughts

One of my favourite updates to macOS 14 and iOS/iPadOS has been this update to, well, updates! I’ve not experienced anything other than perfect results with this in my testing across Macs and iPads, and it’s a real comfort to have greater confidence in the remote update workflow on macOS, as well as providing additional options to users in the form of scheduling OS updates to occur.

Give it a try in your environment and, based on the results, consider potentially different workflows and processes for different types of device - maybe use scheduling for mobile devices and lab Macs, with deferrals for MacBooks. Jamf and Apple have given us the tools to offer more flexibility here for an improved user experience, and that’s something we should definitely celebrate and take full advantage of.

Contributor II

What is it about DDM that makes it require Jamf Cloud? (I'm an on-prem customer.)

Contributor II

Honestly, I’m not sure. That’d be one for either your Customer Success Manager or Support :)


Just tried this, any idea why it doesn't work? i have one test ipad with 16.6 version of the ios. I put it in a static group and then ran through the update wizard, selecting the last option "auto install, auto restart". However its been an hour and nothing has happened. On the ipad itself, there are two updates sitting there pending, but nothing has been done that i can see. They were also there before i did anything above. one is ios 17 and one is a point release of 16.

I checked the log on the ipad for management commands and i dont see any commands about update even sent to the device. The only thing i can see is under Device -> History -> operating system history, is a "product key" iOSUpdate18F72 and "install action" being set to "install ASAP". There are no failed or pending commands in the management history tab and no way that i can see to examine the status or history of this update framework.

Was really jazzed about this, but still seems like it needs work (it does say beta at the top so what did i expect i guess :P).

New Contributor

Hi, where is this configured in Jamf School?



Contributor II

@wifichallenges - This requires iOS/iPadOS 17 to work, as earlier versions don’t have the functionality. On macOS, Sonoma is required (macOS 14). 



You can use DDM with Jamf Pro (on prem) and this new Update Method.  The only catch, is that you can't schedule a deadline if you are on prem.  That feature is only if you are in Jamf Cloud.

You can read the requirements in the Admin Guide:


One question, I'm trying to find out is about scoping to a Smart Group.  If you use a Smart Group as the scope, then send the update command out.  But the next day a new mac gets put in the Smart Group, do they get the Update Command?

Contributor II

@jleomcdo They won’t receive the command if they weren’t in that Smart Group at the time the command was sent. At least not in my testing. 

New Contributor III

@bb_sysadmin from my understanding it is not configured for Jamf School yet. 

New Contributor II

It is giving mixed results. Usually, it won't work in most of the cases.

If this starts working we don't have to use the SUPERMAN and Nudge.

New Contributor II

Thanks for detailed info on DDM,  By this we can push the required OS software updates 

Could you please let me know how we can track the deployment status or logs of particular deployment after scheduling through JAMF.

Contributor II

Hi @seshagiri 

You can check this under the Operating System sections of the device's inventory records. There's one such category under Management and another under History 😊 

New Contributor

I've been trying this in Beta for my macOS users. Couple of thoughts, there is no way to gauge success, I can't confirm that the update notices are seen by my users, what number of users actually update after seeing the update, etc. There needs to be more interaction and availability of stats to see how these update pushes are working. It's like you press the button, and then just have to hope that something happened. Hoping this is something that is being expanded for better use.

Contributor II

@selby - You can check OS update status in the Management and History tabs of a computer's Inventory record, including how many update deferrals a user has remaining (if applicable). Definitely worth checking that out.

In my experience, it works very reliably. If in doubt, have a check that all Apple's required safelisting as per is still in place on your network.

For tracking, you can create Smart Groups to track Macs that either are or aren't on the latest version. I prefer the latter option, as I can then use that group as the scope for my next update push. 

New Contributor

Hi, any updates on this for Jamf School?

Contributor II

@bb_sysadmin I'm not personally aware of any developments, but it'll definitely be coming. 

Contributor III

I would reiterate what @Ecco_Luke said about making sure your APNs traffic isn't being blocked by your network, outbound.

Don't take your Network Team's word for it.  Don't trust, verify.  I learned this lesson the hard way.  There are several free utility apps that will check your network connectivity outbound to Apples external infrastructure.

JET - 

Jamf Check - 

Mac Evaluation Utility - (Available from the 'Apple Seed for IT' beta website) otherwise not publicly available.  You must sign up/sign in with a managed apple ID from your Apple School Manager or Apple Business Manager to see the MEU app.  I believe its listed under 'Resources'.  I highly recommend this app!

Using these three apps, you will be able to determine if any Apple or Jamf related URLs are being blocked, filtered by a web proxy or redirected to a 3rd party service by your network infrastructure.  If this is so, Apples infrastructure will drop the network connection at their end for security reasons.  They classify any tampering with traffic as HTTPS Interception / deep packet inspection, which they don't allow.  All APNs or Apple traffic in general from your network/endpoints to Apples infrastructure must (be whitelisted) come direct.  

If you see red errors for Apple server URLs marked as 'Not Available' especially for APNs related traffic gateways on Apples end, Apple classifies this as a 'deployment blocker'.  It would be one reason why your MDM or DDM update commands aren't working reliably/properly.  Likewise if you have shared lab devices, ensure all of them have an escrowed Bootstrap Token on your Jamf server.  Otherwise update commands will again, fail.
If you have Student Vlans, Staff Vlans and Ethernet and Wi-Fi networks, the utility apps must be run on each of these networks/Vlans to ensure there are no errors in terms of connectivity to Apples infrastructure, outbound.

We found in our org, depending on what campus you were on, and what subnet, and what Vlan, you would get different results for blocked Apple URLs.  Even though our network services team had assured us in the past, that all outbound traffic was allowed, this turned out to be not the case when tested.  Don't trust, verify.

We had to add several firewall outbound rules for all subnets to get our Apple update commands working properly.

  • TCP 2195
  • TCP 2196
  • TCP 2197
  • TCP 5223
  • TCP 443

We also had to add * to whitelist most of the required Apple URLs.  See Apples enterprise documentation below regarding this.

You can check Apples enterprise documentation here:

Use Apple products on enterprise networks 

If your Apple devices aren't getting Apple push notifications 

Once you have 'verified' your network traffic is in order and your devices have escrowed Bootstrap tokens, you should be seeing 80% - 90% success rates for deployed Apple Updates via MDM or DDM.

Any issues after that will come down to the endpoints themselves such as - operating system is too old to work with MDM/DDM commands.  In which case an OS Upgrade (using the full installer) may be required or off boarding the device if its too old to be upgraded.  Other issues can include, not enough free space left on the SSD or not enough battery power left, in which case the update will fail to install or even start.

I hope this info helps with troubleshooting if you are having issues.


Quotes from the above URLs...


If your firewall supports using hostnames, you might be able to use most Apple services above by allowing outbound connections to * If your firewall can only be configured with IP addresses, allow outbound connections to The entire address block is assigned to Apple.

HTTP Proxy

You can use Apple services through a proxy if you disable packet inspection and authentication for traffic to and from the listed hosts. Exceptions to this are noted above. Attempts to perform content inspection on encrypted communications between Apple devices and services will result in a dropped connection to preserve platform security and user privacy.