Managed Software Center: quit and relaunch blocking apps

[Gregory Neagle]

Jordan Calhoun has worked on an implementation of a much-asked-for feature in Managed Software Center: the ability for MSC.app to quit (and relaunch) blocking applications when doing an update.

See info here: https://github.com/munki/munki/pull/1305#issue-3834822650

Preference names are not finalized.

A test version of Managed Software Center.app is here: https://github.com/user-attachments/files/24779254/Managed.Software.Center.zip

To enable this for testing:

sudo defaults write /Library/Preferences/ManagedInstalls AutoQuitAppsOnUpdate -bool YES

(and optionally sudo defaults write /Library/Preferences/ManagedInstalls AutoForceQuitAppsOnUpdate -bool YES)

If you are interested in this feature, please test and provide feedback. 

Some things to discuss/things I’m hoping for feedback on:

Names for preference keys

Names for pkginfo keys

UI/UX

Localization of strings in the new UI for quitting blocking apps

And of course any feedback/bug reports on the actual quitting and relaunching behavior.

-Greg

[Gregory Neagle]

To do a full testing of the new features, you’ll also need a updated version of the command-line Munki tools (specifically managedsoftwareupdate) to test the new “prevent_auto_quit_on_update” and “application_quit_script” keys. But you can do early testing with just the test version of Managed Software Center.app, which you can run from anywhere.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-dev/DB343323-60AA-40D7-9F9A-042B0993F145%40mac.com.

[Per Olofsson]

My spontaneous reaction is that this is interesting and it would be a nice option for a few apps. I don't see us making it the default behavior though, we'd still want users to be prompted for most apps, so a pref to make the feature opt-in or opt-out would be needed for this (e.g. an AutoQuitAppsDefault bool).

As for the pkginfo keys:

• prevent_auto_quit_on_update feels like a double negative. Clearly minor, but to me allow_auto_quit_on_update feels more natural.

• In an application_quit_script, could you use the script return code to signal that the application has been successfully terminated? E.g. for video conferencing apps we wouldn't want to quit them if a video call is active.

-- 

Per Olofsson, IT-service, University of Gothenburg

[Gregory Neagle]

On Jan 21, 2026, at 2:00 PM, Per Olofsson <per.ol...@gu.se> wrote:

My spontaneous reaction is that this is interesting and it would be a nice option for a few apps. I don't see us making it the default behavior though, we'd still want users to be prompted for most apps, so a pref to make the feature opt-in or opt-out would be needed for this (e.g. an AutoQuitAppsDefault bool).

Users _do_ get prompted, and I think the naming of the preference keys make that fact confusing.  (I think we need to remove “Auto” from them).

Current (7.0.6) behavior: Users are given a list of blocking applications and are on their own to quit them (and relaunch them)>

New (7.1.0 preview) behavior: Users are given a list of blocking applications with a “Quit apps” button. If they click that, MSC.app attempts to quit them (and optionally, later will attempt to relaunch them).

As for the pkginfo keys:

• prevent_auto_quit_on_update feels like a double negative. Clearly minor, but to me allow_auto_quit_on_update feels more natural.

• In an application_quit_script, could you use the script return code to signal that the application has been successfully terminated? E.g. for video conferencing apps we wouldn't want to quit them if a video call is active.

I’d rather look at the actual list of running processes rather than trusting the admin to write a script that returns this info. Since users are notified and must trigger the attempt to quit apps, I’d think the need to check for things like “active video call” is not high.

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/032A7B73-6D09-4BE8-92DE-69498A048BE1%40gu.se.

[Gregory Neagle]

Also there are screenshots along with the descriptions here: https://github.com/munki/munki/pull/1305#issue-3834822650

-Greg

[Gregory Neagle]

Perhaps the two preference keys should be “OfferToQuitAppsOnUpdate” and “OfferToForceQuitAppsOnUpdate”.

Alternatively, _one_ preference, something like “BlockingApplicationsStrategy”, with supported values of 0, 1, 2:

  - 0 or defined means use legacy behavior (notify but do not offer to quit)

  - 1 means offer to gracefully quit, but if that fails, do not offer to force quit

  - 2 (and perhaps >2) means offer to gracefully quit, and if that fails, offer to force quit

Do we actually need three modes? Would admins really choose the (1) behavior?

The `prevent_auto_quit_on_update` key might become something like “ExcludeFromOfferToQuitOnUpdate” (ugh). Naming things is hard.

-Greg

On Jan 21, 2026, at 2:00 PM, Per Olofsson <per.ol...@gu.se> wrote:

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/032A7B73-6D09-4BE8-92DE-69498A048BE1%40gu.se.