# Nudge: the macOS update nagger that lets users defer > Nudge is an Apache-2.0 licensed Swift and SwiftUI application that encourages macOS users to install security updates, with multilingual support, custom deferrals and two interface modes. Version 2.0 added fully automated updates by querying the SOFA feed, and the last release was 2.1.4 in September 2026. **macadmins/nudge** — A tool for encouraging the installation of macOS security updates. - Repository: https://github.com/macadmins/nudge - Stars: 1,283 · Forks: 207 - Language: Swift - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/macadmins-nudge ## A replacement for the Python Nudge, not an update agent Nudge is described as a tool for encouraging the installation of macOS security updates, and the README says it is a multilingual application offering custom user deferrals which strongly encourages macOS updates. It is written in Swift and SwiftUI. The word encourages is the whole design. Nudge is not an update agent, it is not a management client, and it does not install anything on the user's behalf. It puts a message in front of a user and lets the user decide, and the flexibility in the product is almost entirely about how that message is shaped and when it is shown. The lineage matters for anyone who has deployed this before. Nudge will only work on macOS Big Sur 11 and later, and it is a replacement for the original Nudge, which was written in Python 2 and 3. If you need to enforce macOS updates for earlier versions, the recommendation is to use nudge-python, which is a separate project in the same organisation. So there are two tools with the same name and the same purpose, split by the operating system generation they can run on. The Swift one is the current one; the Python one is the legacy path for fleets that have not moved. The project also has an institutional home. It is maintained under the macadmins organisation, and the README links the macadmin's Slack channel for the project. That is worth noting for an open source tool in this space, because macOS update prompting is exactly the kind of utility where the community of administrators running it in production is the real documentation. ## Two interface modes, and why the difference matters The README documents the user interface with screenshots in two distinct modes, and each is shown in light and dark and in a localized Spanish version. The first is simpleMode, with two screenshots for English light, two for English dark, and one each for the localized Spanish light and dark variants. The second is standardMode, which has a much larger set: two variants of the first screen with and without an icon, further screens for the interaction, then a second pair with and without an icon, and the localized Spanish versions of the second and fourth screens. The screenshots in the assets/ directory tell you what the difference is in practice. simpleMode is under assets/simple_mode/ and standardMode under assets/standard_mode/, and the standard mode has both icon and no-icon variants of the same screen. So standard mode offers a configurable window with an optional app icon, while simple mode is a reduced presentation. For a tool that appears in front of users, that choice is not cosmetic. A single window with a large countdown and a defer button is a different social interaction from a full panel with options, and administrators deploying this generally need to tune how visible it is. The presence of both a with-icon and a no-icon variant of the same screen suggests the icon is a configurable detail rather than a fixed element, which is the kind of thing a deployment guide would need. The light and dark pairs matter too, since a management tool that renders as a white rectangle in dark mode on a modern macOS desktop is the kind of detail that gets reported as a bug on day one. The Spanish variants show that the localized strings are a first-class part of the interface rather than an afterthought, which connects to the multilingual claim in the description. ## Automated updates came from the SOFA feed Version 2.0 of Nudge added a capability that changed what the tool can do, and it is worth separating from the interface work. Nudge 2.0 enables fully automated updates, by default, by querying the Simple Organized Feed for Apple Software Updates, known as SOFA, for macOS releases. The feed is hosted at sofa.macadmins.io and is itself a macadmins project. The reason this matters is that the previous behaviour of Nudge was largely manual in its inputs. An administrator told it which version to nudge towards, and it compared the running system against that target. With the SOFA feed, the tool can determine the current target itself, which means an administrator deploying Nudge does not have to track Apple's release cadence and update their configuration each time a new macOS point release ships. That is a real reduction in operational work, and it is the sort of thing that decides whether a tool stays deployed. A nudge target that goes stale because nobody updated it is a nudge that stops nudging. The by default wording is also meaningful. The feed query is the default behaviour rather than something you have to opt into, which is the opposite of how Nudge's predecessors in this space tended to work, and it means the tool is doing the sensible thing on a fresh install. The trade is that the tool now depends on an external service being reachable and being correct. If SOFA is down, the nudge target is unknown. That is a small dependency, and it is one the macadmins community maintains, but it is a dependency a fleet owner should know about. ## What the repository layout reveals about the build The top level of the repository describes an Xcode project with more going on than a single app target, and the directory names carry information. The app source is in a Nudge/ directory, with Nudge.xcodeproj/ holding the project file. There are two test targets, NudgeTests/ and NudgeUITests/, so the project has both unit tests and user interface tests. That is worth noting for a SwiftUI application, where the interface is where most of the behaviour lives. The Schema/ directory at the top level suggests the project carries a schema for its configuration, and a schema in a management tool is usually a managed preferences or configuration definition. There is also a Localizable.xcstrings file, which is the modern Xcode string catalogue format, and that is the concrete artefact behind the multilingual claim. The assets/ directory holds the screenshots referenced by the README under the simple_mode and standard_mode subdirectories. The build is scripted. build_nudge.zsh is a zsh build script at the root, and build_assets/ is a directory for the asset build, while Example Assets/ holds example material that is not part of the app itself. The documentation set is the most modern part of the tree. There is an AGENTS.md, a CLAUDE.md, a CHANGELOG.md, a SECURITY.md and a docs/ directory. The presence of both AGENTS.md and CLAUDE.md is a signal about how the project now expects to be worked on, and SECURITY.md in a tool that manages a fleet is a file that gets read before deployment rather than after an incident. The .github/ directory holds the workflows, and .agents/ is another entry whose purpose is not documented in the README. ## Where Nudge is the wrong tool There is a clear boundary in the product itself, and it is the one Nudge's own README draws. Nudge will only work on macOS Big Sur 11 and later. If your fleet includes machines on earlier versions, this project cannot do the job, and the recommendation is the separate nudge-python project instead. A deployment that mixes Big Sur and Catalina hardware needs both tools, or a single one that covers the whole range, and this is not the latter. The second boundary is the nature of the tool. Nudge encourages; it does not enforce. If your requirement is that updates are installed regardless of what the user does, Nudge is the wrong category of software, and no amount of configuration tuning changes that. The deferral mechanism, which lets a user postpone, is a deliberate feature, and a workflow where deferral is unacceptable needs a different tool with a different contract. The third boundary is the target audience. The project is aimed at administrators who manage a fleet and want to nudge their users. A single developer on a single Mac who wants to be reminded about their own updates has a much simpler option in the system's own update mechanisms, and the operational weight of deploying a management tool for one machine is not worth it. The fourth is where the documentation is. The README is short and points to the wiki for information about installation, deployment, and the user experience. So before you adopt Nudge you are committing to reading the wiki, because the repository itself carries almost none of the configuration detail, and the specific options that shape the user experience are the ones you need to get right. ## Conclusion Nudge is a good pick for a Mac administration team that wants users to install security updates without deploying a forced update agent, because the deferral mechanism and the two interface modes let you tune how insistent the reminder is, and the Apache-2.0 licence makes it safe to modify for your own deployment; it is the wrong pick for a fleet still running macOS versions before Big Sur 11, where the project points you at the separate Python implementation instead, and before you adopt it you should read the wiki, because the installation and deployment details are documented there rather than in the repository. ## FAQ ### What is Nudge and what does it do on macOS? Nudge is a Swift and SwiftUI application that encourages the installation of macOS security updates, with multilingual support and custom user deferrals so users can postpone. It puts the reminder in front of the user rather than installing updates itself. ### Which macOS versions does Nudge support? macOS Big Sur 11 and later only. For earlier versions the project points at the separate nudge-python implementation, which was the original Nudge written in Python 2 and 3. ### What is the SOFA feed and how does Nudge use it? SOFA is the Simple Organized Feed for Apple Software Updates, hosted at sofa.macadmins.io. Version 2.0 of Nudge queries it for macOS releases, which enables fully automated updates by default, so the nudge target does not have to be configured by hand each time Apple ships a release. ### What is the difference between simpleMode and standardMode in Nudge? They are the two user interface modes, both shown in light and dark and in a localized Spanish version. simpleMode is the reduced presentation with two screens, while standardMode is the fuller panel and has variants with and without an app icon. ### What licence is Nudge released under? Apache-2.0, with the licence file at the repository root. The most recent release is 2.1.4.81863 from 2026-09-08, and the installation and deployment details are documented in the project wiki rather than in the repository. ## Sources - [Issues](https://github.com/macadmins/nudge/issues) - [License: Apache-2.0](https://github.com/macadmins/nudge/blob/main/LICENSE) - [macadmins/nudge on GitHub](https://github.com/macadmins/nudge) - [README](https://github.com/macadmins/nudge/blob/main/README.md) - [Releases](https://github.com/macadmins/nudge/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/macadmins-nudge