It seems to be an import pipeline bug.
Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.
Rare, nondeterministic corruption fits the profile.
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.
I have had extremely bad luck, reporting bugs to Apple.
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.
They asked me for a sysdiagnose when I complained about how crappy their new Finder disk icon looks on macOS 26. See this rant by Jeff Johnson, who called for a boycott on filing bugs with Apple a couple years back (I stuck to the boycott except for two obvious UI design issues in the latest OS because neither required repro steps (so why the sysdiagnose?)).
https://lapcatsoftware.com/articles/2025/8/7.html
Edit: accidentally called sysdiagnose a spindump.
Oh I stored filing bugs years ago. It frustrating as hell and pointless
Not to hand wave-- but this feels industry standard IMO. I have a dozen PRs sitting unacknowledged and stale across a handful of FAANG (and other) repos, including Apple's.
I start my first day @ Apple in a few weeks, so I ACK that my opinion might be a little biased here.
Maybe you can help bump FB13400242, a bug that is _literally_ going to kill people. (The bug is that to make an emergency call, even from lock screen, you're supposed to be able to squeeze buttons on either side of the phone. But it only works with the volume buttons on the left - the Action button didn't get supported, when that button was added. So now the rule for teaching a small child isn't just "squeeze both sides" it's "oh but not that one!")
(Yes, this came close to killing someone close to me. Fortunately someone else happened to come along to help.)
Consider hitting up some Apple "watcher" people (e.g. 9to5mac) to see if they can give you a boost on their social media. It's pretty obnoxious that it's come to needing to make a stink like that to get eyeballs on something, but here we are.
This definitely works. When I was at Apple I remember a number of issues in their weekly “bug review board” were classified as being high priority because they were going viral on Twitter.
> you're supposed to be able to squeeze buttons on either side of the phone. But it only works with the volume buttons on the left
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?
I'm decades away from being a small child and I can't remember these gestures. The only time I get screenshots or activate emergency mode on my phone is accidentally. Of course I also don't expect my phone to be able to help me much in an emergency.
Well, not an Apple fan personally but on this they are just top of class. Even if this story involves an Apple Watch and not an iPhone, my father-in-law some time ago fainted (due to an underlying heart issue we late uncovered), knocked his head on the toilet when he got up in the middle of the night to go to the bathroom. He lost consciousness for a brief moment and when he regained it, there was already someone from the emergency line speaking through the Apple Watch and he got the ambulance at home faster that without wearing the Apple Watch, and surely helped in saving his life.
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.
My phone is off at night and I don't have a watch. I try not to let these huge companies FUD me into thinking that I appreciably change my odds of surviving an accident by buying their technology, but I get that others see it differently.
Maybe you want to rethink that? You're literally responding to a testimonial that it likely saved someone's life. Seconds do matter in some medical emergencies.
Also, you may not be aware of Car Crash Detection https://support.apple.com/en-us/104959
Of course, the seconds that matter might be someone else's medical emergency, which your iPhone or Apple Watch is slowing down with false positives.
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.
Yep, this is the other side of the coin for sure. There should probably be some basic training around these features; there will still be many (careless) people that just completely ignore the "are you OK?" question the watch/phone is asking them but maybe the situation would improve.
To be fair this kind of thing is emotionally manipulative.
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.
Here's the official Apple Information on how to do this:
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.
A bug that has been reported that is down prioritized that then leads to killing people would be a pretty bad case for Apple when it came to court.
I think a faster / easier approach is to just press the biggest button repeatedly until it makes an emergency call for you.
A five year old is going to find "just squeeze" easier than doing that.
five year olds shouldn't have a phone, and should be supervised. even if they have a phone, they are unlikely to handle it with the care it requires.
Thread is talking about kids knowing how to request emergency services with a nearby phone in case something happens to their parent(s). Nothing to do with giving kids their own phones.
A nearby phone implies a nearby phone user that would presumably understand how to place an emergency call, especially if they are being asked by a frantic five year old.
if it’s only the kid and the nearby phone user, and the nearby phone user is having an emergency (that’s also preventing them from being able to call themselves) then the kid is able to do it.
well you're already starting off assuming that the kid is holding an iPhone. so its already an "oh but not that one" situation.
I don’t know anyone that has any phone but an iphone, so it’s a good assumption.
How to say I'm American without the accent...
Could be Japan too.
Industry baseline is slightly worse again e.g. attempt to report a bug in a Microsoft product that a major government customer is experiencing when they use it with our stuff, but Microsoft won't accept the bug report because we don't ourselves have an enterprise support contract with them, and the customer's own relationship with MS is nigh-impossible to navigate because of public sector nonsense.
I've only submitted two security reports, both for very blatant bugs, and they've booth been closed as "works as intended".
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.
Did you take a job at Apple just so you can accept one or more of those PR's that's been bugging you? :)
Wasn't there an xkcd about that scenario...
Just gotta be careful...
If you ever get the chance, maybe you can be the one that improves that process some day.
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.
Unless one's title is going to be "VP" or "SVP", the chance that someone joins BigTech and gets to "improve the process" is usually miniscule. You're being hired as cog #21 on team #54 and there is a large backlog of JIRA (well, in this case, Radar) tickets to grind through. There will be people who tell you what the processes are, and to not deviate from them. And you shouldn't get mad at those people, either--they're just the messengers, and were told what the processes are by people above them on the totem pole and so on.
how is this different from any product with a billion users and 100,000+ live bug reports?
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.
I'm amazed at what Google was okay with. For a while there, if you had access to Chrome's files, for a user logged in with Chrome that had a credit card on file with Google, you could initiate a Google Pay payment with no further authorization.
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.
Open radar is a just a landfill. Nothing ever gets picked up for fixing
> I guess you can't argue with the results, as they have a market value North of 3 trillion dollars
This was financed by equally massive technical debt.
How does one finance a project or a company with increased maintenance costs and lower quality production?
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.
> How does one finance a project or a company with increased maintenance costs
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.
? This is the system working as designed. The whole game, from startup to fortune 500, is to accumulate market power fast enough to avoid tech debt swallowing you whole.
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.
> I have had extremely bad luck, reporting bugs to Apple.
From your description, your experience is quite typical.
mmm, it was better than the "closed as duplicate" (of an internal bug that you can't access) path that used to be the big complaint about radar...
"Very rarely, I may get a ping on one of my reports"
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.
Unless you get paid by Apple, why would you spend any amount of time doing work for them?
Because you want them to fix a bug they might not be aware of, and bug reports are also votes of importance
What's worse about the Apple ecosystem is that because of how tightly coupled it is, a bug fix for Photos would only come as part of a macOS update.
Which means that if that bug has been present since the (now unsupported) Mavericks, tough luck!
I still don't under stand why Apple limits updates to their first party apps to OS updates.
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.
A lot of them are also the library surface for a lot of internal foundational libraries. Photos is also PhotoKit, similarly with email. It's essentially over coupled.
They somehow separate out certain apps, like Safari (on occasion), the iWork suite, and the Pro apps, but I have no idea why they insist on coupling apps like Photos and Music to OS updates.
Safari is interesting. It's been separate, except for major macOS updates, which had it bundled. But if you had a newer Safari on an older macOS, and upgraded macOS to anything else that the latest version, then your Safari was downgraded, often causing data loss..
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..
Google used to keep it coupled on Chrome OS, and older Chromebooks can only run insecure versions of Chrome.
MacOS updates are several per year though. If a fixes found (and the bug considered a high enough priority) it could show up before 2025 is up.
It’s a way to force you to update those apps. They don’t want you on the latest OS and on an old Music or Photos.
It’s more a problem for Macs not supported with OS updates like the 2019 13” models right now.
I think your best bet is to do what you did: write an extensive blog post about it and hope it goes "viral" and grabs the right people at Apple's attention.
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!
iTunes Match has routinely just... removed/greyed out files that I've had uploaded, and I've reported this to Apple over and over again, with exactly zero explanation of why or how to avoid it. To this day it still does it.
Have you tried copying the files to the local disk before importing?
I use Lightroom, but always with this workflow (copy files from memory card to disk, then use LR to do the import / move / build previews).
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.
This is what I always do. Rather than go directly from the card reader or camera into Photos or Lightroom, I copy the files onto an SSD, and then bring them in from the SSD. The entire process goes faster.
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.
I haven't had actual corruption but had imports take an excessive long time or fail to complete in Lightroom because of bad USB cables or (I think) bad USB jack.
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.
You don't need repro steps if Apple is serious about quality. Just the description of what's happening should give enough to a senior Apple engineer to intuit where this is possibly happening and create tests that will stress their software to repro this.
I see you've never used Feedback Assistant
> I'd report it to Apple
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 worked on the Photos team a decade ago — some of what you're saying I can vouch for. If it is a rare occurrence, that lowers the priority of the bug. Data corruption though? That moves it to the top.
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.
> 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
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.
> Why? If your app is used by billions of people, surely you can afford a few additional testers and engineers?
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.
Garbage software still makes lots of money. Sometimes more than good software, and certainly more than the best software. Just look at the windows vs Linux ecosystem for a simple task like screen recording with decent compression. Open source tools are superior, but can be harder to even find on windows due to the poorer signal/noise ratio from all the terrible for profit/enshittification software. Some graphics drivers have dashboards that do screen recording, but that is not a universal solution.
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.
> 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.
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.
If you have more bugs than you can fix in a given amount of time then you have to prioritize somehow.