iOS 19 supposedly a huge change

If the YES button is big, colorful, and shaped like a button, but the “NO” button is a text link that differs only from surrounding text by being dark blue instead of black, the developer isn’t doing that in order to be helpful to the user.
For sure. Can you show me an example of Apple doing this?

Edit. Even then I think it would depend on what was being offered. Time Machine backup. One button saying yes and that’s all!
 
For sure. Can you show me an example of Apple doing this?

Edit. Even then I think it would depend on what was being offered. Time Machine backup. One button saying yes and that’s all!
1741900110636.png


The option most clearly demarcated as a button is the Setup Now.
 
Fair play. That definitely fits the description. I still don’t think it’s particularly egregious but I can see I’m in a minority of one here.
I think it looks even worse when you’re not in dark mode? I can’t remember. Also, why is blue text a button, but blue glyphs are not?

Also, people differentiate, in their minds, buttons vs. links. Here it looks like a link because there is another button above the button (“About…”) that has link behavior whereas the button below the button (“Not now”) is really what people think of as a button. The fact that they are both implemented as UIButton’s is beside the point.

Post iOS 7 it’s all just a mess
 
I wonder how people feel if instead of giving a choice where you are being directed in a particular way, the decision is made by the company and you can turn it off? Is that less “dark” or a step further? Much of design is making decisions for the user. Otherwise we end up with Linux.
 
I wonder how people feel if instead of giving a choice where you are being directed in a particular way, the decision is made by the company and you can turn it off? Is that less “dark” or a step further? Much of design is making decisions for the user. Otherwise we end up with Linux.

providing no option is better than trying to trick customers into choosing your preferred option and then pretending they intentionally chose that option
 
providing no option is better than trying to trick customers into choosing your preferred option and then pretending they intentionally chose that option
So my question is, are there any instances in which it’s ok to ”trick” people into making computing decisions or is it always bad?

If I plug my keyboard in and it offers to configure it with a large button “Continue” button and a hidden “no” button, should they not do that?

Edit. By “hidden” I mean as in the screenshot above. Not literally hidden. A poor choice of words.
 
Last edited:
So my question is, are there any instances in which it’s ok to ”trick” people into making computing decisions or is it always bad?

If I plug my keyboard in and it offers to configure it with a large button “Continue” button and a hidden “no” button, should they not do that?

I can’t imagine a good reason to do that. Either just go ahead and configure it, or offer two clear options. What’s the point in offering a hidden button?

Either offer a choice or don’t.

The only reason to hide a button is because you don’t want the user to press it.
 
OK, but unless we have some metric in terms of crashing etc, then as you say it is ultimately subjective. I have been using Macs for a long time, over two decades. It has never been more stable not just from my experience but that of other networks of Macs I’ve managed. I haven’t had a kernel panic in at least 3 years, if not longer. In the early days, and up to say Lion, it wasn’t uncommon to have 2 or 3 a year.
Yeah, but I was mostly talking about the effect of a 2-year release schedule on the quality of the UI design, not the stability. Here's the original quote from me to which you were responding: "You could tell their design goal with SL was to provide the most functionality in the simplest, cleanest, and most intuitive way."

And when it comes to design, the 12-month cycle isn't really 12 months. There's time at the beginning to switch to setting things up to design a new OS, and time at the end to wrap things up. So the amount of focused design time they have with a 2-year cycle is much more than twice what they get with 1-year. One year simply doesn't give them space to think—and to discard ideas that don't work—that two years does. And that difference in time is not subjective.

Of course, more design time doesn't automatically result in a better product; with bad designers, you're giving them more time to screw things up. But I'm giving Apple's UI designers the benefit of the doubt here, than they could produce a better product if given significantly more time.
I don’t think this is true though. The release schedule is more frequent, but the features are far fewer. Leopard boasted over 300 new features iirc. It’s not the release schedule, it’s the amount of work crammed into that release schedule. Recent Mac releases have a handful of features. I think it’s red herring to suggest it would be better if things went back to the old days of two or more years between releases.
You need to be careful of those figures. That 300 sounds like it came out of Apple's marketing dept. They probably tasked someone with enumerating every new thing, no matter how small, and counting it as a change. If you applied that same counting method to the newer OS's, you might find similar values. For instance, this article highlights "50 new features and changes" in Ventura "worth checking out", indicating those 50 are just a subset of the total number of changes. https://www.macrumors.com/guide/macos-ventura-features/

