So exactly what problems do most people have with iPhones that could be solved with Android.
One really big one that comes to mind: watching YouTube videos without ads. On an Android, you just install Firefox, then install uBlock Origin inside it, then navigate to youtube.com and enjoy. Or you can install an app like Revanced; you might have to manually load the APK, but it's doable.
Yes, "floating point accumulation doesn't commute" is a mantra everyone should have in their head, and when I first read this article, I was jumping at the bit to dismiss it out of hand for that reason. But, what got me about this is that: * every other Apple device delivered the same results * Apple's own LLM silently failed on this device to me that behavior suggests an unexpected failure rather than a fundamental…
FYI, the saying is "champing at the bit", it comes from horses being restrained.
Huh. I never knew "champing" was the proper spelling [0]
Actually it was originally "champing" – to grind or gnash teeth. The "chomping" (to bite) alternative cropped up more recently as people misheard and misunderstood, but it's generally accepted as an alternative now.
built-in calculator apps are surprisingly underbaked... I'm surprised neither of the big two operating systems have elected to ship something comparable to a real calculator built in. It would be nice if we could preview the whole expression as we type it.. I use the NumWorks emulator app whenever I need something more advanced. It's pretty good https://www.numworks.com/simulator/
That’s certainly an improvement - but why can’t I modify a previous expression? Or tap to select previous expressions? What I want is something like a repl. I want to be able to return to an earlier expression, modify it, assign it to a variable, use that variable in another expression, modify the variable and rerun and so on.
Qalculate https://qalculate.github.io/> is my favourite REPL-like calculator, although it unfortunately lacks an iOS app. It feels similar to using an HP 48-series calculator.
Numbat https://numbat.dev/> is similar, but more CLI/REPL-focused, and with more of an emphasis on being a programming language.
Blog post dated 28 Jan 2026, the bug fix posted 29 Jan 2026, so I guess this story had a happy ending :) Still, sad state of affairs that it seems like Apple is still fixing bugs based on what blog posts gets the most attention on the internet, but I guess once they started that approach, it's hard to stop and go back to figuring out priorities on their own.
I think you overestimate the power of a blogpost and the speed of bugfixing at Apple for something like this. I almost guarantee there is no way they can read this blogpost, escalate it internally, get the appropriate approval to the work item, actually work on the fix, get it through QA and get it live in production in 3 days. That would only happen on really critical issues, and this is definitely not critical enou…
It would have to be a very serious security bug. Even then, unless they've totally upended their software development workflows in the past couple of years, the Apple I knew extremely well from the inside couldn't turn around a software fix this quickly, from PR to OS release, even if its existence depended on it. There's simply too much bureaucracy and process around submitting anything, no matter how vital.
I think you overestimate the power of a blogpost and the speed of bugfixing at Apple for something like this. I almost guarantee there is no way they can read this blogpost, escalate it internally, get the appropriate approval to the work item, actually work on the fix, get it through QA and get it live in production in 3 days. That would only happen on really critical issues, and this is definitely not critical enou…
Three days is, agreed, too short. A week is just about possible, though... I've seen a blog-post, authored a bug in Radar, assigned it to myself, and fixed it the same day. Whether it goes out in the next release is more a decision for the bug-review-board, but since the engineering manager (that would have been me) sits on that too, it's just a matter of timing and seeing if I can argue the case. To be fair, the clo…
The fixing of a bug at Apple is the easy and quick part. It's the submission process from then until it gets released as part of an OS update that is the ridiculously long (and too often difficult) part.
Blog post dated 28 Jan 2026, the bug fix posted 29 Jan 2026, so I guess this story had a happy ending :) Still, sad state of affairs that it seems like Apple is still fixing bugs based on what blog posts gets the most attention on the internet, but I guess once they started that approach, it's hard to stop and go back to figuring out priorities on their own.
Just goes to show that attention is all you need.
A statement which goes to show that confusing correlation with causation is all you need.
Says who? How do you know what’s on my device, how much it matters to me, and what countless other options I have for recourse if that did happen?
What does that have to do with it being theater or not?
Because I’m saying the threat vector you used to justify it is not an issue for me at all, so it’s a baseless justification for “security”, ergo, theatre.