The Stockholm syndrome is part of the workflow
Longtime Mac users do not stop noticing the weirdness. They just build muscle memory around it. They know which permission dialog matters, which one is lying, which folder is real, which folder is a bundle, which Xcode setting secretly owns the file, and which “simple” fix requires restarting the app, the terminal, the simulator, the daemon, or their entire personality.
That is the great Mac trick. macOS does not remove complexity. It moves complexity behind frosted glass and gives it better typography. Normal users experience this as elegance. Power users experience it as a maze with rounded corners.
This is why arguing about Macs gets weird. A Mac fan says, “It just works.” A developer says, “It just works after you learn the twelve things you are never supposed to touch.” Both people are telling the truth. They are just standing in different rooms of the same very expensive house.
Finder is not the source of truth
On most computers, a file is a file. On a Mac, a file may be a file, a package, a bundle, an alias, a sandboxed resource, a quarantined download, a Finder illusion, or something Xcode can see but refuses to build.
This is where power users start to lose trust. Finder says the file exists. Terminal says the file exists. Xcode may still behave as if the file wandered in without a badge. Apple’s own Xcode documentation separates adding files as groups from adding folders, because Xcode’s Project navigator is not simply a mirror of the filesystem. It can create project structures that match disk folders, or it can create groups that differ from the directory structure on disk.
That distinction sounds harmless until you are debugging it at 1:00 a.m. A Swift file can be sitting in the correct folder and still not compile because it was not added to the right target. An asset can exist in Finder but fail to land in the app bundle. A resource can be visible in the sidebar but absent from the final product. The file is there. The Mac is simply asking a more insulting question: there according to whom?
Xcode is where normal file logic goes to be humbled
Xcode deserves its own circle of this particular hell. It is not just an editor. It is a project database, build system frontend, signing machine, simulator wrangler, debugger, package resolver, and emotional endurance test wearing one icon.
The classic Xcode problem is that the thing on disk and the thing in the project are not always the same thing. Apple documents target membership and build phases for a reason: files must belong to the right target, and resources often need to be copied through the correct build phase. That is technically reasonable. It is also the reason a new developer can add a file, see the file, commit the file, and still ship a build that acts like the file never existed.
Then there is the project file. The .xcodeproj looks like one clean item in Finder, but it is a directory bundle containing project metadata. The famous project.pbxproj inside can turn small UI changes into noisy Git diffs. Longtime Mac developers learn to treat it like a haunted filing cabinet: useful, necessary, and one bad merge away from ruining lunch.
This is the core Mac power-user problem in miniature. Apple wants the interface to feel simple, so the complexity gets stored somewhere else. That somewhere else is often exactly where developers live.
Security is great until you are the person being protected from yourself
macOS security is not fake. Gatekeeper, notarization, sandboxing, app permissions, Full Disk Access, Files and Folders controls, Automation, Accessibility, and Developer Tools permissions all exist for real reasons. Apple’s Gatekeeper checks apps from outside the App Store, and macOS lets users control which apps can access protected folders like Desktop, Documents, and Downloads.
The problem is that power users often experience these protections as scattered veto points. Terminal can access a folder, but VS Code cannot. VS Code can access it, but the helper process cannot. Xcode can build, but a script launched by Xcode cannot see the same environment. A sandboxed app can open a user-selected file, but persistent access may require security-scoped bookmarks. Every layer is defensible in isolation. Together, they feel like a committee of tiny security guards arguing over a clipboard.
The most maddening part is that the user already thinks permission was granted. They clicked OK. They authenticated. They dragged the file in. They opened the folder. But macOS permissions are often per app, per location, per capability, per launch context. The human granted permission. The system wanted a more specific confession.
The command line is Unix until Apple says it is Apple
One of the reasons developers like Macs is that the command line feels familiar. You get a Unix-like environment, good terminals, Homebrew, Git, SSH, shells, and a machine that can develop iOS apps while still feeling comfortable for web and backend work. That is the good version.
The bad version appears when Apple’s developer tooling becomes global state. The active developer directory selected by xcode-select affects tools such as xcrun, xcodebuild, compilers, and build chains. The DEVELOPER_DIR environment variable can override that selection per process. That is powerful. It is also why Terminal, Xcode, Homebrew, Node, Python packages, React Native, Flutter, and CI can appear to disagree about whether the same machine is ready to build software.
Windows accumulates complexity. Linux exposes complexity. macOS hides complexity until it becomes a build error.
Finder treats power users like guests in their own filesystem
Finder is fine for opening documents. It is less fine when you are treating the filesystem as an instrument panel. Paths are secondary. Hidden files are hidden a little too enthusiastically. Bundles pretend to be files. Network volumes, aliases, symlinks, package contents, iCloud syncing, and permission prompts all blur together into a user interface that wants you to stop asking follow-up questions.
That is not always bad design. It is often good consumer design. Most people do not want their file manager to look like a cockpit. But power users do. Developers especially do. They need to know what is real, what is generated, what is cached, what is ignored, what is linked, and what is merely dressed up in Finder’s Sunday clothes.
This is why a Mac can feel both premium and patronizing. The hardware says “professional.” The file manager sometimes says “let an adult handle this.”
The bugs become culture
This is where Claude’s point lands: longtime Mac users adapt. They do not necessarily approve. They just stop being surprised.
They know to check target membership. They know to give Full Disk Access to the app that launches the script, not only the script itself. They know that a downloaded binary may carry quarantine behavior. They know an app bundle is secretly a folder. They know a keyboard shortcut can be system-wide, app-specific, menu-title-specific, or ignored by an app that does its own thing. They know that deleting DerivedData is not a joke, it is a ritual.
Over time, those workarounds stop feeling like workarounds. They become local customs. New users call them bugs. Veterans call them “how Macs work.” That is not maturity. That is scar tissue with a keyboard shortcut.
To be fair, the Mac is still good
This is the awkward part of any honest “Macs suck” article: Macs also rule at a lot of things. Apple Silicon is fast and efficient. The screens are good. The trackpads are absurdly good. Battery life can be excellent. The Unix-like base is useful. The ecosystem is polished. For iPhone, iPad, and Mac app development, there is no serious substitute for Xcode on macOS.
That is why the complaint has teeth. People are not mad because Macs are useless. They are mad because Macs are useful enough to keep using while being annoying enough to complain about forever. A bad computer gets replaced. A Mac becomes a long-term relationship with unresolved issues.
For a broader comparison of the tradeoffs, Notavello’s best operating system for developers guide puts it simply: Windows accumulates complexity, Linux exposes complexity, and macOS hides complexity. The hiding is what makes the Mac feel magical on a good day and gaslighting on a bad one.
So why do Macs suck?
Macs suck because they are too good at pretending they are simple. They suck because power users need mechanical sympathy, and Apple often gives them aesthetic confidence instead. They suck because the system is full of invisible boundaries: app permissions, project metadata, signing rules, sandbox access, build phases, quarantine state, global toolchain selection, and Finder abstractions.
None of these things are automatically stupid. Many are there because Apple cares about security, consistency, or user experience. But for developers and power users, intention does not erase friction. A locked door can be a safety feature. It can also be the reason you miss your train.
The best one-line review is this: Macs are beautiful machines that teach their most loyal users to tolerate nonsense gracefully.
That is the Mac experience. Elegant surface. Hidden machinery. Excellent hardware. Strange rules. A platform that feels like it respects taste more than control. Longtime users survive by learning the rituals. New users arrive, hit the same walls, and ask why everyone else is acting like this is normal.
The answer is simple. They adapted.