Changes to the App Installers installation process on end user machines

Contributor II
Contributor II

We recently updated App Installers section of the Jamf Pro Admin guide (in 10.40) to provide more detail on the App Installers workflow.

As we call out in this section, App Installers uses the InstallEnterpriseApplication MDM command as its deployment mechanism whereas other app deployment workflows such as policies and patch management use the Jamf management binary. The MDM command does not provide us with the same amount of control as we have with the Jamf binary and depending on how the original software vendor designed their installation mechanism, the installation experience can be quite different than that of an installation that was triggered either via a policy or with a GUI triggered installation  (i.e double clicking the installer).

This has resulted in a less than ideal end user experience with a number of the software titles that are being updated by App Installer such as apps being killed whilst the end user was running the app with no warning, strange dialogs, etc.

To address this we started rolling out a Launch Daemon with a number of App Installer titles where this Launch Daemon would queue the installation and only perform the update once the current version of the app was no longer running.

We have made a number of significant changes to this Launch Daemon to improve the end user experience. A few of the biggest changes that you may notice are firstly that App Installers will now queue all installations in /Library/Application Support/JamfAppInstallers. This should address the phantom App Installers item that would occasionally appear in the Launchpad on some machines.

Secondly, most installation packages will now have a built in notification engine to display a notification to end users that there is a pending installation.

The notification uses the icon of the relevant application and displays the default message of “An update is available. Please quit this application to complete the installation”.

The dialog can be dismissed and the user can continue to use the application until it is a more convenient time for them to quit the app. We will remind the user of the machine that there is an update waiting once a day until the update has been able to successfully complete.

We have also created the ability for you to customise how often the reminder dialog appears and also the ability to set a deadline at which point the app will be quit automatically so that the update can be performed. There is no default deadline setting in the packages deployed by App Installers. The only behaviour that is enabled by default is that the reminder dialog will appear once per day.

We will be adding controls for the notification within the App Installers deployment interface in an upcoming release of Jamf Pro however you can start customising the behaviour now with the use of configuration profiles. Please have a look at the freshly published documentation on how to achieve this here -

Lastly, we will also be using configuration profiles to disable the built in auto update mechanism of any applications that are being maintained by App Installers to address the issue of corrupted application installs when an auto update mechanism and App Installers both try to attempt an update at the same time. This is the only way we can provide a consistent and reliable update process for the end users. If you wish to deploy an application and instead have it be kept updated via the built in auto update mechanism, then performing the installation via a policy would be more appropriate. These pre-built configuration profiles should be available as part of the App Installers deployment at the same time as we release the end user notification control interface. In the meantime we have also published documentation on how you can create your own configuration profiles to deactivate auto update. This documentation is available here -

This new framework will be included with all new installation packages published in App Installers from today. If the ‘Package Publish Date’ in the App Installers metadata is the 6th of September 2022 or newer, it will have this new Launch Daemon.

As always, thank you for the feedback that you have provided on App Installers to this point. We are still hard at work on enhancements to App Installers and your feedback is appreciated.


Honored Contributor

These are great improvements!  Nice to see some of the rougher edges for users being addressed.

Sure makes our jobs easier when we don't p*ss of users 😉

Valued Contributor II

Oh, this sounds good. Can't wait to try this out. 

Valued Contributor

Are there any screenshots of what these notifications for reminders and deadlines will ultimately look like?

 This is an example of the default notification, with no deadline set

Notifications configured.png

 Here is an example with a deadline set (it now has a countdown timer to notify how long until the deadline). It says minutes in this case as we set a deadline of 1 minute for this example. We would expect that most deadlines would be a number of days, in which case it would countdown in the number of days remaining.

Notifications & deadline configured 1.png

 Finally an example of the notification once a deadline has been reached.


Notifications & deadline configured 2.png

I followed the guide and set up notifications, but I'm not getting the app icon. Did I miss something?Firefox Update Notification.png

Legendary Contributor III

That sounds like a very comprehensive amount of improvements to this new deployment mechanism. Thanks for all the work on this so far.

New Contributor II

Is there a timeline for being able to add an option for Self Service installation to these App Installers?

New Contributor III

New Contributor II

Can we make it so the App Installers (NEVER) force closes applications?
I see it written in this article, but it has not been the case with our App Installer deployment of 
Chrome, Firefox and Slack.
"The default behavior is to notify the end user daily and to never force quit an app to perform the update."

Valued Contributor

If you don't set a deadline, it never force closes the application.

New Contributor II

great to know McAwesome!

New Contributor II

Maybe a bit late to the party, but we've got an issue with some of our Macs where the /Library/Application Support/JamfAppInstallers folder is not clearing out, causing our vulnerability management tool to generate a lot of false positives with regards to application versions.  Is there any automation we can use within Jamf to clear those folders out?  Example is below:

Nessus detected 4 installs of Microsoft Word:

Path : /Library/Application Support/JamfAppInstallers/ Word 03.35.21
Version : 16.70

Path : /Library/Application Support/JamfAppInstallers/ Word 01.52.14
Version : 16.68

Path : /Library/Application Support/JamfAppInstallers/
Version : 16.69

Path : /Applications/Microsoft
Version : 16.71

@chrkro we have recently made a change to the process to ensure that the tmp files are properly removed. This should mean that this behaviour does not occur again. Please let me know if you see this occur again.