> Apps Remain Running (and Focused) After Being Closed
If you’re complaining about this, you don’t understand Mac OS.
Mac is a multi-window system. Unlike Windows or Linux or BSD, a program can have multiple windows open at once, each window potentially doing vastly different things. That is why that red dot doesn’t actually close the program. It only closes the current window, leaving all other windows - and the program itself - still up and running.
For a multi-window paradigm, this is logical, rational, and expected.
I have a coworker on Windows who leaves an instance of Word open with a blank document at all times because it will lock up for a minute or two while launching the first instance. One you have the first window open, new windows with additional documents open much faster. It’s like he’s reinvented the Mac application/window paradigm, except worse because his placeholder window is always present in the alt-tab switcher.
Really, most of the content in the article is horribly contrived complaints. The "Informational Redundancy" screenshot shows at least two UI elements that are hidden by default. The complaint about how quitting the Finder makes desktop icons disappear misleadingly neglects to mention whatever hacks he had to use to get the Quit action to show up in the menu in the first place, because it's not available by default for precisely this reason. This guy is putting real effort into misrepresenting the stuff he's complaining about.
The Apple docs suggest to app developers that when closing the last window, the app should be made to close automatically. This is almost certainly what the user wants, unless you have a reason to think otherwise.
For example, as per my other comment, if I have restore tabs in my browser, I expect the tabs of the last open window to always be restored. Instead of this being a suggestion, it should be the default, and the developer should have to configure when they want the last window to NOT close the app. (Even Apple's Safari suffers from this!)
Also, Win has a dock for "background" apps which are always open, accessible, but not in the toolbar of open apps. Apple has a menubar, that similarly allows docking of those apps that are open without a window. My rule of thumb - if you don't think the app belongs in the menu, you want it to close when the last window closes. And if Apple had a "minimize to menu" that might be useful.
Where is it written? And if so, why do the most Apple applications that use multi-window setup do not behave as such, like Safari, TextEdit, Xcode, and many others?
It only makes sense to close the application immediately when the red button is pressed if the application is designed for a single window, or if it's not a document based app. Like the Calculator.app.
Keeping the application running when all windows are closed has huge performance benefits, allows opening another window much faster, and arguably one of the best aspects of macOS.
This is entirely contrary to how the Macintosh has worked for decades which has also shaped user expectations, and closing the app entirely creates a performance penalty for document-oriented apps. Whenever Apple has experimented with doing it a little different, such as when they added sudden app termination to Lion, it has generally degraded the user experience by running contrary to expectations.
I also second everything in bitigchi’s reply to you.
This was the first thing I learned when I started using a Mac in 2007. I took some years off and ran Windows from 2012 to 2021 and never forgot this aspect of Mac.
I don't know, maybe I'm not enough of a power user (I use my MacBook Air primarily as a laptop, rarely hook it up to an external monitor or use a separate keyboard or mouse), but I just don't encounter of these "problems," or I've gotten used to them.
Trying to exit one of those windowless programs on Windows at least, can be rather hidden functionality, and may involve resorting to the task manager. On mac OS, by default it's in the dock if it's open, it's cycled through with command-tab, and once you bring it to the front, you have the menu bar as a uniform interface for interacting with windowless apps. I don't even use mac OS but on this aspect it does seem more consistent.
Menu Item apps (analogous to Windows task bar apps) usually aren’t in the Dock when they are running. You normally don’t quit then via the menu bar (File Edit).
Nor are launchagent processes.
So I’m not sure how you are trying to contrast macOS here.
1. You’re not supposed to quit Finder.app. Unless you customise macOS somehow, the ability to do so is carefully hidden. There’s no menu item to quit it, Cmd-Q does nothing, and even the Force Quit menu has “Relaunch” for Finder rather than Force Quit. Any weirdness you might encounter from quitting Finder is entirely your own fault.
2. There’s a long history behind some of these things. macOS UI conventions stretch all the way back to macOS 1.0, released in 1984. Apple has preserved much of the behaviour of older versions of macOS, like keyboard short cuts and (some) of the spatial behaviour of the Finder. It might not be to your taste, but other long-time Mac users enjoy them. If you don’t like the spatial-ness, the Finder’s column view might be more to your liking.
3. Speaking of taste, many of these gripes are just complaining that macOS doesn’t work like other operating systems. If you want your OS to work like Windows, maybe just use Windows?
You think the Enter key should open things in Finder? Long time Mac users would be incensed if Apple changed this, because we’re used to using Enter to rename things, and Cmd-O if we want to open them.
Window zoom not making sense to you doesn’t mean it doesn’t make sense to other people.
There certainly are some valid points in there, but I certainly hope Apple doesn’t “fix” your other complaints, because that would break conventions we’ve spent decades getting used to.
That first point is especially weird I thought. The author writes: "unlike other DWMs Finder can be killed completely", but I've killed explorer.exe on Windows many times and achieved the same effect as he's getting from killing Finder. I don't know where he's getting this idea that Finder can be killed but Explorer is unkillable.
And yeah, almost everything else is either "it's not Windows" or minor but valid annoyances. A bit disappointing, since there's a lot of big problems to complain about which aren't mentioned.
> Window zoom not making sense to you doesn’t mean it doesn’t make sense to other people.
Could you explain it to me? macOS is not my favourite OS at all, but I can use it without much trouble if I need to and agree that many of these complaints boil down to the author not liking or understanding the macOS workflow. Window zoom, however, always struck me as wildly inconsistent and unpredictable.
For context, I started back in the days of Mac OS X Tiger, up to Catalina. Window zoom never made the slightest amount of sense to me.
Window zoom asks the application to “right-size” their window. The application then gets to decide what the “right” size is. For example, a Finder window will size itself so it can display all the contents of the folder it displays (if possible).
It’s up to the application developer to implement this correctly, so if it is inconsistent, that’s technically not Apple’s fault.
For applications that does not support this, the fallback is just to fill the screen, a bit like maximise does on Windows.
In more recent macOS releases, the new(er) full screen mode works more like maximise does on Windows, and has now taken over the green button on the menu bar for most apps, so the old zoom feature is more obscure than ever.
Thanks, I honestly was not aware that "adjust window to content" is (or used to be) the intended behaviour. I saw apps that did it over the years, but I remember it being inconsistent even from one Apple app to the next.
I also want to say that I remember Apple changing the green button to a maximise-like function, though I can't remember during which release that happened. Probably when they introduced virtual desktops and full screen apps.
Of course, UX guidelines can only do so much without developers following them. That explains why the green button is so unpredictable. You never know if it'll do full screen, resize the window, maximise, or just ignore you.
Well you ought to be able to distinguish “Zoom” and “Full Screen” because the icon within the window control will be a plus symbol if it’s Zoom and two arrows pointing at 10 o’clock and 4 o’clock if it’s full screen. By default it’s full screen now, and you have to hold option to bring the Zoom control up (which since the advent of full screen is inconsistent even in Apple’s own apps).
Double clicking the title bar (in the decreasing amount of empty space in modern Mac OS X chrome) will also net you Zoom functionality without holding option.
Interesting! I don't think I noticed that before. I got used to just doing Cmd+Ctrl+F to do full screen, or manually resize windows. Probably not ideal, but it felt consistent at least.
You missed a nice feature absent in Windows afaik, which is that the last state of the window is remembered and recalled by hitting the green button a second time.
If you want to make this case, you have to make it on a case-by-case basis. It isn’t sufficient to say something is outdated, you have to make the case as to why it is worth changing now.
They got a lot right in the original Macintosh, and they refined what they had a lot throughout the entire Classic and Mac OS X eras.
Well you can replace the USB ports and a headphone jack by "breaking third-party MDM features" if you care THAT much about differentiating between the operating system and hardware (not that you should, because they're the same damn company). MDM features, like USB ports, are way more important that esoteric keybinds from the 1980s.
Those problems "still exist in 2019". Not in 2022. You're running macOS Catalina. (Actually, they don't "still exist in 2019" either).
Yes, files auto-arrange. cmd+J, Sort by: Name, Use as defaults.
Informational redundancy? You went out of your way to activate Show All Tabs which shows the Finder tab bar even with just one tab open, and Show Path Bar which is behaving as expected. Somehow merging the window title & path bar would prevent dragging the window around easily, since the path bar gives you proxy icons you can drag around. And seeing the same folder name in the title bar and the sidebar is good UX. Windows 11 File Explorer has the exact same amount of "repetition", except for tabs which it doesn't support.
Cut and paste is bad for file managers since it requires the file to "disappears" until you paste it. Copy a piece of text off a web page and you've got data loss. And "option" now shows "Copies as Pathname", which is more useful on a UNIX OS than "Move" when you can just drag and drop.
"Open Finder twice" is expected behavior. When an app is open but with no open windows, opening the app again opens a window. This reduces user confusion since it works the exact same as Windows, and is very useful for 3rd party menu-bar-only utilities where you can open their main window (often the settings window) with a half-second Spotlight search.
"Enter" is the most natural choice for renaming since it's an extremely common operation (cmd+R would require 2 key presses) and F2 is used for brightness. Note that modern Windows boxes also put brightness controls on F2, so you need to twist your hand awkwardly to press fn+F2 to rename anything.
The Green button isn't called maximize for a reason. It's meant to show the full document and no more, and is quite useful for Amethyst-without-Amethyst. Hide the "Format and style" sidebar in Pages, and you end up with a huge border around your document. Double tap empty space in the toolbar and the window shrinks to fit the document. Open a Finder folder with 2 lines of files and double tap, the window shrinks to being tall enough to only show those lines, no more. That's useful and works as expected.
Apple's documentation doesn't say Touch ID doesn't put the Mac to sleep. It says it doesn't do so if you press it 1.5 seconds. It does it immediately.
> Cut and paste is bad for file managers since it requires the file to "disappears" until you paste it. Copy a piece of text off a web page and you've got data loss.
What? Is this what happens in MacOS? Because it's definitely not happening in Windows, the cut file does not disappear, it stays until pasted. I can't even fathom that this scenario would be real in any modern OS. File object and text should be handled as separate class of entities and this situation should not occur even theoretically.
> "Enter" is the most natural choice for renaming since it's an extremely common operation (cmd+R would require 2 key presses) and F2 is used for brightness.
??? How often do you rename files vs how often you open them? What is your line of work where file renaming is "extremely common"?
> Note that modern Windows boxes also put brightness controls on F2, so you need to twist your hand awkwardly to press fn+F2 to rename anything.
No, just no. Powerusers (that I know) simply reverse that behaviour to have F-keys behave as original F-keys, the rest just select Rename from context menu.
> What? Is this what happens in MacOS? Because it's definitely not happening in Windows, the cut file does not disappear, it stays until pasted. I can't even fathom that this scenario would be real in any modern OS. File object and text should be handled as separate class of entities and this situation should not occur even theoretically.
Isn't that just move? With a small tweak that involves also deleting the original when moving across drives, rather than keeping it? The author framed cut and paste as completely different from this: "It’s not cut and paste. macOS has copy and disregard-copy-actually-move-instead"
Interesting anyhow. I don't know if Linux has cut-and-paste, but I've used it and Mac for years and never felt a need for this.
And yes, I do rename things frequently, it's a basic filesystem operation.
I think this is a logical approach to pasting. In Windows, for example, if you start by cutting the file, then navigate to where you want to paste it to, and change your mind, deciding you actually want a copy but to keep the original where it is, then you have to start the operation again from the beginning.
With macOS, you can decide whether to `mv` or `cp` just by pressing a modifier in the destination directory.
You rename more than you open files and folders? Not sure why, but I find this concept hilarious.
As someone that uses Windows, Linux (many flavors), and am now using a Mac as my primary daily due to M1 superiority, cut and paste is uniform in how it operates everywhere except mac.
Lots of senseless operations that seem to me amount to being different for the hell of it, because users think they are better and refuse to change. Very basic processes, like manually inputting file paths in Finder, turn into an annoying exercise of remembering instead of intuitive derivation. Everything in a modern OS UX in this day & age should have fundamental design in intuition without muscle memory, as opposed to traditional comforts.
MacOS largely fails in this regard, even though I am highly proficient with it now and greatly appreciate the fact that almost everything “just works”.
I like to so an exercise with software where I imagine I am a little kid or an animal trying to accomplish a task without any prior knowledge. What would be my steps? I think that users should be able to use physical intuition to operate tech, but maybe I am a minority.
It is. From your description I understood that it's the problem with first selecting and cutting a file and then placing it elsewhere. Now I'm not sure what the author is referring to. Have to try it on my Mac later on.
I still think that window management in Macos is not as good as in Windows, plus I still haven't figured out how to select text between current cursor location and the beginning/end of a document. Shift–Command–Dn/Up doesn't work for me. Apple has made some good decisions along the way but getting rid of extra keys (Home/End/PgUp/PgDn/Del) from their laptops is not one of them. Juggling ctrl-alt-cmd-fn combos is just too much.
You can see the problems in the screenshots in the linked article: Files with visible names like "Screen Shot 2021-07...AM.png" and "Screen Shot 2021-0...AM.png" and "Screen Shot 2021-07...AM.png" (again) and "Screen Shot 2021-07...AM.png". The information distinguishing these files from one another has been replaced by the ellipsis.
The same problem exists in iOS. In the Music app, for example, I have playlists in which the list of track titles is something like:
Bach Cantata No. ...
Bach Cantata No. ...
Bach Cantata No. ...
Bach Cantata No. ...
Bach Cantata No. ...
and there’s no way to display the rest of each title. I don’t know how other OSs handle this, but it should be possible to distinguish files from each other at a glance regardless of how long the names are.
Why should an O/S be different from other software? There's no money in fixing bugs or improving performance unless either are so bad that it's a marketing problem. People want features not fixes. Marketeers want features. Developers like new, neat things rather than fixing (hard) problems. And the industry has all sorts of confusion as to what the desktop/deskside things are for. They're not watches or phones. They're way more capable and thus way more complicated. If they didn't need some place to create applications they'd just toss the things.
If's not as if Windows is any better? Haven't they changed the UI paradigm a few times (I'm a mac/linux person)? If so, this is worse than not changing it at all. 50 years on and the damned stuff isn't really easier to use and isn't really any faster unless some thought goes into the development. And it still overtaxes the hardware.
The system has bugs, no question, but few appear in this list. Unlike the author, for instance, I would be annoyed if icons I had arranged a certain way were reordered when I moved them elsewhere. Oh, and he even says it’s possible to get the behavior he wants. The default is less invasive, which makes sense.
Probably this is just a joke, like the famous Steve Martin quip: “those French guys…they have their own word for everything!”. Or perhaps the author considers that “hot garbage” too.
pressing enter to edit a name is exactly how it should be. Enter is for text entry, you type something and press enter to ENTER the text. Why should enter open a program? Reserving Cmd-O for Open is precisely a consistent thing to do, if you're not thinking from Windows' mindset
Well, if I have a directory highlighted ENTER could mean ENTER THE DIRECTORY. Or you hit enter to open the file so you can ENTER its contents. But I'm arguing linguistics, which is stupid.
What is the primary purpose of a file explorer? To find and view a file. It's called 'Finder' not 'Renamer'.
Please tell me a graphical file explorer (and there is probably 100 of them since the dawn of windowed OSs) where ENTER does not open the file that is not Finder. Please tell me one example. Maybe a dedicated file-rename-utility?
If you have a tree of files in an IDE on a sidebar, and you're navigating the tree with arrow keys, and you press Enter. Should it prompt to rename the file or display the source code file you selected?
If you have a image viewer that is showing a grid of image thumbnails and you are navigating them by arrows. You press enter with a thumbnail highlighted. Does it open the image, or prompt you to rename it?
You have selected "Open a file" from practically any GUI app and it displays a File Picker, which is basically what Finder is. As you navigate the grid/listing/whatever, and highlight a choice and hit ENTER, what do you expect to happen?
If you interact with listing or grids or displays of files or objects and have one of them highlighted, and hit ENTER in 99.99% of programs (number made up on the spot by me), does it open/activate/display/expand/select the item, or rename it?
Finder's behavior in this instance doesn't just go against other operating systems' file pickers/navigators, it goes against practically any navigate-items and select-by-pressing-Enter GUI paradigm in virtually every GUI program in existence.
The rename operation is so rare compared to select/open/activate that it is reduced to a hotkey or function key in virtually every other app, OS, and dialog.
You have to think in the context of what a GUI represents at the time. Your assumption was based on the command line ethos, where Enter key plays an important role. It was true on Apple II command line too, but the original Mac interface was designed to do away this keyboard centric mindset. "Use your mouse" was the philosophy behind it. The original Mac keyboard didn't even have arrow keys, it encouraged a novel way of interacting with a machine that is so different to anything before it.
Also, the Enter key that represent so much importance to you, on an Apple machines it's always "Return", which is nothing more than a carriage return, strongly linked to text inputs. A Return key does not "enter" anything. Return and Enter are two completely different keys to the OS. Based on the design choice, Return key deals with text entry, rename is probably the only reasonable text entry function to a file explorer at the time (or even today). This Return vs Enter design choice has been consistently applied on all Apple machine ever since Apple II, which predates any windowed OS you care to mention.
> If you have a tree of files in an IDE on a sidebar, and you're navigating the tree with arrow keys, and you press Enter. Should it prompt to rename the file or display the source code file you selected?
In VSCode for Macintosh, the Enter key in the file panel is for renaming the selected file. This behavior is coherent with the Finder.
Do you perform any file management operations from Spotlight’s search UI outside of the Finder?
Return has a different function in different apps with different paradigms, but the Finder has the longer lineage with the longest set of principles baked into it, treaded upon somewhat with the Mac OS X transition but at least consistent with the compromises that were made in that transition so when you hit Return in the Finder you get a file management function (renaming) because you’re working within a File Manager. Command-O/Double click has always been the way you opened files.
Utilizing unintuitive patterns due entirely to tradition does not justify the practice.
“Enter” both logically and functionally has an intuitive context of “run” or “enter into this object highlighted on screen” within the confines of a file explorer. It is among the largest buttons on the keyboard and its function should be associated with such a presence.
“Rename” is not a rational function bind in any sense — so it is understandable that tradition is the reasoning.
Given how “brave” Apple is to redefine things, like removing a headphone jack or not including chargers, I find it surprising that bravery doesn’t translate to intuitive OS controls contrary to long-held tradition.
What you find is intuitive is only what you learned, and it’s fine to hold that opinion, but it is contrary to what I have learned. For all the criticisms I can and do levy against Apple, not arbitrarily redefining the control scheme that their customers have used for almost 40 years is a mark of respect. Every single keyboard shortcut can be easily redefined to be whatever you want it to be as well, including those of the Finder, through the Keyboard pane in System Preferences. People who find that they can’t get used to hitting Command instead of Control can even just flip the modifier key bindings with ease there on a per Keyboard basis.
Lastly, it’s not “Enter”, that’s actually a separate key binding in some circumstances, but “Return”. Return is a text entry action that typically enters a new line, and by default, begins (and ends) a file rename operation in the Finder; one of the very few functions in which text entry is involved at all in the Finder.
LOL! I love the arbitrary definitions and usage example you give so passionately as if that settles the argument definitively.
Enter could mean, "Begin entering text", sure. But it doesn't. It means "release the block on input", usually passing the text being queued in the input buffer or a pointer to it. Escape has traditionally been the "mode change" button for literally my entire life.
It's wonderful to see Mac fan boys still going though!
it's no more arbitrary than the article's arguments, or your own "Enter could mean, "Begin entering text", sure. But it doesn't. "
Mac fan boys or not, that's just how a Mac works. Calling it inferior just because it's different and then name calling ppl fan boys is just the way to go.
Why did we have to go to Start menu to search for "shutdown" in Windows? To a new user the start menu would be the LAST place she would look for the shutdown command. Start could mean "start the shutdown procedure" sure, but it doesn't.
Idk, having file names be editable like this strikes me as supremely weird, especially coming from a Linux background where we all understand that leaking(well, I suppose implementing here) such functionality isn’t what the user would expect. But again OS X isn’t designed for people like me, so maybe I am just projecting preferences.
If by OS X you meant the GUI, then no OS X wasn't designed for people like you, the original Mac was designed for people who don't want to deal with MS DOS command lines and the GUI design choice have largely been kept intact for almost 40 years. So no you're probably not their target audience. But thank you for allowing for the possibility of preference projection, instead of insisting one way of doing things is inherently superior to another like the others. We don't want everything work the same way otherwise what's the point. To a unix newbie, using mv as a rename function is also extremely strange but to the OG this could well be the most beautiful and efficient implementation.
Author does not understand zoom. Zoom is not supposed to fill the entire available screen, it's supposed to only take whatever the content requires to fill. Zoom is not maximise, never has been. Chrome is the offender here.
My favorite remnants of old Mac OS X are both Finder features enabled by the `defaults` command.
One is slow motion mode. I love to minimize things to the Dock (which is best placed on the right of the screen).
The other is single-window mode. You turn this on and switching apps is just a matter of clicking their dock icons. It’s not 100% perfect but it’s also idea for someone with limited trackpad skill.
I think what we need, is a list of things that macOS does differently to Windows, and explain why it is designed the way it is. So people ( like the Author ) could actually understand why it is done that way. It is not wrong, but different. And many people need to understand why it is different so they get less irritated by its design.
Long time PC/Windows user here - got a 14" M1 pro back in October. Really enjoy MacOS overall, with some minor gripes here and there (like text selection & manipulation - selecting words at a time then copying/pasting is more cumbersome than it is on Windows). Trackpad gestures & Mission Control make for a great single-display experience.
One thing that really bothers me with MacOS though is having to click into a given window to interact with it (e.g. clicking a link in Safari / Edge while you're in VS Code or another window). Not sure there's any way around this.
No way to right click and "Create new Text Document" or Create shortcut or anything like that.
Also, the "closing window doesn't close the app, even when it is the only open window" has a huge side effect. Closing a window with tabs, such as a browser, will delete all tabs, even if they would be restored after close.
More than once, when allowing Win users to use my app they will close a window that I wanted open, thinking they are closing the app. There is a certain logic to it though, solved in Windows by allowing for apps to minimize to the right side of the toolbar.
My least favorite Finder behavior is by default having no scroll bars and allowing files to exist off to the side where they are not displayed and you have zero indication they exist. Like why is this even remotely the default? Why would I even want files to not wrap to the size of the Finder window?
Oh and when Finder won't open a new Finder window because one of those useless "Finder" drag app to Applications folder windows is open despite the fact you can't really find anything with those...
> By default, file icons will preserve their arrangement, which is never what I want.
Tastes clearly differ, because that has always been what I wanted! There is a whole school of thought bemoaning the loss of the "spatial Finder" style prior to OS X, which took this principle even further.
Hahaha, macOS has some issues but not those you talk about. I've heard every windows user complain about such problems - which are not if you accept the fact you are on another Os ant not windows - when starting to use mac. nice clickbait btw.
That's a weird article. I was actually looking forward to some nice intricate OS details. That's just a bad instance of "I'm using the wrong OS and I don't like". Nobody cares bro, just use whatever you want.
macOS isn't perfect, but so what? All GUIs suck, that's a fact of life. Windows is messy and inconsistent, macOS has his own share of issues too, KDE is awesome but has way too many features, GNOME is beautiful but terribly limited, and so on.
The trick is to just pick the one you can tolerate the best.
If you’re complaining about this, you don’t understand Mac OS.
Mac is a multi-window system. Unlike Windows or Linux or BSD, a program can have multiple windows open at once, each window potentially doing vastly different things. That is why that red dot doesn’t actually close the program. It only closes the current window, leaving all other windows - and the program itself - still up and running.
For a multi-window paradigm, this is logical, rational, and expected.