So I'd argue it's those arbitrarily-enumerated new-feature numbers, rather than the release schedule, that are the red herring.

But we can also talk about stability:

I've been using MacOS since Panther in 2003, and my experience is the opposite of yours. From 2003-2009, I used a G5 PPC that never crashed, except for one year where we tracked the issue to Seagate backup software. As the OS's progressed after that, their stability decreased (unless that can be attributed to an inherent stability difference between OS's written for a PPC vs. ones written for x86): I've found the frequency of kernel panics has progressively increased over the years.

I currently record every kernel panic. Here's when I had panics (not apps crashing, but panics forcing a reboot) in 2024 on my current machine, a 2019 i9 iMac running Monterey: 1/26/2024; 3/15/2024; 5/20/2024; 10/24/2024; 12/14/2024.

And it's not just about the panics. I was able to keep that PPC running continuously, and its behavior remained rock-solid. By contrast, with later OS's I had to reboot at successively shorter intervals to keep the machine from being wonky. It used to be once every few months, then once/month, then once every few weeks, then once/week, and it's now about every four days.

MacOS has needed to add features over the years, which unavoidably makes it more complicated. Thus what I'm experiencing is consistent with general principles of system design: Everything else being equal, as a system becomes more complicated, it becomes more likely to have bugs. Or, alternately: As a system becomes more complicated, greater attention is needed to keep the bugs at the same level.
Snow Leopard boasted no new user facing features. Under the hood, massive changes took place. Grand Centra Dispatch etc. Early Snow Leopard was full of bugs and issues. It was only fine towards the end of its life.
You're always going to have bugs with the early versions. That's why I never upgrade until mid to late in the release cycle. But at least with Snow Leopard, at the end they did produce something that was thoroughly patched, unlike the case with later OS's, where you have, for instance, memory leaks that remain unfixed with the final release. And one of the most important factors that enabled SL to be well-patched with its final release is that Apple had 23 months to do bug fixes, rather than <12, because of the release schedule.

Take a look at this article by Jeff Johnson ( https://lapcatsoftware.com/articles/2023/11/5.html ):

"Once Apple engineers are 'finished' releasing a major update, they have to turn around immediately and work on the next major update. After all, WWDC in June every year is only eight months later. Tim Cook's schedule is relentless.

Software quality is a marathon, not a sprint. It's the result of many minor bug fix updates over time with no major updates to introduce new bugs. There was a significant difference between the initial quality and final quality of Snow Leopard. That's why spending a week on bug fixes is nothing but a drop in the bucket. Apple has accumulated more than ten years of technical debt, never giving itself enough time to pay down that debt....No major update will solve Apple's quality issues. Major updates are the cause of quality issues. The solution would be a long string of minor bug fix updates. What people should be wishing for are the two years of stability and bug fixes that occurred after the release of Snow Leopard. But I fear we'll never see that again with Tim Cook in charge."
 
Last edited:
Yeah, but I was mostly talking about the effect of a 2-year release schedule on the quality of the UI design, not the stability. Here's the original quote from me to which you were responding: "You could tell their design goal with SL was to provide the most functionality in the simplest, cleanest, and most intuitive way."

And when it comes to design, the 12-month cycle isn't really 12 months. There's time at the beginning to switch to setting things up to design a new OS, and time at the end to wrap things up. So the amount of focused design time they have with a 2-year cycle is much more than twice what they get with 1-year. One year simply doesn't give them space to think—and to discard ideas that don't work—that two years does. And that difference in time is not subjective.
Yeah but that’s not what happens. They don’t have to force all changes into a 12 month cycle just because the release cycle is 12 months. Many design decisions and features take years, and are planned to be released several releases later. Having a shorter release cycle allows smaller, more manageable updates, which is why Google does the same thing with Chrome. As I said, it’s not the cycle, it’s the amount of features planned.
Of course, more design time doesn't automatically result in a better product; with bad designers, you're giving them more time to screw things up. But I'm giving Apple's UI designers the benefit of the doubt here, than they could produce a better product if given significantly more time.
They have significant time. No one is forcing them do a redesign in a few months.
You need to be careful of those figures. That 300 sounds like it came out of Apple's marketing dept. They probably tasked someone with enumerating every new thing, no matter how small, and counting it as a change. If you applied that same counting method to the newer OS's, you might find similar values. For instance, this article highlights "50 new features and changes" in Ventura "worth checking out", indicating those 50 are just a subset of the total number of changes. https://www.macrumors.com/guide/macos-ventura-features/
Certainly the marketing department quotes these things but your feelings are misplaced. You don’t need to trust my statements. Since you quote macrumors, you can go through their history and check out the forums there. For pretty much every release, there is a “New features in Mac OS thread”, nowadays it’s “Little features in macOS”. People go through each app and part of the os to find features. You can clearly see the reduction in features since they moved to the 1 year release cycle. There is no way to pretend recent releases had anywhere as many features as Leopard. It was a gigantic release. Unstable too.
So I'd argue it's those arbitrarily-enumerated new-feature numbers, rather than the release schedule, that are the red herring.
They’re not arbitrary. There literally every tiny feature accounted for. Again, feel free to double check.
But we can also talk about stability:

I've been using MacOS since Panther in 2003, and my experience is the opposite of yours. From 2003-2009, I used a G5 PPC that never crashed, except for one year where we tracked the issue to Seagate backup software. As the OS's progressed after that, their stability decreased (unless that can be attributed to an inherent stability difference between OS's written for a PPC vs. ones written for x86): I've found the frequency of kernel panics has progressively increased over the years.
If you were using it since Panther, then that was the last release where PPC was the primary target. Apple switched to Intel by late Tiger (2006). It doesn’t seem surprising that stability decreased after they stopped worrying about PPC. That is a much more likely culprit than release cycles.
I currently record every kernel panic. Here's when I had panics (not apps crashing, but panics forcing a reboot) in 2024 on my current machine, a 2019 i9 iMac running Monterey: 1/26/2024; 3/15/2024; 5/20/2024; 10/24/2024; 12/14/2024.
Hmmm I hate to break it to you, but you probably have a hardware issue with the machine. I also record KPs as part of my personal use and my work involving thousands of Macs within commercial and educational environments. The trend is clearly downward. If you think about it, it makes sense given the amount of work that has gone into removing things from kernel space. These days, some file systems and things like Wifi, ethernet are run in user space. Those used to be frequent causes of panics. If you’re having four panics in a year, I’d wager it’s something hardware related.
And it's not just about the panics. I was able to keep that PPC running continuously, and its behavior remained rock-solid. By contrast, with later OS's I had to reboot at successively shorter intervals to keep the machine from being wonky. It used to be once every few months, then once/month, then once every few weeks, then once/week, and it's now about every four days.
That’s absolutely not normal.
MacOS has needed to add features over the years, which unavoidably makes it more complicated. Thus what I'm experiencing is consistent with general principles of system design: Everything else being equal, as a system becomes more complicated, it becomes more likely to have bugs. Or, alternately: As a system becomes more complicated, greater attention is needed to keep the bugs at the same level.
Yeah but everything else isn’t equal. What that belief ignores is the fact that subsystems and parts of the os can be reengineered to be have more features added and still be more reliable and safe, and yes, less complex. Part of that is experience, part is time, but part is newer technologies or language features. Memory safe languages go a long way to make fewer memory based bugs for example.

In the early days large parts of the kernel had to created to add important features. Those added complexity and instability. As bugs were found, they were ironed out. Often they were fixed by a redesign with newer techniques and safer language and compiler features. Once those are done, they don’t need to redone usually, meaning less work.
You're always going to have bugs with the early versions. That's why I never upgrade until mid to late in the release cycle. But at least with Snow Leopard, at the end they did produce something that was thoroughly patched, unlike the case with later OS's, where you have, for instance, memory leaks that remain unfixed with the final release. And one of the most important factors that enabled SL to be well-patched with its final release is that Apple had 23 months to do bug fixes, rather than <12, because of the release schedule.
I’m gonna need to see proof of these supposed memory leaks being due to a release cycle. The first thing people jump on when something is wrong is memory leaks. Few are able to prove it.
Take a look at this article by Jeff Johnson ( https://lapcatsoftware.com/articles/2023/11/5.html ):

"Once Apple engineers are 'finished' releasing a major update, they have to turn around immediately and work on the next major update. After all, WWDC in June every year is only eight months later. Tim Cook's schedule is relentless.

Software quality is a marathon, not a sprint. It's the result of many minor bug fix updates over time with no major updates to introduce new bugs. There was a significant difference between the initial quality and final quality of Snow Leopard. That's why spending a week on bug fixes is nothing but a drop in the bucket. Apple has accumulated more than ten years of technical debt, never giving itself enough time to pay down that debt....No major update will solve Apple's quality issues. Major updates are the cause of quality issues. The solution would be a long string of minor bug fix updates. What people should be wishing for are the two years of stability and bug fixes that occurred after the release of Snow Leopard. But I fear we'll never see that again with Tim Cook in charge."
Lol. Jeff Johnson is a disgruntled ex-Apple employee who has never knowingly said a good word about Apple. Sadly I purchased his “Stopthemadness” extension which turns out to be the greatest waste of money I've ever spent in terms of software. Spectacularly ineffective. I wish he would follow his own advice. He tried to convince me that a Finder issue was due to Apfs, despite other knowledgeable people pointing out he was incorrect. I don’t value his opinion on these matters.

I think I’ve said enough on this topic tbh. Feel free to have the last word.
 
But we can also talk about stability

I had a G4 Cube that I used for something like 9 years (swapped in a faster CPU, so it could run Leopard), until the power supply spit up on meand had maybe 4 or 5 kernel panics in that period. Never got an Intel Mac because I just could not stomach the idea. But Apple introduced the first 64-bit ARM chip in 2013 and had been working on the 64-bit OS for 7 years before they released the M1 Macs, so they had a lot of time to smooth it out.

The iPhone OS has to be rock solid if you want people to buy your expensive phones. And perhaps that had something to do with the decline in macOS stability, as they were being more attentive to detail when working on iOS. Having the two unified can only be a net positive.
 
The iPhone OS has to be rock solid if you want people to buy your expensive phones.
Unfornuately this is no longer true since iOS 16 and stability and UI bugs are considerably even worse in iOS 18.

MacOS has needed to add features over the years, which unavoidably makes it more complicated. Thus what I'm experiencing is consistent with general principles of system design: Everything else being equal, as a system becomes more complicated, it becomes more likely to have bugs. Or, alternately: As a system becomes more complicated, greater attention is needed to keep the bugs at the same level.
I agree with this 100%. The extra bloat that was added to iOS since iOS 16 is too much and couple that with not nearly enough bug fixing, you got the mess that is iOS 18.3.2

I depise iOS now, can we PLEASE go back to iOS 15.
 
Lol. Jeff Johnson is a disgruntled ex-Apple employee who has never knowingly said a good word about Apple. Sadly I purchased his “Stopthemadness” extension which turns out to be the greatest waste of money I've ever spent in terms of software. Spectacularly ineffective. I wish he would follow his own advice. He tried to convince me that a Finder issue was due to Apfs, despite other knowledgeable people pointing out he was incorrect. I don’t value his opinion on these matters.
Agree with this, dude is grumpy but he poses a good question. Why does Apple have major yearly updates and I think its do with marketing pushing them to do it.
 
Many design decisions and features take years, and are planned to be released several releases later.
Not all features are planned years ahead of release, the siri part of apple intelligence was a rushed job and you can clearly tell that it was.

The fact Apple didn't show a demo of context siri to the media/devs even to this day proves it.
 
Back
Top