I think the author is quick to understate the benefits and overdramatize the change.
First of all, he dismisses the performance benefits, but frankly why am I even running the application if it's unused and in swap? Expunging it from memory with application-level semantics is a potential win because it can theoretically prevent you from ever hitting swap even after using hundreds of apps over the course of weeks or months. If you have an app with bad memory management this could be more than a trivial win.
As to the UX question, Apple is trying to push the envelope and say there is a better way to interact with a computer. Much like the auto-save stuff, Apple is re-examining quarter-century-old paradigms that geeks take for granted, but are perhaps not necessary in today's world of computers that are thousands of times more powerful. Now it may be that this they are overstepping and this is creating real usability problems, but it seems more likely to me that a good portion of computer geeks are simply uncomfortable with any change to assumptions they've had for the majority of their lifetime in computing.
I agree on a technical level, but the UX change is non-trivial. In fact, it violates an implicit promise of the UI: the Dock shows you all the applications you've opened. Maybe techies like us understand that the app was closed to save resources, and it's a mere annoyance to re-open. But to all the "moms" out there, it's just broken: they opened it so they can use it, and now it's not there anymore. This makes the OS feel broken, which makes the computer feel broken.
There's no reason not to leave an entry in the Dock so as to maintain the user's expectations, while still recouping background resources as needed.
It's been my experience that all the "moms" aren't the ones opening an application, closing all the windows, and then sometime later expecting that application to be there so they can command-tab to it. Instead I see a million apps left running on the dock because they clicked the red button on the window when they were done with the app.
This times 1,000. Mom's don't use alt+tab. The thing people aren't appreciating is that when you reopen the app (which is available via Mission Control, via Spotlight, via the Finder or perhaps via the Dock), it restores to the place it was when it was left (if there were windows open).
I strongly disagree. There are a strong contingent of clueless power users out there: people who don't know a lot about computers (and don't want to), but who still use them for many different tasks, every day. And these users do so by forming familiar habits. And while some of these habits are bound to be broken by new OS releases, I don't think it should be done lightly. This may be a small issue, but I still think it was a poor design choice.
My aunt is kind of like this. She projects an air of knowing absolutely nothing about computers and mild distaste for them, and yet she's the most capable non-techie I know, and has occasionally been known to drop phrases like "PCI bus" in conversation.
She used to be a typist and a stenographer, so you're probably right about the forming habits key.
I've been unsuccessfully trying to educate my wife about this behavior for years! The windows model of "app closes with last window" seems to be too far ingrained in her to change.
Apple’s current implementation certainly is dodgy but I think the ultimate goal is very desirable. Whenever I explain the difference between quitting and closing a window on OS X to someone their eyes glaze over (even when I ignore all the inconsistencies). It’s just something no casual user understands. Nobody has the same problem when using iOS.
The transition period will be rocky and the UI in OS X is currently still very much optimized for the old model but I think Apple is walking in the right direction.
I guess I would actually like all apps to quit on close. Apps that need it should be able to run in the background (sans any indicator that they are still running).
If all apps auto save and restore their state only very few apps actually need to run in the background: mail clients, music players, RSS readers, …
The dock could then show all apps with open windows (including hidden or minimized open windows) and Cmd-Tab could show recently used apps (including apps that are not running).
For this to work seamlessly all apps need to be able to auto save and restore state and all apps need to be sane about whether or not they need to run in the background. That’s certainly a daunting task and it’s understandable why Apple can’t (and won’t?) jump right to that.
Definitely all kinds of promises are being broken. Bottom line is that the Dock / Mission Control / Command-Tab / LaunchPad are a mess of mixed metaphors right now. As far as my mom is concerned though, she has no idea what is running or not. In fact, the Windows paradigm of closing the last window is more akin to her expectations even though she has never in her life used Windows.
I think non-techies were already quite confused by open applications with no visible Windows. It confused me when I first used a Mac, and I like to think I know what I'm doing.
I think the problem that most people have who are upset about this change is that they're actually using the dock and cmd-tab to switch between applications. Using an app launcher like alfred makes the concern trivial, as switching to an app and launching it use essentially the same action. In that sense, this auto quitting feature is actually a nice compliment to that type of workflow.
That's a ridiculous statement. Using Alt-Tab isn't my 'problem', it's a very efficient way to cycle between a few apps in heavy use.
In general I appreciate Lion's approach to quitting/restoring things, but they have messed up the associated Dock and Alt-Tab behaviour. I wouldn't be surprised to see this fixed in an update.
I think Apple has been backing away from that "promise" for a while now. Remember in Snow Leopard (or maybe it was Leopard?) when they disabled that white dot that used to show beneath running apps? That made it very hard to tell which apps were actually running, vs just docked in your Finder for easy access. I know a lot of people went and updated some plist to revert to the old behavior (I did, and also did so for my wife's computer). But it seems like that might have been an intentional move on Apple's part to make it less obvious which apps are running.
It wasn't even in Lion. They just added an option to disable the white dot in the Dock preference pane at some point. It's in Lion, but I don't remember when they added it, so it could have been there for a while (and I _know_ it's been disable able by plist since at least Leopard, probably since Cheetah/10.0).
It toggles your dock between 3D and 2D. The 3D setting still has the dots, but they're very hard to see. So I was wrong about them disappearing entirely, but that's the change I was referring to.
If you still have the 2D look in Lion perhaps you ran this command previously under Leopard? I did, and the setting survived my upgrade to Lion, so I still have the 2D enabled.
Ah, I only started using a Mac with 10.5 - the 3D dock with the faint dots is the only one I've ever known. It took me a while to notice the dots and realize what they mean.
Huh. I must have missed something. Through Leopard, Snow Leopard, and now Lion, I've never not seen that dot, and I certainly never changed any plists to accomplish that.
When I said "might have been an intentional move on Apple's part to make it less obvious which apps are running" I meant nothing nefarious on Apple's part.
Rather that they seem to be heading in a direction where they want the user to not be concerned with whether a particular app is running or not- just click on it, and it will pop up in the state you last left it, whether it was actually running or not. Just like (many apps) on iOS.
My question is why not just leave it pretending to be opened, then open it when you select it? Leave the dot on the dock, leave it in the alt+tab list, but don't actually have the process running. This seems like what they are actually trying to achieve: you remove all actual strain on the computer without breaking any promises.
> Expunging it from memory with application-level semantics is a potential win because it can theoretically prevent you from ever hitting swap even after using hundreds of apps over the course of weeks or months.
Other than saving some disk space, how is hitting swap to page an unused app back in significantly different from loading the app from memory again?
This is a double-edged sword. On one hand, maybe it has saved you from some memory leaks. On the other hand, maybe it has cleared the infinite undo stack in your 3d modeling program.
Granted, you can always fall back on the argument that if developers support the APIs correctly, this isn't an issue, but that is putting a lot more trust in developers than is warranted based on historical evidence.
IME the Xbox 360/Xbox Live method of just building features into the system always wins out vs the PS3/PSN method of expecting developers to support the available APIs and do the right thing. In that context, I think just allowing virtual memory to do what it has always done is the better way to go.
Several times now, I've accidentally Cmd+Q'd Chrome because I didn't realize that TextEdit or Preview was no longer the application in focus.
This happens mostly if I just closed the last of the application windows, and accidentally expose'd the windows back and forth. If you "Show Desktop" and then bring the windows back, TextEdit and Preview will now be closed.
I don't think I like it, but it might just be a matter of retraining myself.
This just yet another reason that I haven't switched to Lion yet. I don't WANT to think about this stuff. I want to think about editing some text, then getting back to XCode.
Don't add some non-deterministic 'feature' that messes up my model of where my apps are. If you must quit an app to recover resources, do it whilst pretending that the app is still running, because that's my model.
Perhaps, in regularly cmd-tabbing to running but documentless applications, I am some kind of uber edge (head) case, but I suspect not.
Let me know if this is too pedantic, because I might just not be familiar with this particular usage, but calling this behavior "non-deterministic" seems like an abuse of the term.
From what I understand, it can't be predicted by the user -- it depends on factors such as application's memory image size, system load, idle time, etc.
As a user, I don't know when the app will go away.
Unrelated, but in some of the more recent builds of Chrome, you can have Chrome warn you whenever you hit Cmd+Q to then have you hold the shortcut down to confirm quitting. It's saved me loads of frustration on more than a few occasions.
I've never understood the "no open windows but still running" model of OS X. In some ways, this makes more sense, but it also makes it more confusing, since you don't know what state the application will be in when you try to get back to it.
What I really wonder, though, is why leave it running at all if you're just going to kill it later? Seems to me they should have just changed the model to quit the application when the last window is closed, unless the application tells the OS not to.
Time travel back to 1984. If you quit MacWrite, it takes ten seconds or more before the Finder appears (the Finder, of course, wasn't running; there simply wasn't enough RAM to do that) If you now double-click a document, it takes ten seconds or more before MacWrite has started and opened your document.
MacWrite, being a marvel of tight engineering, manages to handle documents of a whopping two to three pages in the 40 kB or so of RAM available to it. So, if you want to write a huge document of say four pages, you have to split it into smaller parts.
If MacWrite quit when you closed its only window, moving from part 1 to part 2 of your document would take over a minute. That is why document-based Mac applications do not quit when you close the last document.
Back in 2011, many people will expect that command-W, command-N will close the current document, then create a blank new one. If Mac OS X Lion quit applications as soon as the user closed the last window, that would no longer work. That, I guess, is the reason that the OS waits for a while before doing that.
Is that a good idea? I think quitting apps is a good idea, as long as the OS manages to completely hide it from the user. Apparently, the current behavior isn't good enough, as it annoys some people a lot. On the other hand, it may just be a matter of getting used to the change.
That's why I specifically called out OS X. In 1984, that model made a lot of sense. But sometime during the next 17 years, computers got powerful enough that the reason doesn't really make sense anymore, and we fall back to "because people are used to it".
But it's clear from Lion that Apple doesn't really care what you're used to. We've had scrolling mice for about as long as we've had OS X, yet they chose to reverse it's function in Lion because, after entering the age of touch-screen devices, they realized the old model was wrong.
I just think it's a little odd for them to implement a half-way solution like this.
I wasn't aware you knew the history. I find it odd, too, but i can think of à reasonable reason for doing this. Good apps without anything to do will not use CPU time, so the only concern is swap space. That, I think, must be the reason for implementing this: on SSD systems, swap space can be scarce (hm, there may even be hardware in the pipeline where it is even scarcer)
I do look forward to a better solution, though. The days of the "Quit" menu item are numbered. Longer term, I think we should get rid of File-Open, too, bring back Lisa-like Stationary documents, and remove File-New.
And launching MacWrite in 10 seconds was the best case imaginable. Software like MS Word or Netscape Communicator took several minutes to launch on consumer Mac hardware through the 1990s. The early versions of OS X completely exhausted lower-end G3/G4 hardware -- Everything beachballed for at least few seconds, and not even TextEdit launched instantly. There's a reason that every Mac/Windows app had those "Are you sure you want to Quit?" dialogs ... Quitting was very very expensive if you didn't mean it.
Launching small apps like TextEdit didn't really become "effortless" until the Intel era, which really didn't start that long ago.
> I've never understood the "no open windows but still running" model
Here's a very specific use case that comes up all the time (for me, but I think it's more general too) where this model is superior: I have a folder-ful of files that I need to go through one-by-one. In my case it's usually assignments my students have handed in. What I want to do is open the first one, then Cmd-W Cmd-O and look at the next one, and so on. What I have to do if I'm unlucky enough to be on a windows machine is open the first one, look at it, open the second, click or Ctrl-Tab to the first, close it, and then look at the second. This is excruciating. Alternatively, I could keep one dummy file (or perhaps just the first one) open while I sequence through the rest. This is also annoying.
This is roughly the same reason (or one of them, anyway) that I also like the screen-wide menubar: at least some actions are relevant to the program, not to the document, and there's no reason that I should need a document open to execute those actions.
If you're not editing the files, can't you just use Quicklook to basically navigate through them iteratively and intuitively? I've added plugins to support php and java. (IIRC from here: http://www.quicklookplugins.com/ )
You could have a 2nd app like a spreadsheet for "scoring"... in fact this is what I did when I'm reviewed resumes for new hires.
Historically, most applications supporting multiple files would have used MDI interface, which is perfectly happy having just a window with no documents open (the equivalent of a Mac app with no windows open). Normally, this window has nothing but a menu bar, and perhaps a toolbar.
But for single-document applications, what I do (on Windows, running Cygwin), is roughly this:
for f in *.your-file-ext; do cygstart --wait "$f"; done
That'll iterate through each of the files in sequence, opening them up in the application registered for that file type, and wait until the application is closed for each file.
If some action is required, I might stick a 'read' in to that ad-hoc script.
(Disclaimer: I contributed the --wait flag to cygstart for just this kind of task.)
Computer resources are so cheap that the idea that, for most user applications, the openness of an application is a "state" should be obsolete. For apps that start up quickly and auto-save, why should the user care if they're open or not? The desktop is just playing catchup.
The only loss is that you can't tab between applications without paying attention, but I suspect that many users don't do this anyway.
If they're going this route, then the user shouldn't be able to tell that an application has been closed behind their back. The application should just be restored when they try to switch back to it.
If the openness of an application should be obsolete, then the user shouldn't be able to tell without explicitly poking through 'ps'
They actually did this, with hiding indicators on the dock by default, but then reverted it in the final GMs. It's definitely the direction they are going in, but it was probably deemed too radical a change for this release. Maybe in 10.8
That's the idea, but when it interrupts the user's workflow, something went wrong in the execution. I care that the program that I am using is open! But Lion pretends to know which apps I am not using and closes them.
A few things happen with an "open" program, like the ability to command-tab through them, appearing in the dock, expecting a window to be in a certain place, showing up in the "Force quit" dialog, etc.
If the user expects to to find an app in the dock, and it's not there, then the user does care if the application is open.
A feature like this doesn't matter as much on an iOS device because of the way applications are launched & managed. Applications are launched and managed differently on the desktop though...
Computer resources are only cheap if you don't care about energy preservation. I think Apple are trying to maximize battery life, as well as taking OS X to iOS levels of user friendliness.
So glad that Apple is finally at least trying to make some smart decisions around this. I can't tell you how many times I've gone to troubleshoot something on a friend's computer and they have about 20 apps "open" and no windows. Of course, when I ask why they have so many apps open, they have no idea what I'm talking about.
Since most apps don't implement "close when the last window closes" Apple is simply trying to do some smart checking for the sake of these users.
Except that this problem only existed on OS X to begin with - Linux and Windows never seemed to have it. Seems they manage to ensure that closing the last Window closes an app. The Lion way seems worse than the non-Apple way to me.
If the argument is really "today's computers have enough resources", then apps should maybe never close, not do a Heisenclose in the background.
There are two seemingly opposite behaviors in Lion:
1. Application without a process: if an application has one or more open documents but no documents visible on screen, the app may terminate itself when resources are low. The applications still appears to be alive in the dock and command+tab menu, but its process has been terminated and is no longer consuming resources. When you command+tab back to the application it restarts itself and restores its previous state.
2. Process without an application: if an application has no open documents it will appear to quit automatically and is removed from the Dock and command+tab menu. In actuality, it remains running in the background ready to spring into action again.
The question is, why support behavior #2 at all?
Behavior #1 covers the automatic resource management and I think it works well (and unlike iOS, Mac applications can opt-out of this behavior). Behavior #2 seems to be aimed at Windows users who have no concept of "Quit", but it only aggravates long-time Mac users with zero actual benefit with respect to resource management. It has nothing to do with iOS and everything to do with grandma Windows users who just bought their first MacBook.
#2: Any headless process that's scanning, or performing a behind-the-scenes operation. And note, it's window not application. Because an application could reliably stay open without a window… until now.
Mail.
File Transfers.
Staying available for chat.
Rendering process that can run headless. (Handbrake, I think, plus others.)
Applications that appear to quit are essentially suspended; they consume RAM but not CPU and cannot do work in the background.
If an application needs to do work in the background then it is not subject to automatic termination by either behavior #1 or behavior #2 and simply remains running.
This is interesting to me because I've become obsessed with the idea of running a 10W, ARM-based system headless, that serves webpages (i.e. HTTP) with the requested data via my LAN. You can leave something like that on all the time, and have instant-on for your higher power devices with displays and such.
Remember that an application has to support the sudden termination API, and indicate to the OS that it can be safely shutdown, in order to actually have this condition apply.
If you make no changes to your application, then the OS won't touch it. And if you do decide to support sudden termination, then hopefully you would call disableSuddenTermination before starting any background file transfers, renderings, etc.
Applications that are terminated shouldn't disappear from mission control or any other aspect of the GUI.
However, the user should have some control over what to show in mission control and elsewhere -- namely the k most recently accessed applications (whether or not they are running).
This will be wonderful for new Mac users, Windows-to-Mac switchers and other non-technical people on a Mac. Countless times I have been asked to fix customers' aging systems only to find that nearly all applications in the Adobe Creative Suite were running simultaneously with 1GB of RAM, that kind of thing. And plenty of other apps on the side. This step might be very helpful to these users who don't actively manage resources or expect an app to quit when they close the last window (as is customary in Windows operating systems).
I mostly use my MBP for Java, Lisp, and Ruby development and I like Lion, after about 10 days with it. Reopening applications where they were before seemed lame at first, now I like it. Same for showing the last bit of text in Terminal windows.
One thing that I really like is FileVault 2. I have a lot of sensitive data for several clients on my laptop (SSH keys set up for their servers, AWS credentials, proprietary materials, etc.) and I used to go through a tortuous process of having encrypted file volumes that I had symbolic links to files on the volumes. I wasted a good 3 or 4 minutes a day with this. I set up FileVault 2 and encrypted all of the external disks that I rotate for TimeMachine backups (I tend to use one for a few days, switch to another, keep rotating), and now I just keep everything on my permanent disk partition. One hassle: I lost my time Machine "history" because the conversion process to encrypted external disks requires a reformat; I thought that it was worth it.
I've been using Lion since the early DP releases and I've never had auto-termination kick in. I tend to leave apps open for very long periods of time. GarageBand has been running for at least 2 weeks and it's still running. I know it's been at least a week since I used it last. This machine has a lot of RAM so possibly it's working off the amount of free memory available? If so that seems like a smart feature to me. If you have 8-12GB of RAM you'll probably never see auto-termination in action. If you have 4GB you'll see it now and again. If you have 2GB you'll see it a lot but your machine will likely be running much better. On my old MacBook Air with 2GB the first thing I did when it got bogged down was to quit unused applications so...
The obvious fix for auto-close is to make applications close immediately when, and only when, the last window is closed. Then the user can associate it with an action they took. But the business of closing apps because windows are minimized is just creepy.
As to auto-save, get over it. I never want to lose another hour of work because I haven't saved and a damn app crashes or hangs. The model that Google Docs uses works for me. It auto-saves periodically (the saved state is visible at all times) and the user can save more often if desired. But it would be fine with me if Lion somehow managed to save continuously (and performantly) and take Save out of my vocabulary.
This has pretty much always been the Apple philosophy. I find it quite perplexing that he thinks this style of treating the user is reminiscent of Microsoft; on the contrary, Apple thinks Microsoft gives the user hassle by leaving them with too many pointless choices to make.
I don't find Apple's perspective objectionable in principle, though I do prefer Microsoft's approach. Most novice users will generally prefer Apple's; whether that's the case in this specific instance is an open question, however. I'll bet most users don't even have a clear mental model of a document editing application distinct from the documents it's editing.
I know the dock was supposed to do away with indicator lights right up until the retail release itself. The message is clear: don't worry about what's running or not. Apple went back on it at the last minute, apparently.
Before upgrading to Lion I kept everything closed but my active windows. But I decided to turn off the dock indicators as an experiment and I have to say, my experience has improved drastically. I don't close things anymore, and I don't worry anymore. For example, opening iTunes, which I do about daily, is no longer a ten-second wait, which is actually kind of soothing.
Personally I think that the changes in the new OS is made mostly for the general user, but this has lead to a really weird RAM distribution. The load-times has doubled and it's not as quick on the regular tasks either.
Spaces: Gone
If you have a lot of different windows up at the same time, its impossible to use. Its impossible to scatter the windows and find the window you're actually looking for.
Other than these small shifts: I'm all good with the new OS. As I'm not a power-user I can't see any fault in a 3sec load time instead of 1-2sec.
Heavy use of virtual memory and swap doesn't make sense when your only storage device is NAND flash. Killing and restarting unused processes makes sense when you are shipping devices with low amounts of SDRAM but fast disks and processors. So these features aren't built for your macbook pro with 8gb and magnetic disk, they're built for your macbook air with 2gb and SSD.
I'm 90% sure I read this is an new API feature of Lion. I'm sure I read this when looking into how the sandboxing was designed to work.
If I remembering correctly you can choose to make available an autokill flag for the system. From (my) memory you can control it programmatically... so if you say "no windows open and been alive for 10 minutes with no state change" then kill me.
One other annoying quirk of automatic termination is when you need to install software that requires other applications to be closed first. I needed to install Office yesterday, and it asked me to close Chrome first. The installler wouldn't actually close until I force closed Chrome from Activity Monitor. OK for me as a dev, but fails the grandma test
Surely there should be a preference to disable this behavior. I suppose there's not. There's a use case here were things are better left to the user. I hate it when software thinks it knows more than I do and thinks it's brighter than I am. I haven't switched to Lion yet and frankly, I'm don't think I'll do soon.
To me, this is no where as big an issue as not being able to copy files and skip the ones already present, which I was able to do in Leopard and Snow Leopard, but apparently I no longer should ever need to do in Lion. Thanks Apple.
Dear Apple: please make "dead" apps continue to show up in the application switcher. If I kill it, fine, remove it from the switcher, but if I dont kill it, then it should still appear to be alive, even if its process has been killed.
Using TextEditor on Lion is a frustration and exercise in patience. Every time I want to start it and just type a quick note... I have to wait as it's disappeared or it's restoring previous windows. Sometimes it even gets in a weird state where it thinks a document is open, but it's not, so attempting to open it results in TextEdit being given focus, but not opening the document in question.
Lion's TextEdit also takes > 10 seconds to pop up on my brand new mac with an SSD. Fortunately, Snow Leopard's TextEdit.app still works, and is just as snappy as ever, if you still have a copy. Hopefully they'll fix this in the .1 update...
Wow. I would say TextEdit is one of the applications that really shines in Lion.
I can quit it, it saves everything, including my temporary copy/paste buffer, -no questions asked, - and restores everything when I reopen it. Also search is improved and a whole lot more keyboard-friendly. (I'm using a couple of years old MBP, but with SSD.)
First of all, he dismisses the performance benefits, but frankly why am I even running the application if it's unused and in swap? Expunging it from memory with application-level semantics is a potential win because it can theoretically prevent you from ever hitting swap even after using hundreds of apps over the course of weeks or months. If you have an app with bad memory management this could be more than a trivial win.
As to the UX question, Apple is trying to push the envelope and say there is a better way to interact with a computer. Much like the auto-save stuff, Apple is re-examining quarter-century-old paradigms that geeks take for granted, but are perhaps not necessary in today's world of computers that are thousands of times more powerful. Now it may be that this they are overstepping and this is creating real usability problems, but it seems more likely to me that a good portion of computer geeks are simply uncomfortable with any change to assumptions they've had for the majority of their lifetime in computing.