From packaging to declaring: the next generation of Mac app deployment

For years, getting a third-party app onto a Mac meant doing the work yourself. Package the installer, host it, schedule it, check that it landed, and repeat when the next version ships. For lean IT teams managing thousands of Mac computers, that loop never ends.

Jamf takes a different approach.

The shift: declare the outcome, not the steps

Apple’s declarative device management (DDM) changes who does the work. Instead of sending a command and waiting to see if the device follows through, you declare the state you want. The device works to reach that state and keep it.

Apps are the natural next step. You say which apps belong on which Mac computers, and the device handles the rest.

What that looks like

The next generation of app deployments is the App Lifecycle Management Engine (ALME). It delivers a curated catalog of non-App Store Mac apps through blueprints, and the catalog keeps growing.

1. Search the catalog
2. Add apps to a blueprint
3. Set maintenance windows
4. Deploy.

Apps install and stay current automatically. Remove an app from a blueprint, and updates stop. The installed app stays in place.

Catalog apps download straight from the vendor, so there’s no repackaging for your team, and maintenance windows let you control when downloads happen. That design is also what lets the catalog grow. Jamf adds an app by defining where to get it and how to verify it, without repackaging or re-hosting the original installer. As the catalog expands, so does what you can declare.

Trust is part of the design

Hands-off updates only work when you trust them. ALME builds that trust in layers:

• Vendor-direct downloads over TLS, so apps come from the source.
• Verification before install: The binary checks the checksum and developer signature after every download and skips any install that fails.
• Your timing: Maintenance windows keep updates out of the way of work, and default notifications tell users when an update is waiting for an app to close.

What this means for Jamf customers

A component that installs and updates apps deserves a clear explanation.

Self Service+ 2.33.0 bundles the ALME binary, a lightweight background daemon that handles vendor downloads, installs and checksum and signature verification.

Your endpoint security tools may list it as new software. That’s expected, and it comes from Jamf. Look for:

• App: ALME.app, at /Applications/Self Service+.app/Contents/MacOS/ALME.app (bundle ID com.jamf.alme)
• Processes: ALME and alme-agent, launched from /Library/LaunchDaemons/com.jamf.alme.plist and /Library/LaunchAgents/com.jamf.alme.agent.plist
• Signed by: JAMF Software, team ID 483DWKW443

The binary stays idle, and installs nothing, until you add an App Catalog app to a blueprint.

It also requires Full Disk Access to update apps stored in protected folders.

Jamf Pro 11.33.0 delivers that permission automatically through a Privacy Preferences Policy Control (PPPC) profile for Self Service+. MacOS gives an embedded app the permissions of its host app, so the profile covers ALME too. Without it, ALME still installs and updates apps in /Applications, but updates to apps in Desktop, Documents or Downloads fail.

Our approach is simple: When a new component arrives on your devices, you should know what it is, where it lives, who signed it, and what it can access.