Kandji Auto Apps vs Jamf Pro App Installers for Third-Party Mac App Patching

KandjiThe KBY LexiconKandjiKandji, renamed Iru in October 2025, is a device management platform that grew up managing macOS, iOS, iPadOS and tvOS through profiles, Blueprints and compliance checks, and added Windows and Android management at the rebrand. Read Full Context Auto Apps and Jamf ProThe KBY LexiconJamf ProJamf Pro is an MDM platform for configuring, securing and inventorying Apple devices, using scoped policies and profiles delivered via Apple's push infrastructure. Read Full Context App Installers solve the same problem: keeping vendor apps such as browsers and collaboration tools installed and patched without packaging them yourself. The practical differences are in update enforcement and hosting. Kandji Auto Apps can enforce a deadline, then give users a 24-hour deferral and a 5-minute countdown before closing the app. Jamf Pro App Installers default to no update deadline, so you set one on the End user experience tab if you need a bounded patch window. App Installers also need a Jamf-hosted cloud instance (Jamf Commercial Cloud, Premium Cloud or High Compliance Cloud) and accept only smart computer groups as targets.

To move a title across, or to run Jamf Pro well, use two App Installers deployments per app. One is scoped to a test smart group with the Automatic update method. The other is scoped to production with Manual, so a new version reaches production only after you select it. Kandji is deprecated and tenants must move to Iru by 1 December 2026.

#Current Method: How Kandji Auto Apps Patch Third-Party Apps

In Kandji, an Auto App is a pre-packaged Library Item that you assign to one or more Blueprints. Kandji manages and enforces its updates, and it also deploys the supporting pieces the app needs: Privacy Preferences Policy Control (PPPC), system extensions, background items on macOSThe KBY LexiconmacOSmacOS is Apple's Unix-based operating system for Mac hardware, forming the platform layer beneath endpoint management, security enforcement and application lifecycle tooling. Read Full Context Ventura and later, notifications, and Rosetta 2 on Apple silicon when the app requires it. Kandji states that it validates each update’s Apple-issued signature, Team Identifier, code signing identifier and notarisation during download and packaging.

Each Auto App has two controls that matter for patching:

• Installation: Continuously Enforce, Install-on-demand from Self Service, or Update Only. Update Only patches copies already on the Mac when the bundle ID matches, but never installs the app and does not deploy its supporting profiles.
• Version Enforcement: Do not manage updates, Automatically enforce new updates (with an enforcement timeframe and time zone), or Manually enforce a minimum version (with a minimum version and a deadline).

When a new version is released, the Kandji agent caches it on the Mac straight away. If the app is closed, the agent updates it silently. If it is open, the user gets a banner and can update from the Kandji Menu Bar app. At the enforcement deadline, Kandji updates silently with a 24-hour limited deferral. If the app is still open, a 5-minute countdown runs, then the app is closed, updated and reopened. To test before production, Kandji lets you add the same Auto App several times, each with a Label and its own settings, assigned to different Blueprints.

Auto App settings live in Blueprints and in the Kandji tenant, which must be upgraded to Iru before the deadline. If you rebuild them in Jamf Pro, a Labelled test instance becomes a test deployment and an enforcement deadline becomes an Update deadline. If you are deciding between the two platforms, our guide to upgrading Kandji to Iru or migrating Macs to Jamf Pro covers the platform decision; this playbook covers the app patching layer.

#Improved Workflow: Ringed App Installers Deployments in Jamf Pro

Jamf Pro App Installers distribute titles from the Jamf App Catalog to computers in a smart computer group. Jamf sources each package from the vendor and, where needed, repackages and code-signs it; repackaged installers show the signing identity Developer ID Installer: JAMF Software in the title’s metadata. Delivery uses the InstallEnterpriseApplication MDM command through Apple Push Notification service (APNs), after Jamf Pro has checked the Mac’s installed apps with InstalledApplicationList.

The workflow below follows Jamf’s documented best practice. A test ring receives every new version automatically. Production stays on a pinned version until the test ring has run it for an agreed period. A Jamf Pro administrator with rights to Mac apps, smart groups and settings builds the deployments; an app owner signs off each production version. The trade-off against Kandji is one extra click per release and a deadline you must choose yourself.

#Implementation: Building the Two Deployments

Do this on one title first, such as a browser, with a test group of a few IT-owned Macs. Before you start, confirm your Jamf Pro instance is Jamf-hosted cloud, because App Installers are not available elsewhere.

1. Record the current state. List every Jamf Pro policy or patch policy that installs or updates the same app, with its scope and settings. This is your backup: if you stop, you restore exactly this. Stop if you cannot identify every existing installer for the title.
2. Check prerequisites. In Settings > Computer management > Security, confirm Jamf management framework and Self Service is selected; App Installers uses it for notifications. If a restrictions profile blocks disk images under Hard Disk Media Access, titles offered as DMG files may fail to install. Stop and fix the profile scope before continuing if that applies.
3. Create the smart groups. Build a test smart group and a production smart group. Keep criteria simple: Jamf warns that circular smart group references and excessive nesting are common causes of server performance problems. Define the production group so it never contains the test Macs; if a Mac were in both, the Manual production deployment would take priority over the test one.
4. Create the test deployment. Go to Computers > Mac apps > New, select Jamf App Catalog, click Next and click Add for the title. On the Configuration settings tab choose the test smart group, Install automatically and the Automatic update method. Leave Deploy switched off until you have reviewed the metadata.
5. Review the metadata. Check Architecture, Minimum OS, Bundle ID and Shared installation path. If Shared installation path is Yes, versions that are not in the catalogue are not updated, so plan to replace them deliberately.
6. Decide on supporting profiles. Install supporting configuration profiles deploys a profile that disables the vendor’s built-in auto-update when the package recommends it. It appears on the Mac as App Installers - APP_NAME. Jamf advises reviewing this first, including any profiles you deployed to manage App Installers settings in Jamf Pro 10.43.0 or earlier.
7. Set the end user experience. On the deployment’s End user experience tab, set an Update deadline and Force quit grace period that match your patch policy. The default deadline is None. Do not suppress all notifications; Jamf does not recommend it, because users would not know why the app quit.
8. Deploy to test. Switch Deploy on and click Save. Expect the deployment to take up to 20 minutes to begin. Open the Deployment status tab.
9. Create the production deployment. Repeat steps 4 to 8 for the same title, scoped to the production smart group with the Manual update method. Manual pins the current catalogue version; when a new version appears, an information icon shows next to the deployed version, and you apply it with the Select version icon.
10. Retire the old installer. Only after production shows Installed for a sample of Macs, remove the app from the scope of the old policy or patch policy recorded in step 1.

