Issues caused by restoring from backups were super common in the early iOS days. It makes me wonder how many weird bugs can be fixed these days by starting from scratch instead of migrating years of cruft through backup/restore.
Quite a lot probably. I wasn’t able to use the health app on two different iPhones - it would crash after tapping “get started” consistently - and apple told me to just start from scratch instead of restoring from backup and there was no other way to fix it. Not a very satisfying answer
They might not be dependent on ad revenue, but they are a greedy company that will not leave any money on the table. Next year, more ads are coming to the App Store that already generates a profit of over $10 billion/year: https://9to5mac.com/2025/12/17/apple-announces-more-ads-are-...
MacOS doesn’t have a gatekeeper status in the Digital Markets Act (DMA), so Apple doesn’t need to provide it. This shows that they only provide the SDK because of regulatory pressure, and try to maintain their vendor lock-in where possible.
Not necessarily, Since 2015 launch NAN has been vaporware outside android, nobody else support it. Windows does not do so today either [1].
In Linux iw and the new cfg80211 NAN module has support for some hardware. There are few chips in desktop/laptop ecosystem that have the feature, but it is hard to know which ones today, it is more common not to have support than to.
AFAIK no major distros include UI based support that regular users can use. Most Chromebooks do not have the hardware to support, ChromeOS[2] did not have support OOB, so even Google does not implement it for all their devices in the first place.
For Apple to implement is easier than Microsoft or Google given their vertical control, but not simple even if they wanted to. They may still need a hardware update/change and they typically rollout few versions of the hardware first before they announce support so most people have access to it, given the hardware refresh cycle it is important for basic user experience which is why people buy Apple. What is the point if you cannot share with most users because they don't have latest hardware? Average user will try couple of times and never use it again because it doesn't "work".
Sometimes competing standards / lack of compliance are political play for control of the standards not about vendor lock-in directly. Developers are the usual casualties in these wars, rather than end users directly. Webdevs been learning that since JScript in the mid 90s.
All this to say, as evidences go this is weak for selective compliance due to regulatory pressure.
Look, you might be right. But you might be wrong. We don't know for sure.
One of my first jobs was in infosec, and there was a sign above one of the senior consultant's door quoting Hanlon's Razor: "Never attribute to malice that which is adequately explained by stupidity". That quote is right.
There's so much going on at any medium-to-large organisation, from engineering to politics and personalities. All that multiplied across hundreds of thousands of people in thousands of teams. Its possible you're right. Apple might have provided an iOS-only SDK for wifi aware because of regulatory pressure. Its also possible they want to provide it on all platforms, but just started with an ios only version because of who works on it, or which business unit they're part of, or politics, or because they think its more useful on ios than on macos. We just don't know.
Whenever I've worked in large organisations, I'm always amazed how much nonsense goes on internally that is impossible to predict from the outside. Like, someone emails us about something important. It makes the rounds internally, but the person never gets emailed back. Why? Maybe because nobody inside the company thought it was their job to get back to them. Or Steve should really have replied, but he was away on paternity leave or something and forgot about it when he got back to work. Or sally is just bad at writing emails. Or there's some policy that PR needs to read all emails to the public, and nobody could be bothered. And so on. From the outside you just can't know.
I don't know if you're right or wrong. Apple isn't all good or all bad. And the probability isn't 100% and its not 0%. Take off the tin foil hat and have some uncertainty.
Your reply makes sense in a vacuum, but in reality we have the context of having seen Apple comply with regulation maliciously before, so we do know for sure that there's no macOS in the sdk because they weren't forced to by regulation.
> we do know for sure that there's no macOS in the sdk because they weren't forced to by regulation.
Unless you have insider knowledge, we don't know anything for sure here. Apple isn't a person. Apple doesn't have a single, consistent opinion when it comes to openness and EU regulation. (And even a person can change their mind.) All we know is that some teams at apple responded in the past to some EU regulation with malicious compliance. That doesn't tell us for sure what apple will do here.
Apple is 165 000 people. That's a lot of people. A lot more people than comment regularly on HN, and look at us! We don't agree about anything. I'm sure plenty of apple's employees hate EU regulation. And plenty more would love to opensource everything apple does.
That sort of inconsistency is exactly what we see across apple's product line. The Swift programming language is opensource. But SwiftUI is closed source. Webkit and FoundationDB are opensource. But almost everything on iOS is closed source. Apple sometimes promotes open standards - like pushing Firewire, USB and more recently USB-C - which they helped to design. But they also push plenty of proprietary standards that they keep under lock and key. Like the old 20-pin ipod connector, that companies had to pay money to apple to be allowed to use in 3rd party products. Or Airdrop. Or iMessage. AFS (apple filesystem) is closed source. But its also incredibly well documented. My guess is the engineers responsible want to support 3rd party implementations of AFS but for some reason they're prohibited from open-sourcing their own implementation.
We don't know anything for sure here. For my money, there's even odds in a year or two this API quietly becomes available on macos, watchos and tvos as well. If you "know for sure" that won't happen, lets make a bet at 100-1 odds. If you're sure, its free money for you.
> Apple is 165 000 people. That's a lot of people. A lot more people than comment regularly on HN
How do you know the HN numbers? I’m not doubting you, I’m curious about the data.
> and look at us! We don't agree about anything.
At the same time, anyone can join HN. There’s no “culture fit” or anything like that. It is possible to have a larger difference of ideas in a smaller pool of people.
Again, what’s the source of the data? Anyone can throw around vague numbers. “A few million” and “a small fraction” provide no useful information for the context.
What do you mean by "multipoint spec"? I have written a few BT stacks (you might have even used one I wrote at one point or another) and I have no idea what you mean by that phrase. Please cite a section of the spec or proper name of what you are talking about.
They support HFP and A2DP and AVRCP, and properly, including all of those features working on android phones and proper switching between them as needed...
The argument (which I assume you deliberately ignored) is that those features, like battery reporting and multi device pairing, are being arbitrarily restricted by Apple to maintain a proprietary ecosystem.
How you could argue that this is a good thing tells me you're either too drunk on the corporate kool-aid or that you have some financial incentive to ignore the obvious problems with these facts.
Either way this is my last message in this thread as googling things for you is a bore.
So show me in the spec where one BT device as seen by the host can report the battery of three different battery levels - ie the case and two ear pieces.
The obvious solution would be to report the lowest number, as multiple replies to you have already proposed, but you again chose to ignore because it doesn't serve your agenda.
This entire thread started with you claiming Apple was somehow trying to prevent issues by hiding these features, and you've twice tried to move the goalposts to irrelevant points when given evidence to the contrary.
If you can't even defend your original position then I have no interest in continuing a discussion with Apple's most useful idiot.
The lowest level of the three is not a useful number. The case serves as a battery pack to recharge the headphones (something I did earlier today while on an international flight).
The reality is the sort of compatibility being talked about is a new feature with design choices, not just unwired functionality.
I'd rather them work on features to report charging time or expected playback time on iOS, or write their own app for Android, than try to arbitrarily increase their bluetooth profile compatibility checklist.
“the lowest number” would be completely useless. What would that tell me? Do I need to charge the case? So I need to put my left pod in the fully charged case? The right one?
The average between the two buds then, and rely on the LED for the case. This isn't that complicated guys, other earbud manufacturers somehow figured it out, I'm sure Apple can too.
Hyper-fixating on an issue with one part of the spec doesn't dismiss the larger problem being discussed. It's baffling (and kind of sad) how hard you guys feel the need to defend a trillion dollar company making obviously anti-consumer decisions.
How does the “average” help? It still isn’t actionable. It doesn’t tell me whether I need to charge my case, put my left AirPod in a fully charged case or put the right AirPod in a fully charged case.
If you know the average of those three, what does it tell you?
What other manufacturers have figured out how to report three devices that represent to a Bluetooth host as one device in a standards conforming way that will work across multiple hosts?
It’s not that I am defending a trillion dollar company - the idea of averaging three completely different devices is non sensical and provides absolutely no benefit to the end user. If you want ti complain about anyone - complain about the standards body.
You, like the person this thread started with, are (deliberately?) missing the fire in the forest because you want to talk about the state of one tree. Yes, the standard should be improved to support multi-part devices, nobody here is arguing against that.
This entire thread started with someone trying to claim that Apple was not in the wrong by restricting these features, of which battery reporting is A SINGLE ONE.
No, I don't have a perfect solution for this one specific part of the problem, but that's also not been the my focus the entire time. Getting dragged into the weeds only serves to distract from the actually important point here, which is that what Apple is doing is anti-consumer.
Let's first agree that Apple should play on even ground with everyone else, and then we can whinge over how to correctly report the battery of three components over a single connection. Yeesh.
Yes because it’s easy as long as you ignore the details. Speaking of which, how do you surface all of the other features of the AirPod using the Bluetooth protocol?
You claimed other manufacturers have “figured this out” - how?
Every single thing that you say Apple should do is about how Apple can do that in a method that conforms to the spec - you kind of have to “fixate” upon the spec if you claim that Apple isn’t conforming to the spec.
The battery reporting is the one you brought up and had only horrible ideas.
Immich has an iPhone app that should be able to pull photos from your photo library (and thus iCloud Photos) and upload them to Immich, but it might take a while compared to uploading from a Mac.
reply