Using Nudge with DDM for macOS Updates in Jamf

Nudge was created to solve a very practical problem. For years, some macOS updates still required user interaction. Someone had to click Install, and in many cases authenticate with their password before the update could continue.

Today, that landscape has changed considerably. Declarative Device Management (DDM) has dramatically improved how managed software updates work, reducing the situations where administrators have to rely on user intervention alone. Because of that, Nudge is no longer as essential as it was several years ago—but I don’t think that makes it obsolete. It simply means its role has evolved.

That is the part I think gets lost whenever the conversation turns to “Is Nudge dead?”

If I’m choosing where update enforcement should live, I want that responsibility to stay with DDM whenever possible. Jamf’s managed software update workflows, built on DDM, allow administrators to declare update intent, enforce compliance deadlines, and report update status back to management. That’s exactly what a modern MDM framework should be doing.

Nudge complements that approach by focusing on the user experience instead of the enforcement itself. Rather than simply waiting until an update becomes mandatory, Nudge provides users with clear communication well in advance. It explains why the update matters, reminds them that a deadline is approaching, and gives them an easy path back to Software Update before enforcement becomes necessary.

Instead of viewing Nudge and DDM as competing solutions, I think they work best together. DDM provides the management and compliance framework, while Nudge helps users understand what’s coming and gives them every opportunity to complete the update on their own schedule.

The JNUC 2025 session macOS Patching with Nudge and DDM in the Real World illustrated this approach well. NetApp shared a deployment journey that began with roughly 30% update adoption using traditional MDM update commands. Introducing Nudge increased adoption to around 80%, and combining Nudge with DDM pushed that figure to approximately 90% within a two-to-four-week deployment window.

That’s the model I find most compelling. Nudge isn’t replacing DDM, and DDM isn’t replacing Nudge. Each addresses a different part of the update experience. Together, they create a workflow that’s easier for users to follow while still allowing IT to meet compliance requirements.

With JNUC 2026 right around the corner, it seemed like the perfect opportunity to revisit one of my favorite sessions from JNUC 2025. What stood out wasn’t a flashy new feature or a product announcement. It was a candid look at what a real deployment looked like—the successes, the challenges, and everything in between.

Building the Workflow

Now that we’ve established where Nudge fits, let’s build the workflow.

One thing I like about this deployment is that each component has a very specific job. Jamf installs the application, Nudge communicates with the user, SOFA provides current macOS release information, and DDM becomes the enforcement layer when the deadline arrives.

Rather than trying to configure everything at once, we’ll build each piece individually, verify that it works, and then bring everything together into a complete update workflow.

The first step is simply getting the application onto the Mac. If Nudge isn’t installed, none of the configuration we’ll create later has anything to apply to.

For new Jamf administrators, the Jamf App Catalog is by far the easiest deployment method because Jamf handles application updates for you.

Deploy Nudge with Jamf App Catalog

1. In Jamf Pro, go to Computers > Smart Computer Groups.

2. Create a small test group.
   • Use one enrolled test Mac.
   • Ideally choose a Mac that is behind the macOS version you plan to require.

3. Go to Computers > Mac Apps.

4. Click New.

5. Choose the Jamf App Catalog / App Installer source.

6. Search for Nudge.

7. Select the Nudge catalog item.

8. Set the install behavior.
   • For testing, use automatic install.
   • Scope only to the test group.
   • Do not start with all managed Macs.
9. Save and scope Nudge.

The second part is the configuration. Nudge is flexible here, which is one of the nicer parts of the project. The example assets folder includes sample configuration in multiple forms, including a JSON example, a mobileconfig example, and tester assets such as the sample plist. Those all describe the same basic campaign idea: what version is required, when it is required, what the user sees, and how Nudge behaves.

At this point, Nudge should be installed, but you won’t actually see anything happen yet. That’s expected.

Installing the application only gives the Mac the ability to display notifications. The behavior—what version is required, when the deadline is, and what the user sees—is all controlled by the configuration profile we’ll build next.

Configure the User Experience

With the application installed, the next step is teaching Nudge what campaign you want it to run.

This is where the configuration profile comes in. Think of the profile as the policy behind the application. It tells Nudge which macOS version is required, when it must be installed, how often users are reminded, and what options they have before the deadline arrives.

Use the Nudge Jamf Schema

1. Download the Nudge Jamf schema from:

   Nudge Jamf schema

2. In Jamf Pro, go to:

   Computers > Configuration Profiles

3. Click:

   New

4. Name the profile:

   Nudge Configuration

5. Set the profile level to:

   Computer Level

6. Add the payload:

   Application & Custom Settings

7. Select:

   External Applications

8. Click:

   Add Schema

9. Upload or paste the Nudge Jamf schema JSON.

10. Set the preference domain to:

com.github.macadmins.Nudge

1. Jamf should now display Nudge configuration fields from the schema.

2. Configure the required macOS version.

