OS X design decisions. Terminate the app on last window close?

27
votes

Unlike Windows, GNOME and most other GUI's, OS X application programs do not all terminate if the main window (or all the windows) of that application are closed.

For example, fire up Firefox, Safari, Word, or most document based apps. Either click the red dot in the corner or type cmdW to close the window. You can see that the menu of that program is still active, and the program is still running. With OS X newbies, sometimes you will see dozens of these windowless zombies running and they wonder why their computer is getting slower.

With some document based programs, there is some sense to not terminating the application if it has no windows. For example, with Safari or Word, you can still type CmdN and get a new document window for whatever that application was designed to do: browse the web (Safari) or type a new document (Word).

Apple is mixed with their design philosophy on this. Some close on the last window closed and some do not. Third party apps are even more mixed.

There are other apps that do close when their red close button is clicked. System Preferences, Dictionary, the Mac App Store, iPhoto and Calculator do terminate when the sole or last window is closed. iCal, Address Book, iTunes, DVD Player do not terminate.

What I find particularly annoying is the applications that do not have a logical "New Document" or "Open" function yet they do not terminate when the document window is closed. Example: fire up iTunes or Address Book and terminate the main window. There sits a zombie with no window and no function other than manually selecting "Quit".

It is easy to close the application after the last window closes. Cocoa even gives you notification of that event. Just add this to your application delegate:

  - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender
{
    return YES;
}

My question is this: Is there any reason I should NOT terminate my application after the last window closes? Why is this so variable on OS X software? Unless the app has a "new" or "open" or some other clearly understood reason to not terminate with no window open, the failure to terminate seems like a bug to me.

3
cocoamacosuser-interface
Why do you say 'they wonder why their computer is getting slower'? An inactive application is using no resources. – Carl Norum
Just a quick note: there is a perfectly sound reason to want to run iTunes windowless, I hope you understand what it is. Address book is weird, though. – Agos
@Carl Norum: "An inactive application is using no resources" That would be news to me. Start a bunch of programs including Terminal. In Terminal, type top Sure looks like those programs are using resources to me! Sure seems to speed things up if I terminate a few programs -- even those that that have not been active for days. As I type this, Photoshop is in the background. I have not had a document open or had it active in days. It is using 5% CPU and 233MB of resident memory. Multiply that by 10 programs sitting there and that is noticeable effect on performance. Am I missing something? – dawg
@Carl: When I have Safari open for a while with many windows, I can close all the windows and it still leaves my mac sluggish. Safari is sometimes eating 500MB or more, with no windows open. This definitely leaves a visible slowness until I actually close Safari, at which point my memory "usage" drops incredibly. – Chris Cooper
@drewk/chris - arguably the using of resources by "inactive" programs is the bug then, not the failure to terminate them when their last window is closed. – Carl Norum

3 Answers

25
votes

Per Apple's Human Interface Guidelines (a guide for Mac developers):

In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window.

3
votes

In general, never close a document based application when the last window closes. The user will expect to be able to open a new document without relaunching the application, and it will confuse them if they can't.

For non-document based applications, you need to consider a few things:

  1. How long does it take for my application to open? If it takes more than a second, you should probably not quit.
  2. Does my application need a window to be useful? If your application can do work without windows, you should not quit.

iTunes doesn't quit because, as Anne mentioned, you don't need a window to play music (question 2). It is also not based on Cocoa, so it is much more difficult to close after the last window, especially since it allows you to open windows for specific playlists so there are an indefinite number of possible windows to be open.

In my opinion, Address Book does not need to stay open. This could be a left-over design decision from older versions of OS X, or it could be that someone at Apple just thought it was better to leave it open (maybe so you can add a contact?). Both iTunes and Address Book provide access to their main interfaces through the Window menu, as well as a keyboard shortcut (Option+Command+1 for iTunes, Command+0 for Address Book).

0
votes

The main iTunes window can be reopened from the 'Window' menu. Mail.app has similar behavior. I can't think of any applications that close when the last window is closed, and as such I don't think there's a good reason that your app should behave that way (in fact, i'm surprised its not in Apple's user experience guidelines, it would really bother me!).

One reason why you'd want to close e.g. the iTunes main window but keep the app open is to be able to use the app as sort of a server for third party scripts/applications. I rarely use the main iTunes interface, but instead control my music with a third party app. I also write AppleScripts for other apps that I launch instead of interacting with that app's interface.