Patching Without the Ticket Tax: Better End-User UX with Prebuilt Apps

Browsers alone can push updates multiple times a day. If your Apple MDM isn’t handling Mac patch management for third-party apps automatically, packaging each one by hand eats hours you’d rather spend anywhere else.. and skipping the work isn’t a real option, because CVEs and zero-days aren’t slowing down. An out-of-date fleet is an exposed fleet.

Then there’s the part no tooling fixes on its own: people. As Product Manager Selina Ali put it, “I’m the worst end user. I never update anything, I never close anything, I never reboot my machine.” The job isn’t just shipping updates. It’s shipping them without tanking someone’s productivity or losing their work mid-task.

Selina and Senior Solutions Architect Daniel Allen walked through how Prebuilt Apps closes that gap in production, plus a Q&A on conflict resolution, policy hierarchy, and what’s next. Here’s what came out of it.

Stop packaging the apps everyone already runs

The premise is simple: macOS patch management you don’t have to build yourself — a maintained catalog of Mac applications that get packaged, tested, and kept current for you, so nobody on your team hand-builds a Chrome package for the third time this month.

What’s in it today, if you haven’t opened the page in a while:

• 220+ apps actively maintained
• MDM and PPPC profiles included automatically for most apps that need them — with coverage expanding as Apple device management moves toward declarative management
• You can request new apps, as long as they have a publicly available installer outside the Mac App Store and don’t require a license key during installation. Sending the direct download link to [email protected] is the fastest path
• Apps that get locked behind a login page eventually have to be sunset — once the installer isn’t reachable, it can’t be kept current

Automate Mac app updates without losing control

The core controls are worth a refresher:

• Auto-update to latest for apps you want on the newest release
• Scheduling windows for when enforcement happens
• A delay period before new versions roll out — useful for letting an early-access group catch issues first
• Update-only mode for apps you don’t want to deploy, but do want patched if a user installs them on their own

Selina’s own machine is the example: Spotify never gets pushed to her, but it still stays patched through update-only.

Inheritance overrides: one fleet, different appetites for change

Policy settings have always cascaded from the top down. The bigger addition is that you can now override those settings at any level.

The practical version: a parent policy enforces updates every 10 days, one site (Everwood) is overridden to a tighter 5 days, and everything else underneath keeps inheriting the parent’s 10-day setting.

Why you’d want it: Chrome deployed everywhere is easy. A department that needs the newest release sooner — or later — than the rest of the fleet is where a single global setting starts to hurt.

Give users a way to see what’s coming

Pop-up notifications are a blunt instrument. If they’re the only signal, users either dismiss them reflexively or get blindsided by an enforced update mid-task.

The newest addition since the last SudoTalks is a menu bar item — off by default on every policy. Turn it on and users get a persistent, low-friction view of what needs updating and exactly when it’ll be enforced.

Notifications are throttled now, too: they surface on a set cadence (every 4 to 8 hours by default) instead of firing every time an open app falls out of date.

When two policies disagree, most restrictive wins

If you run flex policies, you’ve probably wondered what happens when two of them contradict each other on a setting.

The working principle across the board is most restrictive wins. The shorter notification window, the tighter schedule, the “don’t show the menu bar” setting — each takes precedence over its more permissive counterpart.

One exception is still being worked out: install-and-update versus update-only conflicts inside flex policies can behave unpredictably today. In a straightforward policy hierarchy with no flex policies involved, setting update-only at the top and overriding to install-and-update lower down works exactly as expected.

One piece of guidance has changed. Selina used to recommend schedules as a way to cut notification noise. Now that notifications are throttled, she steers people away from schedules by default — they can quietly block installs entirely for devices onboarding outside the configured window.

Mac patch management guardrails worth knowing

• No downgrades. If a user has already updated an app themselves, it won’t be rolled back.
• No removal scripts. Pulling an app out of a policy stops it from being kept updated — it won’t uninstall it.
• Critical vulnerabilities can pull a version from the catalog. Good reason to periodically check that your enforcement windows still make sense for apps that ship frequently.

For admins who want to build on top of it

The session included a genuinely new resource: a knowledge base article documenting the SQLite database that now tracks Prebuilt Apps status on every device, along with the terminal commands and API available for wiring Mac patch status into your own reporting and automation.

Selina gave a shoutout to Jeremy Kenney of Global Mac IT, who built an open-source plugin connecting Prebuilt Apps to the popular Support App menu bar tool using that same database.

Her one ask: treat the database as read-only. Query it all you like — don’t write to it.

What’s shipping next?

• A CVE detection data dashboard, currently in progress. Auto-remediation is the planned follow-on once it ships.
• Unified notifications — one alert covering every app that needs attention, instead of one per app — still in early discovery, alongside Do Not Disturb support.
• Opt-in MDM profiles for helper tool pop-ups (Slack, VS Code, Firefox) on apps whose developers support it. Being explored, not committed, and opt-in rather than forced on.
• Clearer update conflict rules for the cases that still need a documented, predictable outcome.

Two questions from the Q&A worth passing along

Should I set common apps to update-only at a high-level policy, then override to install-and-latest lower down?

Yes: it’s a pattern a lot of customers already use. The one caveat is flex policies, where install-versus-update-only conflicts aren’t fully predictable yet.

If an app updates faster than my enforcement window, does it ever actually update?

It depends on the app. If Chrome updates weekly and your window is 14 days, the deadline keeps resetting with each new release unless the user closes the app on their own. The fix isn’t a blanket 14-day setting across the catalog — check an app’s release history in its catalog details and set the window to match how often it actually ships.

Catch the recording

The full session and upcoming events — including Frontier, our free virtual conference — are at addigy.com/events.

Testing something with the new SQLite or API access? Building on the open-source plugin? Have a Prebuilt Apps question that didn’t make the Q&A? [email protected] goes straight to Selina and the rest of the product team.