[embedding-shape]

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.

[dahcryn]

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 enough for that.

[spacedcowboy]

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 closer we are to a release, the less likely a change is to be accepted unless you can really sweet-talk the rest of the BRB, and there's usually a week of baking before the actual release goes out, but that has sometimes been shrunk for developer-preview releases...

[tensility]

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.

[spacedcowboy]

The submission process is pretty trivial too - as long as your code gets a PR review, and is given the green light to be merged into trunk (which is the 99% case, even if there are PR comments to address), it's going to be in the next daily build.

The releases are the things that are few and far between - generally though, a nominated daily-build (based on the pre-determined release schedule) is triaged and tested by QA and engineering for a while before release, and then ... it's out there...

...Unless something goes unexpectedly wrong with the nomination, anyway. That's pretty rare because builds are constantly being made, regressions identified, and new bugs discovered and earmarked as "must-fix" (or whatever) on a daily basis. B&I have a fairly good feel for how things are going at any given time.

It's really just timing. If you can squeeze another fix in before the cutoff deadline for the nominated build, you're in. If not, you wait until the next one, which can be a while...

[tensility]

Yeah, that was not at all my experience in CoreOS/SWE, where we would sometimes/often have to wait weeks for submissions to turn around in B&I to become part of "daily" builds. Glad you don't have to put up with the same ridiculous crap process.

[tensility]

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.

[embedding-shape]

Or, one of the developers of the library saw it, decided to fix it in their spare time (does that exist at Apple?) before it became a bigger thing.

If not, talk about coincident that someone reported an issue and all of that you mentioned was already done before that happened, and the only thing missing was merging the code to the repository which was done after the issue was reported. Not unheard of, but feels less unlikely than "Engineer decided to fix it".

[jckahn]

Just goes to show that attention is all you need.

[tensility]

A statement which goes to show that confusing correlation with causation is all you need.

[llm_nerd]

MLX is a fairly esoteric library seeing very little usage, mostly to try to foment a broader NN space on Apple devices. This isn't something that is widely affecting people, and most people simply aren't trying to run general LLMs on their iPhone.

I don't think that fix is specific to this, but it's absolutely true that MLX is trying to lever every advantage it can find on specific hardware, so it's possible it made a bad choice on a particular device.

[rafaelcosta]

Extremely bad timing on my end then, should've waited for a few more days

[syntaxing]

I don’t think so. You can see the issue ticket linked in the PR. Whether that issue ticket is related to the blog post is unknown https://github.com/ml-explore/mlx-swift-examples/issues/462

[mrtesthah]

How do you know that it wasn’t merely that the blog post elicited multiple people to file the same duplicate bug in Apple’s radar system, which is how they ostensibly prioritize fixes?

[embedding-shape]

I don't, but the effect is the same, "something might land in the news, lets fix it before it does, since multiple people reporting the same issue based on this public post someone made".