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.

[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.

-- 

Per Olofsson, IT-service, University of Gothenburg

--
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.

--
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/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:

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

21 jan. 2026 kl. 22:01 skrev 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>:

--
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.

[Gregory Neagle]

Scenario: there is a blocking application that requires user iteraction before it will quit. Here it is iTerm:

I click “Quit Apps”:

iTerm comes to the front, and displays this dialog. If I do nothing for a while, MSC changes the sheet contents:

OK. so far so good. I click “Quit Apps” again, and now the sheet looks like this:

IOW, the spinner is awkwardly displayed over the the “Manual quit required” message.

I think the message should be removed when the spinner is displayed, though alternately, the layout could be altered so that the spinner isn’t on top of the message.

-Greg

[Gregory Neagle]

I think the layout of this sheet could be improved.

(Ignore the icons, as that’s a side-effect of my quick-and-dirty testing method, which is to launch the apps, then remove them from /Applications _while they are still running_)

Note how “iTerm.app” is cut off. The enclosing view’s height should be a multiple of the “line items” height. IOW, the stack view should cleanly display either four or five items and not 4-3/4 items.

I think we’d want to get rid of the empty space between the bottom of the stack view and the “Reopen” checkbox control.

I’d also consider getting rid of the border around the stack view if there are few enough items such that we can display them all without scrolling:

(Ideally without cutting off that last item)

vs

BTW, what’s the maximum height here? IOW how tall will this sheet get? (Haven’t yet looked at the code to figure it out)

-Greg

On Jan 21, 2026, at 1:01 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

[Gregory Neagle]

I experimented with never showing the list of apps that have been quit and I think I prefer this UI: the list of blocking apps just gets shorter. IMHO, apps moving from the blocking apps list to a list of quit apps and the sheet resizing and animating is distracting. I’m not convinced it provides any useful info to the user.

You still need to _track_ the apps you’ve quit (so you can re-launch them later), but they don’t need to be _displayed_.

One possible enhancement:

If the user chooses to quit apps, and MSC successfully quits _some_ of the apps, but the user ultimately cancels (for example, because there is an open app with unsaved changes and the user decides _not_ to quit that app and also _not_ to proceed with the updates), perhaps MSC should re-open the apps it did close before the user canceled (or perhaps offer to do so).

-Greg

On Jan 21, 2026, at 1:01 PM, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> wrote:

[Gregory Neagle]

Here’s a close approximation of what I think is a better layout when there are six or fewer blocking apps:

Since there are six or fewer apps, the scroll view has no borders and no scroll behavior at all — functionally it’s just an invisible frame/container of the NSStackView.

After I click “Quit Apps”, it successfully quits four of the apps, but iTerm prompts for user approval. If I ignore or cancel that request, eventually the sheet in MSC looks like this:

No list of apps that were quit is needed (IMHO) and the sheet does not resize or animate as apps quit, unnecessarily drawing attention to itself.

-Greg

On Jan 25, 2026, at 12:08 PM, Gregory Neagle <gregn...@mac.com> wrote:

I think the layout of this sheet could be improved.

<PastedGraphic-2.png>

(Ignore the icons, as that’s a side-effect of my quick-and-dirty testing method, which is to launch the apps, then remove them from /Applications _while they are still running_)

Note how “iTerm.app” is cut off. The enclosing view’s height should be a multiple of the “line items” height. IOW, the stack view should cleanly display either four or five items and not 4-3/4 items.

I think we’d want to get rid of the empty space between the bottom of the stack view and the “Reopen” checkbox control.

I’d also consider getting rid of the border around the stack view if there are few enough items such that we can display them all without scrolling:

<PastedGraphic-4.png>

(Ideally without cutting off that last item)

vs

[Gregory Neagle]

Code with my opinionated changes to the UI is now in the 'gneagle-msc-quit-blocking-apps’ branch.

I will shortly be replacing the 'msc-quit-blocking-apps’ branch with a Munki7_1dev branch which will also include @MagerValp’s PR for retrying downloads on connection failure.

-Greg

On Jan 25, 2026, at 5:17 PM, Gregory Neagle <gregn...@mac.com> wrote:

Here’s a close approximation of what I think is a better layout when there are six or fewer blocking apps:

<PastedGraphic-1.png>

Since there are six or fewer apps, the scroll view has no borders and no scroll behavior at all — functionally it’s just an invisible frame/container of the NSStackView.

After I click “Quit Apps”, it successfully quits four of the apps, but iTerm prompts for user approval. If I ignore or cancel that request, eventually the sheet in MSC looks like this:

[Gregory Neagle]

I’d like to rename the proposed AutoQuitAppsOnUpdate preference to “OfferToQuitBlockingApps”.

I’d also like to rename the proposed AutoForceQuitAppsOnUpdate to “OfferToForceQuitBlockingApps”.

The pkginfo keys are a little harder since we’ve (mostly) establised a “snake_case” pattern, but:

blocking_application_quit_script -> blocking_applications_quit_script. (since there is a “blocking_applications” key)

prevent_auto_quit_on_update ->.   blocking_applications_do_not_offer_to_quit  or  blocking_applications_do_not_quit. (I do not really like any of these)

Whaddya all think?

-Greg

[Patrick Gallagher]

I like the Offer versions of the names. 

I'm curious what examples folks might think the OfferToForceQuitBlockingApps would be used for? Seems potentially risky. 

I did a quick test of the new MSC and did the Chrome example from the PR. But I got a "manual quit required" for Chrome. Was that because Chrome does the "hold command + Q" thing? Maybe that answers my question about where OfferToForceQuitBlockingApps would be useful. 

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/1855CF61-64F2-4F92-B5A2-D0B24AD78F11%40mac.com.

[Patrick Gallagher]

I turned off the "hold command + Q" thing and it still required a manual quit. :shrug:

[Gregory Neagle]

Works as expected for me with Chrome. Here’s what I did:

$ sudo rm -r /Applications/Google\ Chrome.app

$ sudo cp -R /Volumes/Google\ Chrome/Google\ Chrome.app /Applications/  #(copied from a mounted disk image with an older version of Chrome)

$ open -a Google\ Chrome

I then ran the test instance of Managed Software Center, did an update check, which found that Chrome needed to be updated. I clicked “Install”, and saw this:

I clicked “Quit Apps” and Chrome quit, Munki installed the new Chrome, and Managed Software Center relaunched Chrome.

----------

As for “OfferToForceQuitBlockingApps”: totally within the admin’s control to offer this or not. You should play with it to see how the UI/UX around it is implemented. A good app to test with is iTerm, which seems to always prompt for confirmation when asked to quit, meaning it will always have to either be manually quit or force quit.

-Greg

On Feb 4, 2026, at 9:23 PM, Patrick Gallagher <pat...@gmail.com> wrote:

I turned off the "hold command + Q" thing and it still required a manual quit. :shrug:

On Thu, Feb 5, 2026 at 12:08 AM Patrick Gallagher <pat...@gmail.com> wrote:

I like the Offer versions of the names. 

I'm curious what examples folks might think the OfferToForceQuitBlockingApps would be used for? Seems potentially risky. 

I did a quick test of the new MSC and did the Chrome example from the PR. But I got a "manual quit required" for Chrome. Was that because Chrome does the "hold command + Q" thing? Maybe that answers my question about where OfferToForceQuitBlockingApps would be useful. 

To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/CAF4aQ0TC023QTB1iEUG99ApqbGHTbcAwyAyat4f7eR39c7a7Rw%40mail.gmail.com.

[Gregory Neagle]

If you follow the steps here https://github.com/munki/munki/pull/1305#issuecomment-3795938923 you are likely to see the failure you mention. Jordan’s initial PR fails in this scenario (where the app is running but entirely missing). It works in the scenario where the app is runnng, but out-of-date.

I have a fix for that issue, but haven’t released a new test build — I’m waiting for a decision on preference/pkginfo names before the next test build.

-Greg

On Feb 4, 2026, at 9:08 PM, Patrick Gallagher <pat...@gmail.com> wrote:

I like the Offer versions of the names. 

I'm curious what examples folks might think the OfferToForceQuitBlockingApps would be used for? Seems potentially risky. 

I did a quick test of the new MSC and did the Chrome example from the PR. But I got a "manual quit required" for Chrome. Was that because Chrome does the "hold command + Q" thing? Maybe that answers my question about where OfferToForceQuitBlockingApps would be useful. 

To view this discussion visit https://groups.google.com/d/msgid/munki-discuss/CAF4aQ0SEJSLEjQHnNkS6as9NZ8NyMu34d1Ciiq4_7bgQQF%3DMLw%40mail.gmail.com.

[Gregory Neagle]

The prefs right now in the gneagle-msc-quit-blocking-apps branch are:

AutoQuitAppsOnUpdate -> MSCOfferToQuitBlockingApps

AutoForceQuitAppsOnUpdate -> MSCOfferToForceQuitBlockingApps

(new) MSCOfferToUpdateOthers

The pkginfo keys:

application_quit_script -> blocking_applications_quit_script

I still haven’t decided what to do with “prevent_auto_quit_on_update”.

Some possibilities:

    blocking_applications_do_not_offer_to_quit

    blocking_applications_no_offer_to_quit

    blocking_applications_manual_quit_only

Once we get these decided I can probably issue an early beta.

-Greg

[Gregory Neagle]

You’ll find my current choices documented here:

https://github.com/munki/munki/releases/tag/v7.1.0b1

-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/36655616-95C6-42D6-8378-3A8E19335C3E%40mac.com.