iOS 26.2 to Open Up iPhone–Apple Watch Wi-Fi Sync in EU
John Gruber (Mastodon) has a great post with new details about exactly what’s happening with sharing iPhone Wi-Fi network information in iOS 16.2. In brief, I think this turns the story on its head. The way this has been reported and discussed since November 4 seems to be wrong and almost backwards. First, I want to get into the facts of the situation, which I believe (but cannot independently verify) that Gruber has entirely correct. Second, I think there’s an interesting media story about how everyone got the wrong impression. And third, I have responses to some of Gruber’s explanations and opinions on Apple’s approach. First, the facts:
Apple is complying with the DMA, and they’re not disabling Wi-Fi network synchronization between an iPhone and a paired Apple Watch. What Apple is doing, in order to comply with the DMA, is changing how Wi-Fi networks sync with Apple Watch (in the EU), and offering new APIs in the EU for third-party paired devices to put them on equal (or near-equal?) footing with Apple Watch (in the EU).
[…]
The EU mandate to Apple is not that Apple must grant to third-party devices and their iOS companion applications this same functionality as it stands today — that is to say, access to the entire history of the iPhone’s known Wi-Fi networks. The EU mandate is that Apple must grant to third-party devices the same level of access to Wi-Fi network information that Apple Watch has. Apple is complying with this mandate in two ways: (a) by changing how much Wi-Fi network information an Apple Watch gets from the iPhone to which it is paired; and (b) creating a new framework in iOS 26.2 (gated by a new entitlement), Wi-Fi Infrastructure, that provides a set of public APIs, available only to apps in the EU, to (per the framework’s description) “share Wi-Fi network credentials securely between devices and connected accessories.”
[…]
The change for Apple Watch in the EU is that starting with iOS 26.2, when a new (or reset) Apple Watch is set up, the Apple Watch will no longer have the user’s list of saved Wi-Fi networks automatically synced from their iPhone. Only future networks will be synced — the same level of access that the new Wi-Fi Infrastructure framework is making available to third-party accessories.
I think the high-level takeaway is that Apple is not removing the network syncing feature. They’re actually keeping nearly all of the functionality, removing self-preferencing, and opening it up to third parties. As Gruber says, most Apple Watch users in the EU probably won’t even notice.
I think the restriction on historical network information is kind of weird. If an EU user buys a new phone and watch the day 26.2 is released, the watch gets all the info. But if a user who already has a phone gets a new watch (or perhaps replaces an existing watch?), that watch will never get the info for the older networks that the phone knows about unless the user physically goes back to those locations with the phone. The watch gets open-ended access to all the data going forward, but data from yesterday is forbidden. That seems confusing. Why is sharing the older data not even an option? You could argue that users wouldn’t understand what they are consenting to sharing, because they don’t remember where they’ve been. But the list of networks is visible on the iPhone and, probably, users will forget all about this setting when visiting new networks in the coming years, anyway.
Maybe the idea is that this is for the more technical user who wants to micromanage the data sharing. Maybe there’s a particular sensitive network that they don’t want the watch (or other third-party device) to know about. In that case, Apple’s implementation frees them from worrying about the past, and then going forward they can choose not to join that network on their phone to prevent it from syncing to the watch. This seems far-fetched to me and not very useful. Such a user would prefer to be able to use the Wi-Fi on their phone but also to be able to mark that network as private so that it doesn’t sync. Remembering not to connect is error-prone.
I also don’t really see why Apple cares so much about the SSID data. They’re happy to let you share other retroactive information like your contacts and your entire photo library, complete with time- and GPS-stamped photos. Is the rather coarse SSID information really that useful to data brokers?
The EU mandate to Apple is not that Apple must grant to third-party devices and their iOS companion applications this same functionality as it stands today[…] The EU mandate is that Apple must grant to third-party devices the same level of access to Wi-Fi network information that Apple Watch has.
The EU mandate doesn’t seem to address the biggest difference in functionality, which is that Apple Watch can piggyback on the iPhone’s connection to access captive Wi-Fi networks, but third-party watches can’t. The Wi-Fi syncing feature always had an (awkward) workaround, which is that a third-party device could manually log into a Wi-Fi network by typing its password. But it’s not really possible for a small-screened device to go through the prompts for accessing a captive network. Apple Watch doesn’t even try to offer this feature—it just gives the watch special access through the phone. I think this is way more useful than the password-syncing feature.
The news was broken by Nicolas Lellouche, reporting for the French-language site Numerama.
[…]
Lellouche’s report at Numerama broke this story (the reports at MacRumors and 9to5Mac are both based on Numerama’s), but the above is not an accurate summary of what Apple is doing with iOS 26.2.
How did this happen? The (translated) language, “Apple announced to Numerama that it had made the decision to disable Wi-Fi synchronization,” gives the impression that Apple reached out to Lellouche to tell him that they were removing the syncing feature in iOS 26.2. But why would Apple do that when it’s nearly the opposite of what they’re actually doing? If they were trying to tell Lellouche something else, and he misunderstood, why did Apple let the misinformation spread all around the Web without ever getting back in touch with him to correct the record? Why let everyone think that, as a result of the DMA, the functionality of Apple Watch in the EU will be significantly degraded?
I can think of two possibilities, neither a satisfying explanation. First, maybe Apple wanted to spread this misinformation as part of its anti-DMA PR crusade. They told Lellouche something that was technically true but missing the full context so that he concluded the worst. Evidence for this theory is that Apple PR has a high level of competence, so you’d think they’d notice if Lellouche misreported what they told him. Evidence against is that it seems like a pretty dumb strategy. Also, the API is publicly documented and was announced at WWDC.
The other theory is that Lellouche initiated the communication with Apple. Maybe he asked them a very precise question and got a narrow answer that was correct but gave the wrong overall impression. This might explain why Apple wasn’t closely following him to send a correction, but I have a hard time thinking how he could have phrased the question to end up in this situation and why Apple wouldn’t have been more careful to convey the full story.
There’s a similar mystery around the AirPods Live Translation feature. Apple first announced that it would not be available in the EU and then later said that it would be available but that it was delayed due to “additional engineering work” that the DMA required. It’s still unclear what that work was and what the state of the feature and third-party support are. Apple had said that it was “illegal” for them to “share these features with Apple users until we bring them to other companies’ products,” but there’s been no announcement that they’re doing the latter. Apple seems to be going out of its way not to tell us what’s actually happening. Oddly, Lellouche didn’t mention the Wi-Fi API but does mention a forthcoming multi-stream audio API that I haven’t seen documented or reported on by anyone else.
Back to Gruber:
There’s a reason why Apple isn’t offering the new Wi-Fi Infrastructure framework outside the EU, and that’s because they don’t believe it’s a good idea to grant any access at all to your saved Wi-Fi networks to third-party apps and devices. Especially without being able to specify, let alone enforce, a policy that Wi-Fi network information should be treated the way Apple treats it — remaining exclusively on device.
I don’t think Apple keeps it on-device, either. Doesn’t Wi-Fi information sync up to Apple’s servers through iCloud Keychain? And users don’t really have control over this because if you disable iCloud Keychain you can’t use passkeys. Not that I think iCloud Keychain is insecure, but this is a double-standard. There’s no enforcement for what Apple’s doing, either. We have to assume its good intent and lack of design flaws and bugs, but there’s no option to extend that courtesy to other companies.
The skeptical take […] that Apple’s intention here is, somehow, primarily about trying to drive anti-DMA sentiment amongst its EU users. […] Part of what makes this particular situation clarifying is that it’s so specific […] very few Apple Watch owners in the EU are likely to notice the change.
As described above, I don’t think Apple’s carve out for the historical data makes much sense, so I find this anything but clarifying. It’s odd how they got into this situation where there was lots of press coverage about how the EU was ruining Apple Watch, yet most Apple Watch owners won’t notice a change. They kind of got to have their cake and eat it, too.
If Apple were motivated by spite, and were trying to turn EU Apple Watch owners against the DMA, they’d just remove all Wi-Fi network syncing between the watch and its paired iPhone.
They wouldn’t do that because they would get blamed for obvious malicious compliance.
Tsai is making a few wrong assumptions here. First, Apple is enabling users (in the EU) to opt into having their iPhone share Wi-Fi information with third-party devices. Second, this mandate is not specific to smartwatches — it applies to any devices that can pair with an iPhone and have corresponding iOS partner apps. So Meta, with their lineup of smartglasses, does have corresponding devices. And, per Apple’s public statements, it is Meta in particular that has been zealously pursuing interoperability mandates pursuant to the DMA. I think it’s entirely possible that this entire issue regarding Wi-Fi network sharing was prompted by Meta’s interoperability requests to the European Commission.
My first wrong assumption was due the report from Lellouche, seemingly the only person (at the time) who got an official statement from Apple on this. For the second, I could see not buying Meta glasses on principle, and I could see buying them and wanting everything to “just work,” but I don’t see buying them and wanting to manually manage which Wi-Fi they have access to. You trust Meta enough to wear their device that records audio and video and talks to their servers, but you draw the line at letting it know which Wi-Fi network you’re on?
The “it should be up to the user” take benefits informed, technically savvy users. The “it shouldn’t be possible” take benefits uninformed, un-savvy users — users who in many cases have decided that they simply trust Apple.
No, it depends on whether the company receiving the data is unscrupulous. If Apple prevents a useful integration that was not actually dangerous, that is not a benefit to the user. Instead of Meta, imagine if a company like Panic made a device. I bet there are customers who trust Panic more than Apple. Also, adding friction disproportionately hurts the un-savvy users.
For at least the last 15 years, I’ve repeatedly emphasized that Apple’s priorities are in this order: Apple first, users second, developers third. The DMA attempts to invert that order, privileging developers first (in the ostensible name of fair competition with Apple, a designated “gatekeeper”), ahead of users, and ahead of Apple itself. So of course Apple is going to object to and resist mandates that require it to subordinate its own strategic desires — its own sense of how its products ought to be designed and engineered — especially when the primary beneficiary of the mandates aren’t users, but developers.
I disagree that the DMA is putting developers ahead of users. If a user buys two products from different companies and wants them to work better together, that’s a benefit to the user. If the users care about privacy and the developer doesn’t, they can choose not to buy the product, and then the developer doesn’t benefit.
The clearest example of that is the App Store. It’s overwhelmingly developers, not users, who object to the App Store model[…]. Users largely don’t have a problem with any of that. […] Users love the App Store model. With Apple in particular, users, by and large, like the idea that the platforms have stringent guardrails. Many buy iPhones because Apple exerts such control over the platform, not despite it.
I think users don’t have much visibility into what they’re missing and that Apple is in large part selling a false sense of security. For example, take the recent case of the Tea app, whose breach exposed user data that its App Store privacy nutrition label claimed it wasn’t even collecting. With so many factors (iPhone hardware, iOS, sandboxing, the App Store, the available apps) all tangled together, we don’t have a clear way of measuring what users actually care about. The clearest place to compare is probably the Mac, where the App Store model is optional, but the Mac App Store is at best a mixed bag. In some cases it’s easier, in some cases it isn’t. It’s full of scams and fake reviews but is missing many top apps. Whether or not you like it, it’s hardly a top reason to choose a Mac instead of a Windows PC.
Apple’s perspective is that protecting their customers’ privacy is, in fact, Apple’s responsibility — and one of their most important responsibilities at that. It’s illegal to steal cars, but every carmaker still puts locks on the doors and requires a key to start the engine. In numerous ways, Apple sees the DMA as mandating, privacy-wise, that they create something akin to cars that don’t require keys, trusting EU law to keep them from being stolen.
I see it more like Apple wants the car keys to be locked to your DNA, and the EU wants to make sure that you can hand them to your friend or mechanic.
You can reasonably make the case — and expert-level users (read: nerds) often do — that the user should always be in control. I bought the device, I should be able to run whatever software, with whatever privileges, I want. That perspective is valid, but it also describes a class of devices — PCs — that privilege the autonomy of third-party developers over the vendor-controlled stability of the OS.
Again, I object to this framing that if an expert user wants it, that’s preferencing developers. Their interests overlap but are not the same. For example, maybe I want to analyze my own Wi-Fi history even though I have no interest in developing a networking product. I can’t process that data because iOS doesn’t let me export it.
It’s always about trade-offs. And with this particular trade-off, it’s very clear which model is more successful in the market.
We have no true apples-to-apples comparison. Even if we did and the open option were less popular, I’m not sure what we should conclude from that. There are plenty of examples where society rightly chooses to protect the interests of groups that are outnumbered. Sometimes they also have companies advocating on their behalf for self-interested reasons. That doesn’t mean that there aren’t also good reasons or that the protections aren’t worthwhile.
Previously:
- Apple-Funded Study on EU Alternative App Store Business Terms
- iOS 26.2 to Remove iPhone–Apple Watch Wi-Fi Sync in EU
- AirPods Live Translation Expands to the EU
- Meta Ray-Ban Display
- Apple’s Thoughts on the DMA
- AirPods Live Translation Blocked for EU Users
- Apple Restricts Pebble From Being Awesome With iPhones
- Meta’s iOS Interoperability Requests
- DMA Compliance: Alternative Browser Engines
Update (2025-12-01): René Fouquet:
My cynical take is that Apple deliberately leaked technically incomplete information in order to provoke DMA-critical reporting. Apple continues to employ the tactic of spreading as much public resentment as possible among its users in the EU towards the EU.
The alternative seems to be that Apple was unaware of the misinformation being spread in their name or simply didn’t care.
20 Comments RSS · Twitter · Mastodon
Gruber with the dumbest takes, as usual. Even when they spat in his face, he still tows the company sales pitches.
> Re: I don’t think Apple keeps it on-device, either. Doesn’t Wi-Fi information sync up to Apple’s servers through iCloud Keychain?
It certainly has kept WIFI info on device only. If you set up a new device any other way than old device to new device directly or restoring from an encrypted backup on a Mac you do not get your WIFI authentification information. Setting up from an unencrypted Mac backup or from iCloud and you have to reset up all your WIFi networks.
@Liam: I'm not so sure about that. I got a new Mac running Sequoia just a couple weeks ago. It hasn't left work, where it was delivered, and by being signed in to my iCloud account is has the same 60+ WiFi credentials as my old laptop. I didn't do any information transfer from one Mac to another nor did I set up from a Time Machine backup. I'd think it's iCloud Keychain or, similarly, the Passwords app (from my iOS device).
"I’ve repeatedly emphasized that Apple’s priorities are in this order: Apple first, users second, developers third. The DMA attempts to invert that order"
The DMA attempts to put Apple and third-party devs on the same level, which should put users first.
There is a third possibility, a bit Hanlon razor-ish, is that the local Apple PR team didn't considered the Numerama's article as false, and may not have the same "high level of competence" that the HQ one. The local PR team may have misinterpreted Apple's update just like the journalist, either because it's quite complicated or because the technical team that briefed them internally wasn't precise enough (or at least not as precise as Gruber). Other PR teams may not care as much about DMA, and overlooked it too. Maybe at some point, when it reached the other side of the Atlantic, they could have tried to correct it and release a new statement, but maybe this angle is fine with them for now, so they can appear to compromise later.
Apple would be able to build their devices however they wished even if they complied with the DMA. They wouldn't be able to put up fake barriers to lock users in, but their integrations with their headphones, styluses etc would be just as smooth.
Sure, some people would opt for better alternatives, or cheaper ones, that could connect just as easily, but I don't see people getting that choice as bad.
I absolutely believe that 90% would keep using Apples App store even if there was an alternative.
Great post. I enjoyed your well-reasoned pushback against Gruber’s illogical takes. He really twists himself in knots to justify apple’s bad decisions sometimes. And this is an example of that
@Liam If I open Keychain Access, I see all the Wi-Fi passwords in iCloud Keychain.
@Nicolas That could certainly be it, though I would have thought the main PR team would notice when it was all around the English-speaking media. So at minimum they must have been fine with that narrative or they would have sent someone a tip that it was wrong. (Apple PR didn’t feed this to Gruber; he reached out to them to figure what was going on, presumably because the original story was so strange.)
@Plume, “The DMA attempts to put Apple and third-party devs on the same level, which should put users first.”
Why would you think that elevating developers would put users first? Has that happened well for us in the past?
I mean, thata very neoliberal, American, ‘let liability and the market figure things out (while the users pay the consequences)” take on power relations., which, as I understand it, is actually not the usual EU take on things.
Also, don’t you not pay for any services from any big FAANG companies? So what’s your leverage as a user/consumer here? You can’t boycott something you don’t use/pay for.
@Michael, I think that sharing historical wifi is a bad idea because there are way more security implications than most, even moderately sophisticated, users can imagine. Not sharing them is a pretty hard line for privacy — one that I as an informed user appreciate. A pain, yes, but a smart one.
How it might work: I suspect that the new EU Mac/iOS screen for signing into new wifi networks will have reminders or permissions about who you’re sharing new wifi passwords with. i.e. on the wifi password screen, you get to pick who you share the wifi password with before you join the network. That’s a pain, but it certainly will remind users who they’re sharing their info with.
That would maintain some finer-grained privacy/security, as well as constantly reminding/asking the user who gets access to what.
Even better/more clever might be if Apple were to put those approved shared SSID/passwords are in some secure enclave — hashed on the device — so that the third party can join known wifi networks, but the third party never gets the SSID or password pair. If Apple doesn’t have plaintext access to the SSID/password pair, why should the third party?
Anyway, like Jobs said at some keynote or other: ask the user, inform them, and ask them again when it comes to privacy. It’s always a balancing act between privacy and convenience — this is part of that dance.
“ I’ve repeatedly emphasized that Apple’s priorities are in this order: Apple first, users second, developers third. The DMA attempts to invert that order, privileging developers first (in the ostensible name of fair competition with Apple, a designated “gatekeeper”), ahead of users, and ahead of Apple itself.”
Gruber succinctly explaining why he looks so ridiculous, as a user, despite his best attempts to be a company mouthpiece, getting crying-blood angry on behalf of a company that won’t even talk to him at their birthday party anymore.
Anything that benefits developers benefits users too. Yes, bad actors and all that. But let me decide my own safety and comfort.
@Someone else It doesn’t sound like they’re doing that sort of fine-grained approach. I don’t see how a blanket approval for the future is much different from a blanket approval for the past. Apple’s code on the device does have access to the plaintext. But it sounds like they’re more worried about the SSIDs than the passwords, anyway.
Just because Gruber's take happens to align with Apple's most of the time doesn't mean that what he's saying is illogical or that he's a shill for the company. He calls them out when he disagrees. Of course, that doesn't mean that Tsai's post is any less "well reasoned". They just have different opinions, and that's fine.
Tsai: "I think users don’t have much visibility into what they’re missing..." I think this is true in general.
There should be a setting to allow/disallow third party access to this kind of info, and it should be set to 'disallow' by default, with a warning message if you decide to turn it on.
@DJ Yeah, I disagree with some Gruber’s opinions there, but I think they’re his honest beliefs and that he did a good job of explaining that point of view.
I definitely lean towards letting the user opt into sharing data or doing pretty much anything else with their device.
@Michael, Yes, the Apple device has access to the SSID/password keypair so that it can pair, but it can presumably be decrypted on-device only at the moment of use and that Apple the company doesn’t have access to it. (I really don’t know if it’s the case, nor do any of us, really, but from what I can tell, they don’t look at it at the corporate level — , mostly because: why would they? Also, they seem to say as much: passwords are E2E encrypted and Apple doesn’t have the key and presumably Apple doesn’t look at that even in icloud backups without a subpoena, per their track record).
Facebook, Google, etc. would love access to the keypair, ideally with your GPS location or address, though.
Knowing SSID is useful so that — even without connecting to a network — one can tell where someone is by also looking at nearby SSIDs at the same location (assuming you’ve granted the app/device network access, which in recent years, Apple’s dialog has gotten more explicit about what’s being shared and how it can be used to determine your location). Turn-of-the millenium tech but it still works great. No GPS needed on the device.
@Someone else Yes, my point is that this is another case where people say “Apple doesn’t have access” to mean that it technically does have access but they believe it chooses not to use that access. But then when the exact same situation involves another company they assume it’s secretly phoning everything home.
Yes, so Apple is OK with sharing SSIDs that would reveal where the user currently is but not where they were years ago.
Yes, but Apple presents itself as the privacy company. That doesn't mean that they don't sometimes find a bug that needs to be fixed, or a court order that they have to comply with, but they're careful to position themselves as being protective of user data. Other companies, not so much. Google and Meta are quick to offer user data to anyone to make a buck. Meta seems to be especially slimy in this regard, imo.
"Why would you think that elevating developers would put users first?"
Because companies will be competing for users.
"Has that happened well for us in the past?"
Yes. Before every system was a walled garden.