If you schedule large rollouts, Settings > Computer management > App Installers > Deployment settings controls batch size, days and times. These settings decide when commands are queued, not when the app installs on the Mac.

#Guardrails

• One owner per title. Only one App Installers deployment per app applies to a Mac. With overlapping deployments, Jamf Pro picks one: Install automatically beats Self Service, Manual beats Automatic, then the newer version, then the lower deployment ID. The losing deployment shows Unqualified.
• Do not run two patch engines on one app. Keep the old policy until the hand-off in step 10, then remove it. Two engines updating the same bundle ID make failures hard to attribute.
• Least privilege. Give the app owner sign-off authority, not Jamf Pro settings rights.
• Bound the user impact. A deadline without a grace period closes apps abruptly; set a grace period that lets users save work.

#Validation

On the Deployment status tab, each test Mac should move from In progress to Installed. Installed requires the app to be in the Applications folder or a temporary folder, and the Mac to have answered InstalledApplicationList. If the app was open, Jamf Pro installs to a temporary folder such as /Library/Application Support/JamfAppInstallers/ and moves it to Applications when the user closes the app.

For any one Mac, open its inventory record, then History > Management History. You should see InstalledApplicationList and InstallEnterpriseApplication. If you enabled supporting profiles, you should also see a command such as Install Configuration Profile App Installers - Google Chrome. Status updates are not immediate, because they depend on InstalledApplicationList, which runs every few hours.

Your pass condition for the pilot: every test Mac shows Installed, no Mac shows Unqualified, and users saw the notification you configured, by default “An update is available. Quit this application to allow the update to complete.”

#Common Mistakes

• Scoping a static group directly. Targets must be smart groups. Create a smart group with the criterion Computer Group member of the static group.
• Expecting removal from scope to uninstall. If a Mac leaves the smart group, the app stays installed but stops receiving updates. Remove apps through your normal software removal process.
• Assuming a user-deleted app comes back. It stays uninstalled until the deployment is toggled off and on, a new version is published, or the Mac leaves and rejoins the group. Self Service distribution lets users reinstall it themselves.
• Treating Failed as transient. Failed means the Mac failed compatibility checks, such as minimum macOS or architecture, or three attempts six hours apart all failed. Read the reason before retrying.
• Leaving Kandji Update Only habits in place. Kandji’s Update Only patches existing copies without installing. App Installers offers only Install automatically or Make available in Self Service, so scope deployments only to Macs that should have the app.
• Ignoring certificate deadlines. Packages you still deploy through policies may be affected by signing certificate changes; see the Developer ID sub-CA expiry deadline for .pkg installers.

#Recovery

To stop a bad rollout, switch the deployment’s Deploy toggle off and save, so the title is no longer distributed to the group. Expect Macs that already installed the version to keep it. Production Macs on the Manual update method stay on the version you last selected, which is why the production ring is pinned.

Jamf’s documentation describes Select version only for moving to a newer version. If a version breaks the test ring, keep production on its current pinned version, report the issue to the vendor and Jamf, and wait for a fixed release. If a test Mac must return to an older version, treat it as a manual reinstall by your desktop support team, outside App Installers, and record it.

To fall back to the previous method, restore the policy or patch policy from your step 1 record, then remove the Mac from the App Installers smart group so the two do not compete. Confirm recovery by checking the restored method’s own status for the pilot Macs and that the App Installers deployment no longer lists them.

#Measurable Outcome

Measure time from vendor release to fleet installation, and manual packaging work left. For each pilot title, record the number of hours spent packaging, the date the catalogue version appeared, the date you selected it for production, and the date the production group reached Installed. Compare with the same title’s last three releases under the old method. Review weekly during the pilot, then monthly: check Failed and Unqualified counts, titles still deployed by policy, and any production version older than your agreed window. Choose candidate titles for evaluation on a test bed, as in our real Mac pilot comparing Jamf Pro and Kandji.

#App Installers Adoption Checklist

• Jamf Pro is Jamf-hosted cloud, and Jamf management framework and Self Service is enabled.
• Every existing installer for the title is recorded with its scope (your rollback record).
• Test and production smart groups exist, do not overlap and are not nested deeply.
• Test deployment uses Automatic; production uses Manual.
• Metadata checked: Minimum OS, Architecture, Bundle ID, Shared installation path.
• Update deadline and force quit grace period set; notifications not suppressed.
• Pilot Macs show Installed, with the MDM commands in Management History.
• Old policy removed only after production shows Installed.
• Deploy toggle off is the documented stop; no downgrade path is assumed.
• Next decision: add the next title, or keep it on the old method and record why.