An example is the latest System Preferences. It's virtually unusable.
The latest update added "Stage Manager" or whatever, tried it out for an hour...didn't really like it and turned it off, it never gets in my way trying to force itself on my like Windows does with all of its anti-features.
People complain about system preferences but I use spotlight to find settings when I need them, which works great - and once a setting is set I rarely change it. I don't think I've touched the preferences "app" since I initially setup my mac studio. The moaning and groaning about how bad it is just seems so.....pointless to me.
This is exactly how I do it, and I also do it this way in Ubuntu. And in both OSes, I hide docks/apps.
There exist equivalents that have exactly that same functionality as described above. I don't know what GNOME uses, but KDE's krunner searches system settings, user files and applications, bookmarks, browser tabs, solves arithmetic and unit conversions, does spell checking, searches the web, searches active windows, applications and workspaces, etc.. It's configurable with many plugins available. I expect GNOME's system works similarly.
Have you considered that other people have usage requirements different from yours?
Of course there's not much reason to complain about System Settings if you never use it, but that's missing the point.
You could copy paste your comment to everyone here, "have you considered that other people use it differently".
That's not all the commenter said. "The moaning and groaning about how bad it is just seems so.....pointless to me."
If System Settings is fine for the commenter, that's great for the commenter. (Although "I virtually never use it" isn't exactly a great response to "It's virtually unusable" or a great defense of System Settings.) However, the commenter is criticizing other people for complaining about it, and that's not justified.
For seven years longer and with 20K more ports than Homebrew, and without leaving a mess on your system or munging permissions, so is MacPorts.
There's still some weird annoyances for me, though. For example, it's still intended for single-user mode only. The best solution I came up with was to create a separate user for Homebrew and then basically alias `brew` to `sudo -H -u homebrew brew`.
And generally, if you attempt to use a non-standard prefix, such as in your home directory, packages will have to be built from source. I understand why, but it sucks because this means when you need x86-only packages via Rosetta, you're stuck with the old `/usr/bin` prefix, unless you want to and can build from source.
Also, in general, maintaining multiple prefixes/architectures is annoying too. I wish the default command allowed me to just pass `--arch amd64/arm64` or something when installing packages
Goofy shit like this randomly happens, particularly after OS upgrades. I remember some crazy hell where I couldn't finish the OS install on a new Mac, because Apple decided that Apple IDs must be email addresses, and my ancient ID was not. Required a call to customer support.
And the "untrusted developer" shit always bites me in the ass every couple months or so... It is particularly painful when using pro audio interfaces, which will just suddenly stop working every now and then. It requires a magic key-press during a reboot to clear some kind of special RAM.
So why would it suddenly be a good idea to import this from iOS?
At least Apple managed to move all their settings from one paradigm to the next in one year. I’m looking forward to the improvements they make to the app in the future.
Everything seems to get sacrificed at the altar of Developer Comfort. Performance gets thrown under the bus so we can write everything in JavaScript. Platform-specific features get abandoned or neutered in a cross-platform framework so we only have to target one API. We ship gigs of Docker containers so we don’t have to get our software to work on all the customers’ computers.
This is just another example. Wouldn’t it be great if iOS apps and Mac applications converged on the same thing? Only a developer would want this.
Why would you ever want added cognitive complexity?
If things need to be different then sure. But if they can be unified in a way that works great for both then please do!
Honestly, with their tight integration, I don't even think of watchOS and iOS and macOS as being so separate. They're all just a kind of "appleOS" that gets applied to different form factors. So UX unification is ideal wherever it makes sense.
> and at least it’s consistent with iOS
What a huge win for Mac users.
And search works better than it used to as well. To me it's been entirely improvements.
And thanks to this peculiar way of thinking we also have several layers of UI inconsistencies in Windows, for example. Someone thought "let's unify everything" but, assuming this is a good idea at all, you really need a lot of work, planning, effort, and most of all imagination to make sure the final result is actually an improvement for the users of both mobile and desktop systems rather than being a mediocre one-size-fits-all solution.
This new thing violates much of Apple's own HIG, and despite running Ventura for half a year, I still find myself hunting for things that should be easy to find. Quick: where do you go to turn the volume menubar control on or off?
My response is similar for the other complaints I see here. I can ignore new features I don't like. I've got integration with my phone and watch that took zero effort. No need to waste time on drivers, etc. If I want to run Photoshop I can.
(I've used Macs since the original Mac Plus with one one-year Windows interlude. For servers I use Linux, which is obviously appropriate for that use.)
Most people are familiar with the iOS model already. It's rare to find Mac users who aren't.
The order is seemingly random. You can't reorder, pin favorites, or hide unwanted settings. Many things are buried deep in hierarchies.
Not to mention that iPhone Settings is based on a small, non-resizable window and a touch interface, neither of which are true of the Mac.
Familiar crap is still crap.
Source: Self after working on anti-theft software for macOS, for a few years now.
I can make a command line tool or a standalone Qt application right now without having sandboxing pop up at all.
Even for access that the OS protects the user from, as an app developer I rarely need to think about it. When I try and access a limited area it asks the user for me.
Source: self after working on lots of varied code bases from web dev to 3D libraries and standalone applications for over a decade.
For starters, the UI experience is terrible. You get a dialog telling you you can't install an app; close the dialog then you have to know to go to a certain Settings tab under Privacy & Security, and there will (hopefully) be some text that allows you to enable the app. This is a UI disaster. Maybe they do it so that non-technical users will give up in frustration.
Once MacOS decided that my official Oracle JRE was "untrusted", and I would get the bullshit dialog every time I started a Java process (note: I develop apps using the JVM). I had to google to learn some arcane CLI magic to disable the untrusted bits on my JRE files.
More recently, I couldn't get CIV 6 to run. Instead of telling you what to do, you get a "app is corrupted" dialog (maybe this was the fault of Steam). This required multiple enabling via the magic permissions tab. I mean, are Steam and Firaxis not "trusted developers".
All this pales in comparison to the pain when using my MOTU audio interface. Getting it to work was an enormous pain in the ass thanks to Apple security. And then MacOS would randomly decide to break things every 6-12 months, and getting it to work again requires discovering an arcane NVRAM reset procedure using magic key presses during reboot.
Does 'app from a trusted developer' mean something other than 'app from the app store, or from someone you've specifically allowlisted'?
They don’t necessarily need to be from the App Store, but they do need to be notarized.
If they’re not, the warning can be bypassed.