Matt Neuburg (yes, that same Matt Neuburg whose book I just gave a glowing review) has a piece up on TidBITS about the new feature in OS X Lion called Automatic Termination. As the name implies, this allows for an app to pseudo-Quit on you without your explicit intervention. As cited in the article, John Siracusa has a concise rundown of the feature and when it occurs in his herculean review of Lion:
Lion will quit your running applications behind your back if it decides it needs the resources, and if you don’t appear to be using them. The heuristic for determining whether an application is “in use” is very conservative: it must not be the active application, it must have no visible, non-minimized windows — and, of course, it must explicitly support Automatic Termination.
As Neuburg notes, Siracusa elaborates the implications of this feature. In short, the app only becomes half-quit, residing in a sort of Application Purgatory. It still has technical bits in memory, but it's not executing. It won't show up in your Dock or in your Application Switcher (Command+Tab), but the system still knows about it.
Read the rest of Neuburg's article for the straight facts of Automatic Termination as it exists today in Lion. It's his opinion I'm taking issue with.
In particular, I propose to discuss the big question of whether Automatic Termination is a good thing.
He goes on to say, from a technical standpoint, he doesn't believe it's much of an improvement, because the App Purgatory isn't really saving the computer much in terms of resources or time. But I think this is the wrong way to look at the problem, technically, because “saving resources” in this case means memory, and “saved memory” in operating system terms is wasted memory. There's no sense in having unused memory. When the operating system needs more, it will page for more, like every major operating system has done for years.
Neuburg then turns his attention to the User Experience aspect of Automatic Termination, which I think is its real purpose.
The ultimate goal here is to annihilate the distinction between running and non-running applications. Consider how, on iOS 4, with multitasking, you don’t know what applications are running, because you usually don’t quit an application yourself (you switch away from it and allow the system to tell it to quit if needed), and you don’t care what applications are running, because both running and non-running applications are listed in the Fast App Switcher, and because apps are supposed to save and restore their state […]
Precisely. This is exactly what Apple is after. That the solution more efficiently manages system resources is a bonus. The real purpose is to alleviate the user's maintenance work.
He goes on to make some good points about the current implementation, and where it falls short. His experience with it involved Lion quitting an app while he was still using it, causing him surprise and frustration. For an inexperienced user, having an app suddenly disappear from the Dock would certainly cause confusion, and probably lead the user to think the app has crashed.
But then Neuburg reaches what I think is the nut of his argument [emphasis mine]:
Moreover, there’s a larger question at stake: Who, precisely, is in charge? I think it should be me, but Lion disagrees — and not in this respect alone. Automatic Termination is merely one aspect of an overall “nanny state” philosophy characteristic of Lion, and one which I find objectionable. When I tell an application to run, I mean it to run, until I tell it to quit; Lion thinks it knows better, and terminates the application for me. Conversely, when I tell an application to quit, I mean it to quit; but again, Lion thinks it knows better, restoring the application’s windows when the application launches again, and relaunching the application if I restart the computer. By the same token, when I tell an application to save, I expect it to save, and when I don’t tell an application to save, I expect it not to save; again, Lion wants to abolish a distinction and a choice that I think should be up to me.
This is where I disagree almost fully. It is an operating system's job to not only manage system resources efficiently, but also to service the user of the machine. By doing so, it's supposed to alleviate all the stresses and friction involved in owning a computer. It's hard to imagine as power users, but for average users, the task of remembering which apps are running and which are quit is tedious, arduous, and at times seemingly sisyphean. It's difficult for them, and it's not because they're stupid. It's because system designers have thus far been stupid, and have not catered to the needs of an average human computer user. When all the windows of an app are gone, so too should be the window as far as the user is concerned. The user shouldn't have to know the difference between “an app without windows” and “an app which has been quit”.
Apple is finally catching OS X up to the standards of iOS, and it's going to be a bumpy transition. The current implementation in Lion is not perfect. It ought to be more transparent, and the app shouldn't disappear just because it falls into App Purgatory (it should instead faking being active; a slight delay while it springs back to life has been shown to be nearly imperceptible to users. See Jef Raskin's The Humane Interface for more).
OS X brings with it decades of operating systems catering to computers instead of humans, and it's about time this reversed. Lion is the first step in this direction.