3. Configure the required installation date.

4. Configure deferral behavior.

5. Configure refresh timing.

6. Configure the System Settings / System Preferences bundle IDs.

7. Scope the profile to your Nudge test group.

8. Save the profile.

Sample Nudge Configuration

In Jamf, the JSON path is the one I want to pay attention to because Nudge also publishes a Jamf schema. That schema lets Jamf expose Nudge settings through Application & Custom Settings instead of making me hand-edit a full mobileconfig every time. I can still use a plist or mobileconfig when that makes sense, but JSON plus the Jamf schema gives me a cleaner native Jamf workflow for setting the attributes.

{
  "osVersionRequirements": [
    {
      "requiredMinimumOSVersion": "15.5",
      "requiredInstallationDate": "2026-07-15T17:00:00Z",
      "targetedOSVersionsRule": "default"
    }
  ],
  "userInterface": {
    "simpleMode": false,
    "showDeferralCount": true,
    "forceFallbackLanguage": false
  },
  "userExperience": {
    "allowLaterDeferralButton": true,
    "allowUserQuitDeferrals": true,
    "allowedDeferrals": 5,
    "imminentRefreshCycle": 600,
    "initialRefreshCycle": 18000
  },
  "optionalFeatures": {
    "acceptableApplicationBundleIDs": [
      "com.apple.systempreferences",
      "com.apple.systemsettings"
    ]
  }
}

The example above isn’t meant to be copied verbatim into production. Instead, it demonstrates the settings that make up a typical deployment. Your required version, deadline, and user experience should reflect your own environment and maintenance schedule.

Once the profile has been deployed, it’s worth verifying that the Mac actually received it before moving on.

profiles show -type configuration | grep -i "com.github.macadmins.Nudge"

Installing the binary without the profile gives me an app without a campaign. Installing the profile without the binary gives me settings for an app that is not there. The workflow I want is straightforward: use Jamf to deploy the Nudge app, use the Nudge configuration to define the communication campaign, and use DDM as the enforcement layer.

At this point we’ve built the mechanics of the deployment. Nudge is installed, the configuration profile exists, and Jamf is ready to deliver it.

Before rolling it out to users, there’s one more decision to make: what version of macOS are you actually requiring?

That’s where SOFA enters the picture.

Start with the update decision

Before I configure a Nudge policy, I want to know exactly what I’m asking users to install.

Nudge 2.0 has changed this workflow significantly by adopting SOFA (Simple Organized Feed for Apple Software Updates) as a native source of update information. Instead of manually maintaining operating system versions, build numbers, release dates, and other update metadata, Nudge can retrieve that information directly from the SOFA feeds maintained by the Mac Admins community.

That doesn’t mean you can ignore the update you’re deploying. I still recommend understanding which macOS release you’re targeting, why you’re requiring it, and whether there are any known issues before rolling it out across your fleet. Automation should simplify administration—not replace good decision making.

Even though Nudge consumes SOFA natively, I still find the SOFA website to be one of the best places to validate what’s currently available. It provides an easy-to-read view of Apple’s latest macOS releases, Rapid Security Responses, XProtect updates, and other security-related metadata that can help you verify your deployment plan.

The web interface is a great starting point:

https://sofa.macadmins.io/

If you prefer to inspect the raw data yourself, SOFA also publishes a machine-readable JSON feed:

curl -A "nudge-review" -s https://sofafeed.macadmins.io/v1/macos_data_feed.json \
  | python3 -m json.tool \
  | head -n 80

Whether you’re using Nudge, another update workflow, or simply validating Apple’s latest releases, understanding the data behind your deployment helps ensure you’re making informed decisions before users ever see their first notification.

Once I’ve confirmed the version I want to target, I update the Nudge profile to match that release. From there, the next step is making sure users actually see what I intended them to see before expanding the deployment beyond a small pilot group.

Validate the User Experience

This is probably the most important part of the entire deployment.

Creating Jamf objects is easy. Confirming that users actually experience the workflow you intended takes a little more effort.

Before expanding the scope, I always walk through the entire update process from the user’s perspective.

Test what the user actually sees

The test I care about is not “Did I create the Jamf objects?”

The test is whether the user gets a clear path from the prompt to Software Update, and whether Nudge stops prompting once the Mac meets the requirement.

I will usually open Nudge directly on the test Mac:

/Applications/Utilities/Nudge.app/Contents/MacOS/Nudge -version
/Applications/Utilities/Nudge.app/Contents/MacOS/Nudge -demo-mode

Demo mode is only a UI check. The real test still needs a Mac that is below the required version. I want to see the prompt, click through to Software Update, confirm the expected update is available, install it, and then confirm the Mac reports the expected version:

sw_vers -productVersion

Apple documents that managed software update behavior can be affected by MDM settings, deferrals, managed update commands, eligibility, and other deployment controls. Nudge can keep asking, but it cannot make an unavailable update appear.

