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.

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

[Jordan Calhoun]

The iTerm behavior is expected.  If force quit flag is enabled you'll get the option to force quit it instead.

UI updates look good

[Gregory Neagle]

I understand the term behavior is expected. What’s not expected is the unsightly overlay of the spinner on top of the “Manual quit required” message. 

Sent from my iPhone

On Jan 26, 2026, at 6:31 AM, 'Jordan Calhoun' via munki-dev <munk...@googlegroups.com> wrote:

The iTerm behavior is expected.  If force quit flag is enabled you'll get the option to force quit it instead.

--
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/9a2ebfb2-cf28-4192-a3d0-03a9a365fd47n%40googlegroups.com.

[Jordan Calhoun]

agreed on the spinner, that shouldn't be present after the app moves to that state.  I will take a look at the bug and fix when i get a chance

[Gregory Neagle]

I think there might be some confusion here. Let me re-describe the scenario:

1) There are available updates with blocking applications. MSC displays the sheet listing the blocking applications.

2) I click “Quit apps”. MSC attempts to quit the blocking apps.

3) One or more apps don’t quit (in my original example, iTerm did not quit) and MSC displays “Manual quit required” next to the app name (as expected)

4) Rather than manually quitting, I just click “Quit apps” again.

5) A progress spinner appears over the “Manual quit required” message for several seconds.

Some possible improvements:

a) When “Quit apps” is clicked, remove any “Manual quit required” messages before displaying the progress spinners.

b) When “Quit apps” is clicked, do not attempt to quit any apps that have “Manual quit required” displayed.

c) if ‘b’ is implemented, if all remaining apps have “Manual quit required” displayed, do not enable “Quit apps” button

-Greg

[Jordan Calhoun]

Agreed.  IMO if the app doesn't quit the first time around we should just go with c.  In this case we can just mark the quit apps button as disabled after the first execution

[Gregory Neagle]

Similar problem if the force quit preference is enabled:

iTerm doesn’t politely quit, so a “Force Quit” button appears in iTerm’s row. But the Quit Apps button is re-enabled, and I click it.

A progress spinner appears over the Force Quit button — and is never removed/hidden. It stays visible indefinitely.

-- 
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/948111d7-3493-440d-bd26-96385114cac1n%40googlegroups.com.

[Gregory Neagle]

Also, after I sent the previous message, I clicked “Force Quit” and it did not result in iTerm terminating… :-(

-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/948111d7-3493-440d-bd26-96385114cac1n%40googlegroups.com.

[Gregory Neagle]

Force Quit issue addressed here: https://github.com/munki/munki/commit/9569785717b435de65d2f920e016304b08dd4adf

-Greg

To view this discussion visit https://groups.google.com/d/msgid/munki-dev/5CF67779-0EDE-47A8-9D29-AF6B19D2F332%40mac.com.

[Jordan Calhoun]

I should have time to look into this tomorrow 

You received this message because you are subscribed to a topic in the Google Groups "munki-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/munki-dev/F0SWPfYeseM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to munki-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/munki-dev/7C2CB9D9-D328-4398-851D-91BD5D32BA0D%40mac.com.

[Jordan Calhoun]

PR for keeping the close button disabled after first go: https://github.com/munki/munki/pull/1308

[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

[Jordan Calhoun]

first 3 all make sense to me.  The last one is challenging.

What abut just: blocking_applications_offer_to_quit which we can default to true

[Gregory Neagle]

On Feb 3, 2026, at 7:56 AM, 'Jordan Calhoun' via munki-dev <munk...@googlegroups.com> wrote:

first 3 all make sense to me.  The last one is challenging.

What abut just: blocking_applications_offer_to_quit which we can default to true

What I dislike about that is the default to true: traditionally we’ve treated an undefined boolean preference as _false_.

Anybody else have ideas?

-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/485ecabb-ae3c-4ee6-83f2-183819138aabn%40googlegroups.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. 

<Screenshot 2026-02-05 at 12.06.02 AM.png>

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

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

[Jordan Calhoun]

What about either of these options:

blocking_applications_require_manual_quit

blocking_applications_user_quit_required

[Miq Viq]

I would suggest renaming them like blocking_apps etc

-MiqViq

'Jordan Calhoun' via munki-dev <munk...@googlegroups.com> kirjoitti 10.2.2026 kello 17.21:



--
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/ef70241b-41d7-47c7-b088-027f94b7a091n%40googlegroups.com.

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