S.U.P.E.R.M.A.N.: nudging macOS users into actually installing updates

The name expands into what the script actually does

The acronym is the clearest description of the tool available. S.U.P.E.R.M.A.N. stands for Software Update Policy Enforcement with Recursive Messaging And Notification, and the project is described as open source software that gives administrators a comprehensive solution to encourage and enforce macOS updates, non-system Apple software updates such as Safari, Jamf Pro Policies, or enforced system restarts. That list is the scope in one sentence, and it is broader than the name suggests, because the mechanism is not tied to the macOS Software Update mechanism alone. Beyond that, super offers a broad range of options for customizable dialogs, notifications, schedules, deferrals and deadlines. The stated goal follows from those options: super makes the macOS update experience better for both users and administrators, which is a defensible claim for a tool whose whole reason to exist is that the default experience is a download in the background that the user ignores for a month. The screenshots in the documentation show the update dialog with multiple customizations and a separate restart notification, so the user-facing surface is a window and a notification, not a log file.

Version 6 changes the enforcement mechanism, not just the cosmetics

The version compatibility section is where the real decision lies, and the difference between the two lines is bigger than a version number. Version 6.x, currently in beta, supports macOS 15 through macOS 27, Mac computers with Apple Silicon, and macOS update enforcement via local authentication and declarative device management, DDM. Version 5.1.x supports macOS 11 through macOS 26, Mac computers with Intel or Apple Silicon, and enforcement via local authentication and mobile device management, MDM. Two things follow. The current line has dropped Intel Mac support and the older macOS versions, so a shop with a mixed fleet is not looking at 6.x yet. And the enforcement path has moved from MDM to DDM, which is a different mechanism with different requirements on the server side and on the enrolled Mac. The transition is not instantaneous either, since 5.1.2 was released on 2026-09-15 while the 6.0.0-beta series is at beta3, dated 2026-10-16, and the release before that was 4.0.3 from 2023-12-14. That gap of nearly three years is the release history of the project, and it means the 5.1 line is the one with real-world deployment behind it.

Deferred deadlines and schedules are where the policy lives

The customisation surface named in the introduction is what turns a script into a policy, and each option maps to a decision an administrator has to make. Dialogs and notifications are the messaging layer, and they are what stops the tool from being a nag. Schedules decide when the user is prompted, deferrals decide how long they can put it off, and deadlines decide the point at which the prompt stops being optional. The reason this matters is that macOS itself already has a deferral mechanism, but it is a single global setting with limited granularity, whereas a script can present a per-update state to a specific user on a specific machine. A deadline in particular is the mechanism that turns encouragement into enforcement, and it is also the setting most likely to produce support calls if it is set aggressively. The repository layout hints at how this is deployed and extended, with a Super-Friends directory alongside the super script, an Example-MDM directory for deployment examples and an Example-Screenshots directory, and the Example-Screenshots tree is organised by major version with the images referenced from the 6.0.0-beta2 branch, which tells you the author keeps versioned copies of the visual assets for the documentation.

A single shell script with a checksum file

The repository is small, and the shape of it is the point. The top level holds a super script, which is the whole tool, alongside a super.checksum.txt file, a CHANGELOG.md, the LICENSE file, and the three directories already mentioned. The primary language of the repository is Shell, which matches a deployment model where a script is pushed to a Mac and run rather than a package that is installed. The checksum file is the detail that tells you how this is meant to be distributed. In a managed fleet, the administrator pushes the script and wants to know the copy that landed on the machine is the copy the administrator pushed, and a checksum file is how that is verified. The repository topics make the deployment context explicit, with mdm, jamf, jamf-pro, jamfpro-scripts, macadmins and compliance among them, which tells you the primary distribution channel is a management system pushing a script to a Mac rather than a user downloading an installer. That model also explains why the project exposes Jamf Pro Policies as a thing it can enforce alongside macOS updates, since in a Jamf shop the policy is usually where update enforcement is normally written.

What is in the documentation and what you have to work out yourself

The repository README is short by design, and it says where the detail lives. The documentation asks you to visit the S.U.P.E.R.M.A.N. wiki for detailed documentation, and points to the CHANGELOG for detailed version progress. The wiki is where the option reference lives, and for a tool with this many knobs that is the right place for it, because the README would otherwise be a wall of flags. The community channels are also named, with the Mac Admins Foundation Slack and a channel called #super, which is a reasonable place to ask about behaviour on a specific macOS version. The project is by Kevin M. White, which matters for a Jamf-adjacent tool, since that name is associated with a long-running set of macOS administration scripts and the Jamf community. What the documentation does not tell you is the important operational detail: there is no description here of the command line interface, the exact configuration mechanism, the log format, or the behaviour when a user is offline or when the machine is on a metered connection. The wiki is the reference for all of that, and anyone adopting this should expect to spend time in it rather than in the repository.

Where this fits against the built-in mechanisms

The honest comparison is with what macOS already provides, and the difference is one of enforcement and messaging rather than capability. The built-in software update mechanism can install updates, defer them, and notify the user, and an administrator can set policy through MDM about when updates are applied. What it does not give you is a custom dialog with your organisation's wording, a per-user deadline with a specific escalation, or a notification that reads like it came from internal IT rather than from the operating system. The trade is a different kind of fragility. The built-in mechanism is maintained by Apple, works with every update policy feature Apple ships, and needs no script on the machine. A script that drives the update experience from outside can present exactly the policy you want, and it can also break when macOS changes an internal API, when a permission prompt appears that the user does not recognise, or when a user disables the script by removing it. That last risk is real in a non-enforced fleet. The choice is between a policy nobody notices because the operating system handles it, and a policy that is visible and accountable but depends on a script remaining in place.

Editorial conclusion

S.U.P.E.R.M.A.N. is a good fit for a Mac administrator who has tried the built-in mechanisms and found that users install updates when they feel like it, and who wants a policy with a schedule, a deadline and a message that reads like it came from the organisation rather than from Apple. It is the wrong tool if you want Apple built-in behaviour exactly, and it is the wrong tool if you do not have a way to deploy a script to every Mac you manage. Before deploying it, read the version compatibility section, because the 6.x line and the 5.1.x line differ in what they support, including the move from mobile device management enforcement to declarative device management, and check the CHANGELOG for the progress of the version you pick. The project is Apache-2.0 licensed, the last push was on 2026-10-16, and the current line is 6.0.0-beta3.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Macjutsu/super on GitHub
4. README
5. Releases