If everything looks correct, the pilot deployment is doing exactly what it should. Users receive clear communication, Software Update opens correctly, and the configuration behaves as expected.

The last piece is making sure that communication and enforcement are working toward the same deadline.

The Nudge deployment is now complete.

What’s left isn’t configuring Nudge anymore—it’s configuring the update enforcement that eventually backs up those notifications. This is where DDM and Jamf’s managed software update workflows take over.

Match Nudge to the DDM deadline

This is the part where the Nudge and DDM workflows have to agree with each other.

If Nudge says the user has until July 15 at 17:00 UTC, then the DDM enforcement date should not be July 16, July 14, or some other time that only makes sense to the admin who configured it. The whole point is that the user sees the deadline coming before the Mac enforces it.

In the JNUC session, that was one of the practical details that stood out: the Nudge deadline and the DDM forced install date need to match. Nudge handles the communication leading up to the deadline. DDM handles the install behavior when the deadline arrives.

In Jamf, the DDM side is handled through the managed software update workflow. For current Jamf workflows, that may mean using the Software Updates area to schedule the update for a smart group. For macOS 26 and newer workflows, Blueprints matter because Apple has deprecated the older software update deferral keys in configuration profiles. That does not make Nudge useless. It means I want to be clear about which layer is doing which job.

The DDM enforcement layer is the piece that actually makes the deadline real. If I were building this in Jamf with Blueprints, I would start with the same target version I put into Nudge and build the DDM side around that date.

In Jamf, the Blueprint path is roughly:

1. Go to Blueprints.

2. Create a new Blueprint for the macOS update campaign.

3. Add the software update settings for the macOS version I want to enforce.

4. Set the update behavior so the Mac is allowed to download and install the update through Apple’s managed software update workflow.

5. Set the enforcement date to match the deadline in Nudge.

6. Scope the Blueprint to the smart group that contains Macs below the required version.

7. Add exclusions for machines that should not be in the push yet.

8. Save and deploy the Blueprint.

9. Watch smart group membership, inventory, and update reporting so I know which Macs are still behind.

If I am not using Blueprints yet, the same idea applies from Jamf’s Software Updates area using Apple’s MDM/DDM software update commands. The object is different, but the logic is the same: pick the target version, pick the deadline, scope it to the Macs that need it, and make sure that deadline matches what Nudge is telling the user.

For the scope, I would use the same basic thinking as the Nudge side. Target the Macs that are below the required version. Exclude Macs that are already current. Add any real operational exclusions, such as incompatible hardware, known app blockers, or groups that need a different timeline. NetApp also called out keeping a recent-check-in window in their smart groups so the deployment targets active devices instead of stale inventory.

The simple model is:

Nudge deadline: communicate the deadline to the user
DDM deadline: enforce the same deadline on the Mac
Smart groups: decide who is still in scope
Exclusions: keep current Macs and real exceptions out of the blast radius

Seeing the workflow laid out over time makes the relationship between Nudge and DDM much easier to understand.

Rather than thinking of them as competing technologies, I think of them as two phases of the same update campaign.

Here is how I think about the overlap if April 15 is the date I want the Mac updated:

That is why I think of Nudge as a user-facing pressure layer. Jamf still owns deployment of the app and profile. macOS still owns the update mechanism. The admin still owns the target version, deadline, support plan, and exceptions.

The point of pairing Nudge and DDM is not to keep an old workflow alive just because it is familiar. The point is to split the job cleanly. Nudge gives the user time, context, branding, and a clear reason to act. DDM gives the admin the enforcement path when that time runs out. If those dates do not match, the workflow feels sloppy. If they do match, the user gets a fair warning and the fleet still gets patched.

When people ask whether Nudge is still relevant, I don’t think the answer is simply yes or no.

DDM has absolutely changed how macOS updates are managed, and that’s a good thing. Modern update enforcement belongs in Apple’s managed software update framework. But users still benefit from clear communication before that enforcement arrives, and that’s where Nudge continues to add value.

For me, the goal has never been to choose between Nudge and DDM. The goal is to build an update workflow that’s predictable for administrators and understandable for users. When Jamf, SOFA, Nudge, and DDM each do the job they were designed for, the entire process becomes easier to manage—and far less surprising for everyone involved.

Sources

• Jamf Pro Documentation: App Installers
• Nudge GitHub repository
• Nudge wiki
• Nudge releases
• Nudge Jamf schema
• Nudge example assets
• Nudge JSON example
• Nudge mobileconfig example
• Mac Admins SOFA project
• SOFA macOS data feed
• JNUC 2025: macOS Patching with Nudge and DDM Real-World Deployment Strategy
• Jamf: Managed Software Updates with Apple’s MDM/DDM commands
• Jamf: Deploying 3rd-party options for macOS software updates using Jamf Pro
• Apple Platform Deployment: Manage software updates for Apple devices

rss facebook x reddit linkedin email follow