Archive for November 25, 2025

Tuesday, November 25, 2025

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 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:

Copyright © 2000–2025 Michael Tsai.