[longfacehorrace]

It's not just the keyboard. My iPhone 15 is often so unresponsive I am tapping twice as much.

Example but the issue not limited to web browsing; Safari will do nothing, I tap again, it does the thing, then it does the thing again due to the second tap. I have to tap back to get to where I really wanted to go.

[itopaloglu83]

Sounds like the liquid glass animations are so heavy that if the system is busy with anything else for a second then everything simply breaks.

I remember seeing the videos about cpu usage spiking over 40% just to show the control center.

And similarly, even on a Mac I find myself clicking on links and button multiple times, just for things to work. It has a dedicated keyboard, how is it that they messed it up so much that a physical keyboard stops working. It's an interrupt based interface, it takes less than a millisecond to process things, how can someone mess things up so freaking stupidly.

[seec]

That was basically the whole point of it.

Apple makes money selling hardware; they have a vested interest in making things slower/worse to incentivize people to buy newer hardware.

This is why you can never really trust Apple and also why no matter how bad Windows gets, it's still a better deal because at least you can count on the fact that PC businesses will compete on the hardware front to get your money.

Choosing Apple is a lot like being in an abusive relationship; you can't leave because the switching cost are quite high, so you tolerate a lot more abuse than you would be willing to otherwise.

And this is the reason people try to not rely on Apple software too much; if you do, they truly have you by the balls.

[longfacehorrace]

Shortcuts run but often do not trigger all the stages in a pipeline. No issues with same shortcuts prior to installing iOS26. These Shortcuts do not trigger UI transitions. They send data over network.

Sounds like Apple management enabled a quality assurance failure that is fostering so many distractions for users it's turning people against Apple.

Tim Cook handing his replacement a dumpster fire.

[tadfisher]

Extremely common pitfall in UI engineering. If you treat all input as a queue that's divorced from output, you end up with situations like this.

It's kind of a paradox, but in many cases you need to actually discard touch inputs until your UI state has transitioned as a result of previous inputs. This gets extremely nuanced and it's hard to write straightforward rules about when you should and shouldn't do this. Some situations I can think of:

- Navigation: User taps a button that pushes a screen on your nav stack. You need to discard or prevent inputs while the transition animation is happening, otherwise you can push multiple copies of that screen.

- Async tasks: User taps a button that kicks off an HTTP request or similar, and you need to wait on the result before doing something else like navigation or entering some other state. Absolutely you will need to prevent inputs that would submit that request twice. You will also need some idempotency in your API design to handle failure/retries. A fun example from the 1990s is the "are you sure you want to make this POST request again" dialog that Web browsers still show by default.

- Typing: You should never discard keystrokes that insert/delete characters while a text input field is focused, but you may have to handle a state like the above if "Enter" (or whatever "done" button is displayed in the case of a software keyboard) does something like submit a form or do navigation.

Essentially we're all still riding on stuff that the original Mac OS codified in the 1980s (and some of it was stolen from Xerox, yes), so the actual interaction model of UIs is a mess of modal state that we hardly ever actually want to fully realize in code. UI is a hard problem!

[ninth_ant]

This analysis ignores the fact that the user experience has regressed from a previous version which didn’t have these issues.

So it’s not like some longstanding industry-wide UI issues they’ve ignored forever, it’s that Apple has introduced new tradeoffs or lowered their quality standards to the point that some users feel their experience has worsened.

[not_kurt_godel]

https://developer.mozilla.org/en-US/docs/Glossary/Debounce

[tadfisher]

Okay, how long is the debounce window? Where in the input pipeline do you debounce (obviously not immediately on keystrokes)? Will debounce work for long-running requests, which are event-driven and not time-driven?

I have seen, far too many times, naive approaches like wrapping all click handlers in a "debounce" function cause additional issues and not actually solve the underlying problem.

[not_kurt_godel]

To clarify - I am not stating that simple debouncing is the solution to all the issues you're identifying. I agree with you that handling some of them can be very complex. I just shared the article as a pointer to a broadly similar concept that can be used to help communicate the gist of what you're talking about.

[NetMageSCW]

Just to correct a common error, nothing was stolen from Xerox. Apple gave Xerox stock (which they later sold too early) for demos and access to the Parc work on Smalltalk and GUIs.