Mountain Lion is (Still) a Quitter
Almost exactly a year ago, I pointed out that Mac OS X 10.7 Lion had the habit of causing some applications to quit while you were using them (“Lion Is a Quitter,” 5 August 2011) — a habit which, as I explained at the time, goes by the name of Automatic Termination. It was with bated breath that I waited to learn whether Lion’s recently released successor, 10.8 Mountain Lion, would prove to have kicked this vile habit. It hasn’t.
I’ve posted a screencast that demonstrates the persistence in Mountain Lion of Lion’s quit-prone behavior. It’s a simple-minded screencast, but it shows plainly that Mountain Lion is still a quitter. You’ll see me first flip through the Command-Tab switcher to reveal what applications are running — just LaunchBar, ScreenFlow, and the Finder. Then, using LaunchBar, I launch TextEdit; and I open a new document. I then close TextEdit’s document, and switch to the Finder by clicking on the desktop. Note that I have not told TextEdit to quit! All I’ve done is
to bring the Finder to the front. Instantly, however, TextEdit quits. If you look sharp, you can see it vanish from the right end of the Dock; a subsequent search for it in the Command-Tab switcher also proves fruitless. (Actually, if you look really sharp, you’ll see that ScreenFlow has also vanished much earlier from the Dock, and is later missing from the Command-Tab switcher as well. Fortunately, the ScreenFlow subprocess that records the screen does not quit!)
Optimistic attempts by various Apple apologists to justify this astonishing behavior have not, in my view, met with any success. The best that can be said for it is that, given the existence of additional Lion and Mountain Lion features such as Auto Save and Resume (which, together, allow an application’s state to be restored the next time it is launched), the distinction between whether an application is running or not is of diminished importance. That might be the case, if an automatically terminated application’s icon remained in the Dock and the Command-Tab switcher, so that you could conveniently relaunch it; and some have suggested that the icon’s failure in this regard was just a minor bug which Apple
would fix in due course. But the fact is that throughout all versions of Lion, and now in Mountain Lion, Apple has not altered this aspect of Automatic Termination’s behavior; an automatically terminated application’s icon is still removed from the Dock and the Command-Tab switcher, just as it would be if the user had quit the application deliberately or the application had crashed. And so the user, who did not quit the application deliberately, is puzzled and annoyed, and in order to continue using this application must now search for it and relaunch it all over again.
(The behavior of Automatic Termination can actually be even worse than I describe here. In Lion, I have seen Xcode terminate itself automatically immediately after being launched — between the time when you double-click its icon in the Finder and the time when you have a chance to tell it what project to open. This can happen even though Xcode, during the brief time it was running, was always frontmost. Unfortunately, I haven’t been able to capture a screencast of that phenomenon; but I assure you that it can happen.)
Fortunately, the intrepid discoverers of command-line incantations have not been idle. It turns out that there’s a way to turn off automatic termination! I don’t know what wizard first unearthed it or when, though I have not found many Internet references to it older than April 2012. It goes like this:
defaults write -g NSDisableAutomaticTermination -bool yes
(You’ll probably have to restart the computer to make the incantation take effect.) For those who tremble to approach a Terminal window, there’s even more good news. You’ll remember that I discussed TinkerTool a while back as one of many ways of throwing hidden system switches through a user interface (“Lion Frustrations? Don’t Forget TinkerTool,” 29 October 2011). Well, the recently released TinkerTool 4.9 incorporates a checkbox that accesses this same setting. It’s on the Applications pane, near the bottom, and reads: “Application control: Don’t allow OS X to automatically quit inactive applications.”
While you’re enjoying TinkerTool (or whatever utility you like to use for getting at these hidden settings), be sure to check out other options that may make Mountain Lion more pleasant. Another new TinkerTool checkbox that I’m particularly fond of is in the General pane: “Disable rubber band effect.” The rubber band effect is the way a scrollable interface in Lion or Mountain Lion will “bounce” rather than just stopping when you reach the limit of its scrollability. Also in the General pane, I like to uncheck “Animate opening windows”; in general, Mountain Lion’s many built-in animations distract me and force me to wait for their completion, so whatever speeds them up or removes them altogether is a good thing. I’m
not saying everyone needs to feel the same way I do about these matters; I’m just pointing out that you have such options if you want to try them out.
Somehow in 10.8, Preview won't let me scan from my printer. I says the selected folder is un-writeable. Yet I can scan in from Image Capture.
And some programs like Safari tends to quit every now and then due to crashing … .
Now if there was a way to get rid of the sliding of screens when going to full screen mode (QT, Dashboard, etc.) AND have the option of having the menubar returned while in full screen mode. I say this because the menubar is eliminated even when the full screen is only on a secondary monitor. The primary monitor's menubar is also hidden (not the way it was in SL).
Are you sure Xcode is automatically terminating and not just crashing? I imagine you've already looked for crash logs, but thought it was worth mentioning anyway.
So, you're saying that, once you close the last open document in an application, the OS closes the application? And, you're saying that this is a bug?
As a fervent Mac user, I understand where you're coming from, as this is a break from traditional Apple OS behavior. However, as a PC user, I am forced to ask if this should be considered a bug at all. This is the way MS windows has operated since ... well, since Windows: The application is subservient to the document, and when the last document is closed, the App terminates automatically.
Am I missing something here?
On a pc you can close a document on most applications and have the application stay open. Works in Word, Excel, the GIMP, etc.
Until you close the final document open, then the app quits. This sure seems to apply to a whole lot of my Windows apps... except for Adobe apps.
The PC behavior is a consequence of how the menu bar belongs to the application window.
(Typically) once you close the window, there is no longer anyway to control the application. So it has no other choice but to close.
On a Mac the menu bar is at the top of the screen. It can remain even though all of the windows are closed. So, it was never necessary for the application to quit merely because it doesn't have a window open. The user can still use File > New to create another document window.
Mountain Lion, and Lion before it, simply don't play well all the time with Microsoft programs. In Mountain Lion, I get long "spinning wheel" hangs all the time in Outlook and Word (using MS Office for Mac 2011), and periodic app crashes in Outlook as well. Apple and Microsoft point fingers at each other, while I pray for an update that will fix the problems.
FYI - from Apple:
"Apps must opt in to both automatic termination and sudden termination and implement appropriate support for them. "
So, this isn't the case for all apps, just those where the developer has opted in to sudden termination.
There's also the reverse problem. If I open a PDF mail attachment in Preview, then close the PDF and quit the Preview app, OS X keeps a background Preview process running--and that process keeps a hold on the document I was looking at. So even though I closed the document and quit Preview, I can't delete the document.
Yes, I also experience this problem. I first noticed it while I was looking at a PDF with Preview. The document happened to reside on an external drive. Even though I closed the document, and Preview, the OS would not eject the drive. I looked at Force Eject and saw that indeed Preview was still open and active, according to the OS.
I've never encountered this problem you're talking about and I have been a power user of leopard, snow leopard, lion, and now mountain lion.
Me either. ML is a great improvement in numerous areas, but like all transition, there will be take aways. Still at least 3 steps forward and one back.
To be clear, Automatic Termination was new in Lion - you couldn't experience it in Leopard or Snow Leopard, and since it has to be supported by the developer, it's most likely to hit with Apple software.
The problem is not so much that Automatic Termination is widely supported, but that it's a badly designed technology that should be avoided until it works consistently in a way that won't confuse users. We're trying, as much as anything else, to show users and developers alike, why it's not a good thing.
Quits in Illustrator when I request print. Contacted Adobe number times - no results.
So, all these changes revert ML and Lion to, well, Snow Leopard...
Until you close the final document open, then the app quits. This sure seem
Matt wrote: Also in the General pane, I like to uncheck “Animate opening windows”;
This also works in Lion. But regrettably Mac OS X Lion has a bug.
When you disable animated opening of windows, the shortcut Ctrl+Cmd+D to activate the inline dictionary panel may have a nasty side effect.
For example in TextWrangler pressing the shortcut will display the inline dictionary panel but when you press Escape the document window closes.
Afterwards trying to open the document again may lead to TextWrangler crashing. The problem also happens in TextMate.
According to BareBones support this is a bug in Lion.
The only way to avoid the issue is to not disable window opening animation.
It would interesting to know if this bug is also present in Mountain Lion.
In the case of Xcode it's most likely a crash. It's rather frustrating that the tool to create OS X and iOS software is prone to frequent crashes.
The other behaviour seems to be intentional. In my years as a Mac sales and support person in the 1990's users were constantly confused by apps that stayed open when the last document was closed. They never used the Open command because they'd invariably click elsewhere and bring up a different menubar. The idea of the app existing independently of the document didn't make any sense to them.
Even today in an app centric iOS world people relate to what they can see. To most an app is only active if it's displaying something. If it's not displaying anything (or playing audio) then whether it's running or not is irrelevant.
Computers should be document centric rather than app centric, but the inconsistency of individual tools would make supporting them a nightmare and leave little opportunity for a software industry to even exist.
I, for one, am grateful for this behavior. Most of the users I support continue to think that closing all the windows / documents in an app, Quits the app. So, I am happy about this change - it is finally fitting my users' expectations!
And if your intent was to close the document you are working on now and open another one (and you only had one document open)? Now you have to go and re-launch your app.
A real productivity killer if the app takes a long time to launch (like anything by Adobe, which, gratefully, doesn't follow Windows convention).
The problem isn't the Mac way of doing things, it's that your clients have been brainwashed into one and only one way of thinking by Windows. I often find the best advise for people who insist on the "Windows Way" is to stick with Windows and leave us Mac users alone.
Is this happening on new Macs with more than the base amount of RAM?
This quitting, crashing, spinning ball stuff is disturbing news. I 've been experiencing this on my 6 yr old Mac, usually involving Safari and Flash web sites. I had planned to buy a new Mac soon. But if Mountain Lion's doing it too, I'll hold off.
"Optimistic attempts by various Apple apologists to justify this astonishing behavior have not, in my view, met with any success. "
I just love how people that actually like the new features in Lion and Mountain Lion are "apologists" and "fanbois."
People who defend Apple decisions that violate basic human interface guidelines - such as visibly quitting applications without user interaction - are apologists, as clearly defined as someone "who offers an argument in defense of something controversial."
As for the "fanbois" construction, the word has never appeared in over 22 years of TidBITS articles.
To me, it doesn't really matter if it violates Apples' Human Interface Guidelines. They're not Apple's Human Interface Laws.
They're just guidelines. And, they're outdated in this instance. Why have an app that is sitting around doing nothing stay open?
I've seen it happen a couple of times. First time was a surprise, but I knew about automatic termination so not a big deal. I opened the app with Quicksilver, like I always do, and it sprang to life instantly.
"Apologists" and "Fanbois" are used interchangeably all over the internet. Just because you choose the "nicer" euphemism doesn't make it any better. You could have merely suggested that the arguments for automatic termination fell flat, for you, but instead you decided to employ an ad hominem attack. Sorry, your defense of the use of "apologist" fell flat.
Bad interface is bad interface. Why have an app sitting around doing nothing stay open? Because the user asked it to - a basic tenet of user interface is that the computer should do what the user tells it to, and should do it consistently every time. Should Mac OS X refuse to quit apps when you hit Command-Q because it thinks you'll want them again right away?
And as Matt shows in his video, it's not like it's quitting after a significant length of inactivity, nor is it quitting because the system needs the resources (not with something as small as TextEdit). If Apple wants to manage resources behind the scenes by terminating the process but leaving the visible representations of it in the Dock and app switcher, that's a different story (and is how iOS works). But at the moment, it's just poorly and confusingly implemented.
The fact that you knew about automatic termination means that you were surprised only once. Fine, but It's unrealistic, and completely against everything Apple does, to assume that any user will be aware of such a low-level behavior. If you don't know about Automatic Termination, you will assume that the app has crashed or just that your Mac is flaky, neither of which benefits anyone, including Apple.
I have never seen this behavior for TextEdit on my systems and lack the NSDisableAutomaticTermination key in all defaults domains of the MBP I'm sitting at now.
That said, there are apps which opt into being terminated once all windows are closed, mostly non-document based apps such as System Preferences. If I recall correctly, there is an obscure info.plist setting which can be set in Xcode to tell the system this app opts into that behavior.
Has anyone filed a bug report?
The idea that one termination model is superior or more natural than another strikes me as odd. It's pure preference. You might as well argue over whether chocolate or vanilla violates Apple's Frozen Treat Guidelines.
Anecdotal evidence from my user base (i.e., my wife and parents), all 15+ year mac users is mixed. To this day my mom persists in thinking to quit an application she closes the window -- she has _never_ used a Windows-based computer.
What's even stranger is my Lion installation has never behaved like this, in fact the 'default' key doesn't even exist on my machine!
$ defaults read NSDisableAutomaticTermination
Domain NSDisableAutomaticTermination does not exist
You'd need to specify the domain (-g or NSGlobalDomain) before the key. Anyway, many hidden preferences like this don't have keys on property lists initially. Otherwise they'd be much easier to find.
Sorry, for brevity I didn't include the complete command line testing I did. I did run w/ "-g" and got the same results. Just tried again w/ "NSGlobalDomain" and got the same results.
What I can't figure out is how come my Lion installation behaves like this parameter is set when it's clearly not. That is, if I close an application window, the application does not quit.
I think NSDisableAutomaticTermination was first mentioned at http://apple.stackexchange.com/a/51246. The answer was probably posted by the same anonymous user who also found out about the ApplePersistence setting (http://apple.stackexchange.com/a/52390) by running strings on system frameworks.
You don't have to restart the computer after running `defaults write -g NSDisableAutomaticTermination -bool true`, but just reopen applications (or log out and back in).
I support what Apple’s doing here, but they _have_ to change OS X so the app which has been automatically quit stays in the task-switcher list.
Interestingly for the first week under Mountain Lion Safari would quit if I hadn't used it for a while—despite have GBs of free memory (no it wasn't crashing). Now it consistently stays running. So maybe there's some added smarts in ML which recognise usage patterns.