Last Week on My Mac: Who decides when to quit an app?

I’m unashamedly Old School. When I quit an app, I expect it to close and go away completely, and when I want one to hang around I’ll leave it open, even if I close all its windows. For the last few years I’ve been battling with macOS, which seems to have a mind of its own. Some apps that I want to keep open, often Xcode, seem to quit of their own accord, while others go into App Nap instead.

I first explored what was going on three years ago, and discovered that, these days, apps can have four different states:

  1. running and not napping: these are apps which are still open, and have windows open, even if they’re not at the front;
  2. running in App Nap, and still fully accessible: these are open even though they may have no open windows, and are still active in the Dock;
  3. running but suspended, in App Nap, but hidden from normal user access: undead, which macOS may terminate whenever it chooses;
  4. Not running at all.

The user only controls states 1 and 4. All apps will be put into App Nap (state 2) unless they’re active, and the old NSAppSleepDisabled setting in an app’s Info.plist is now ignored (and has been since Sierra). The setting there which determines whether they can become undead is NSSupportsAutomaticTermination, as I’ve demonstrated in the four example apps available here, although there’s overlap with NSSupportsSuddenTermination.

Undead apps almost vanish from the human interface, and you can only quit them after ‘opening’ that app again, or in Activity Monitor. They do, though, remain listed in the Finder’s Force Quit Applications dialog, where you can clean them up when you wish.

forcequit

Here, Xcode and two of those four StateTest apps are undead, in state 3, lost from the Dock but still ready to be reactivated should I wish.

Last week, Felix Schwarz @felix_schwarz discovered another app state which can result from App Nap:
5. started loading but halted.
You can put apps which haven’t become undead into this state by leaving them open but windowless, in App Nap, then restarting. Normally, when macOS starts up it attempts to restore app states at the last shutdown. Apps which were open at that time are reopened, and their windows restored (unless disabled in the General pane).

App state restoration is different for apps which had no windows open and were in App Nap (state 2) at the time of last shutdown. Instead of being opened and put back into App Nap, macOS now starts to load them, then halts that when an 8 KB stub has been loaded, without any supporting frameworks, etc. They are left in that state until the user activates them, when they load fully and run before being returned to App Nap again.

For some apps, this has a curious if not irritating side-effect: as they’re not yet fully loaded, they may not respond to events. They are thus nascent rather than running (state 1) or napping normally (state 2).

Big Sur, particularly when running Intel apps in Rosetta 2 translation on Apple Silicon Macs, also seems loathe to terminate undead apps, and leaves them hanging around for hours, even through periods of sleep, so long as there remains sufficient memory to retain them. This changed behaviour appears the result of more sophisticated app management introduced in Catalina with RunningBoard, which originated in iOS where it plays a key part in managing apps which can’t be cached when the system runs short of physical memory.

Those who fear some iOS apocalypse is coming to get macOS will by now be in full spate that this proves their dire warnings have been right. But I don’t think it does in the slightest. As I wrote at the time that I was first getting my head around what RunningBoard is up to, this is an important step forward in managing the Mac’s resources. With the arrival of M1 models with their maximum of 16 GB of physical memory, this complex system of app states, the undead, and RunningBoard seems more focussed on maintaining the M1’s high performance in the face of increasing demands on its memory and other resources. Whereas your iOS device may be unable to use cache, your M1 Mac wants to avoid doing so unless it’s really necessary. And stopping and starting apps repeatedly isn’t making best use of your M1 or its battery.

The Old School in me still wants to control apps the way that I’ve been used to. I can see that Apple is encouraging me to change my habits, and perhaps to close windows and let macOS put those apps among the ranks of the undead, ready to open instantly when I might decide that I need them again. I’m beginning to see that, on my M1 Macs at least, this new way of working could have its advantages.