This is also my guess. It's really a bummer, and I'd report it to Apple but since it's nondeterministic I have no idea how to provide repro steps.
They constantly ask for an example project, even if it's something that is easily demonstrated, simply by running existing Apple software, and creating a project, would be a huge pain.
They also ignore reports. Very rarely, I may get a ping on one of my reports, asking me to verify that it was fixed in some release. Otherwise, there's no sign that they ever even read it.
I usually end up closing my bug reports and feature requests, after a few months, because I'm tired of looking at them.
It's clear that they consider every bug report to be a burden. That's a very strange stance, but then, they are not a typical company.
I guess you can't argue with the results, as they have a market value North of 3 trillion dollars, but that does not make it any less annoying.
I start my first day @ Apple in a few weeks, so I ACK that my opinion might be a little biased here.
(Yes, this came close to killing someone close to me. Fortunately someone else happened to come along to help.)
There were certain photographers and publications, that, if they got upset, all hands were on deck, for even the most innocuous bugs.
Btw I wonder if Apple sends some spoken message to the emergency services or some metadata or just connects the phones and that's it.
Edit: oh and I forgot: my wife got a loud message (that bypassed DND) telling her that her father maybe felt, because she is one of his emergency contacts.
Also, you may not be aware of Car Crash Detection https://support.apple.com/en-us/104959
The Insurance Institute for Highway Safety has done a lot as a private organization to raise standards for automotive safety but the statistics they publish that show that larger vehicles are safer than larger vehicles are frequently wrongly interpreted -- in many of the cases where the large vehicle does better it's not that you die in the smaller vehicle but instead get a broken bone. Once something is seen as "life or death" some people will think they have no choice but to spend another $50,000, spew another 20 tons of carbon pollution, etc.
Just pointing this out. It’s easy to see what you actually meant :)
From https://9to5mac.com/2023/02/03/iphone-crash-detection-critic...
“My whole day is managing crash notifications,” said Trina Dummer, interim director of Summit County’s emergency services, which received 185 such calls in the week from Jan. 13 to Jan. 22. (In winters past, the typical call volume on a busy day was roughly half that.) Ms. Dummer said that the onslaught was threatening to desensitize dispatchers and divert limited resources from true emergencies.
I don't recall there ever being any official language about "squeezing both sides of the phone" to make emergency calls. Doesn't the feature description in Settings explicitly reference which buttons to press?
In case of emergency, use your iPhone to quickly and easily call for help and alert your emergency contacts (provided that cellular service is available). After an emergency call ends, your iPhone alerts your emergency contacts with a text message, unless you choose to cancel. Your iPhone sends your current location (if available) and—for a period of time after you enter SOS mode—your emergency contacts receive updates when your location changes.
Note: If you have iPhone 14 or later (any model), you may be able to contact emergency services through satellite if cell service isn’t available. See Use Emergency SOS via satellite on your iPhone.
Simultaneously press and hold the side button and either volume button until the sliders appear and the countdown on Emergency SOS ends, then release the buttons.
Or you can enable iPhone to start Emergency SOS when you quickly press the side button five times. Go to Settings > Emergency SOS, then turn on Call with 5 Presses.
Even if it's standard among tech giants, you could be the one that makes a new standard! Good luck in your new role, btw.
Wasn't there an xkcd about that scenario...
I don't think my bank had intended to make passwords optional, and the third-party administrator of their bug bounty program agreed, when creating the report, but once it made it to the bank, it was up to them to decide if it was or was not a bug.
This was financed by equally massive technical debt.
That’s what technical debt is. It’s the cost for moving forward quickly. I’m not sure I understand what you’re trying to state.
You seem to be assuming that the company will eventually pay off the technical debt rather than just continue accumulating it and lowering production quality.
Once you have market power (which means different things for different companies) you can safely feed the tech debt monster just as little as you feel like.
From your description, your experience is quite typical.
I've had pretty good luck reporting bugs to Google (notoriously bad!):
1. provide simple, crystal clear examples that cannot be due to third parties, misconfiguration or user error.
2. show that it's happening to a large number of mainstream users (not niche)
3. show that it breaks critical workflows and has no easy workaround (incl partial workarounds).
4. if you meet #1-3, then wait 6-9 months minimum (more if hard to fix). If not, wait 3-5+ years.
---
Favorite example: in the mid-2000s, I caught google maps confusing suite/apt numbers for street numbers. It got flagged as low priority. So, to get the team's attention, I reproduced the bug on a large Google offices. Six month later, bug fixed.
After that experience, I report everything to Google that breaks my workflow. Like clockwork, the biggies get fixed a couple of quarters later.
---
Want long? Try improving/fixing core issues with the API design of Linux or PostgreSQL: fix times can be measured in decades. Backward compatibility is insufficient - they rightfully worry about libraries and tools adopting the new APIs and then breaking legacy systems that cannot be upgraded even for mission-critical security issues.
---
NOTE: OP bug feels P0 and the better strategy is either mass media (incl HN) or networking to someone inside the company. I've hit those too over the years and can usually find someone at the company to send directly.
They also used to let anyone add any gmail address to a Google Groups group, and send out unfilterable spam as a message from that group.
https://lapcatsoftware.com/articles/2025/8/7.html
Edit: accidentally called sysdiagnose a spindump.
Hm. That is more than I ever got, but I also never bothered to report anything to any company after being ignored the first tries.
Support asked me to let them know when a contact vanishing did so they could gather logs from me phone.
Once I was finally able to see it happen, I reached out. Reported that it had just happened overnight. The customer support said it was too long of a time frame for engineers to investigate because "it generates a lot of logs and that's too much to go through". I could not believe their answer.
I just moved my contacts to Gmail and that was the end of it.
Which means that if that bug has been present since the (now unsupported) Mavericks, tough luck!
For example, I'm probably not going to be upgrading to Tahoe until Sequoia's close to end of support life. I just upgraded to Sequoia last month from Ventura (decided to skip Sonoma since the various anecdotes of Sequoia made it sound like Sonoma-with-AI, with few apps breaking because of some new API change).
They could really benefit from how Google does it on Android and decouple it. Push updates to their first party apps via the app store like everyone else, and let the OS update on its own separate schedule.
In Sonoma or Sequoia they started bundling all Safari updates with macOS, but right now Safari 26 appeared as a separate update in Sonoma/Sequoia—-and it will likely stay that way.
Each thing separately can be explained, but when put together it’s somewhat messy..
I would think the diffs would be telling to the right people.
It's on the front page of HN, so that's a good start!
I also want to point out that I've seen similar corruption in the past, only in Lightroom. The culprit ended up being hardware, not software. Specifically, the card reader's USB cable. I've actually had two of these cables fail on different readers. On the most recent one, I replaced it with a nicer Micro B to USB C cable, and haven't had an issue.
Generally I'm frustrated with the state of USB. Bad cables are all over the place and I'm inclined to throw cables out if I have the slightest problem with them. My take is that the import process with Lightroom is fast and reliable if I am using good readers and good cables; it is fine importing photos from my Sony a7iv off a CFExpress card but my Sony a7ii has always been problematic and benefits greatly from taking the memory card out and putting it in a dedicated reader, sometimes I use the second slot in the a7iv.
If nothing else, it lets you get your card back much more quickly, as a file-system copy runs at ~1500MBps, which makes a difference when importing 50-100GB of photos.
I also don't delete the images off the memory card until they've been backed up from the disk to some additional medium.
As an engineer on a framework, I take pride in the code and want those trickier-to-repro bugs. And to your point, yeah, I can probably reconstruct in my mind a scenario, knowing my code, where it may be vulnerable.
Whoever screens bugs though is likely trying to 1) handle the huge backlog and 2) trying to spare the engineers bugs delivered with a shrug.
(I had my ass kicked by one bug in particular where I created a FileDescriptor on the main thread, did some things and then released the FileDescriptor on a background thread. Who knew the FileDescriptor code hung some important data it needed on some kind of thread-based storage that essentially required the caller to destroy the FileDescriptor on the same thread it was created on. Fix was to dispatch back to main when ready to release the FileDescriptor.)
What's the point of it? It is well known in the industry they ignore bugreports.
Also, this bug doesn't affect the majority of users, so it won't ever be fixed.
I'll tell you a secret though that kind of pisses me off. If you have shipped with a bug, that automatically lowers the perceived priority as well. You know, as opposed to introducing a new bug in a new release. "We've already lived with that old bug…" seems to be the mind set. Oh well.
To be sure though, if you saw the number of bugs that queue up for a popular app like Photos, you'd know that fixing all of them is not going to be possible — some kind of system of prioritization is required.
This mentality is all over BigTech: This bug didn't block release X-1, why should it block release X? So, it inevitably just sits in the backlog forever. If your releases are 90 days apart, any bug found has an average of 45 days to be fixed, or it ends up on the "we lived with it last time" list.
“This bug didn't block release X-1, why should it block release X?” Is actually a pretty strong argument and tough, but not impossible, to counter.
And the bug backlog only gets longer with time. It’s the price of greatly increased software complexity.
There is one more thing that gets factored into the bug triage. If the bug affects professional users (as in, data corruption from external media) - fuck them. Apple couldn't care less about professional users. The priority is to fix Photos.app for utility gauge pics and preferably in HEIC and other default settings.
Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers? Your app doesn't have an unlimited number of bugs: if you are solving them faster than you are introducing them, the number of bugs will eventually approach zero.
Sure, you'll always have newly-introduced bugs which are still waiting to get fixed, but if you've got an ever-increasing pile of bugs which have been around for years - even when they have been reported with easy-to-reproduce steps - then something has gone horribly wrong with your development process. At a certain point you have to stop shoveling new crap, rethink the workflow which is introducing so many new bugs, and slowly start fixing old bugs. The alternative is that your code will inevitably degrade into 100% bugs and become completely unusable and unmaintainable.
Unfortunately, in the real world, # of bugs solved per unit time does not scale linearly with # of developers - and, you eventually reach enough people that you can't effectively coordinate changes without wasting more time on processes than you're gaining by adding another person.
I've never worked at Apple and I don't know anyone on the Photos team, but I imagine a company at that scale probably has a good idea as to the optimal number of developers working on one application. Optimal to Apple probably involves optimal money spent:money earned ratio, not most bugs fixed per unit time, but I would wager those numbers are pretty similar anyways.
The most viable free options on windows seem to be sketchy cloud stuff designed to be inconvenient enough to upsell you. On Linux it's either built in already or trivial to install something that records locally and doesn't rug pull the user demanding money.
This is unfortunately still true. I've had some radars de-prioritized with this exact reason and there are few things more infuriating.
It's really a sign of an overwhelmed, dysfunctional organization, but I heard from an ex-CoreOS guy that that's an intentional management choice, "people perform better under pressure"... (although I'm guessing Photos is not in the CoreOS org)