Three things that broke in watchOS 27.0.1: none of them

A point release that ships with a download pointer and no release notes is not a bug. It’s a dare. Apple is quietly betting you’ll push it to the fleet without checking, and nine times out of ten that bet pays off. The tenth time is a wave of “my Mac won’t auto-unlock anymore” tickets that nobody traces back to a Watch update for three days.

So I checked. Here’s the timeline, and what each beat actually meant for a Watch fleet carrying passkeys, Auto Unlock, and Wallet credentials.

Sep 25 — macOS 27.0.1 cleared

The desk signed off on macOS 27.0.1 three days before the Watch release dropped. That matters less than it looks. macOS and watchOS share frameworks by name, not by binary — a clean Mac point release tells you nothing about what shipped to the wrist. It just set the expectation: another quiet maintenance drop, probably clean, verify anyway.

Sep 28 — watchOS 27.0.1 (24R365) ships

Build 24R365. The developer releases page carried the download and effectively nothing else — no feature notes, no security content page at the time of writing. For a .0.1 that’s normal. It also means the only honest way to answer “does this touch authentication?” is to go look, not to read a changelog that doesn’t exist.

The first thing worth knowing is structural, and it kills half the panic before you start: a point release ships no new SDK. watchOS 27.0.1 builds against the same watchOS 27.0 SDK you already have in Xcode. The exported symbol surface of LocalAuthentication, AuthenticationServices, and the Security framework is therefore identical to 27.0 by definition. There is no new API to break your code, because there is no new API.

1
2
3
4
5
6
7

SDK=$(xcrun --sdk watchos --show-sdk-path)
​
# TBD stubs define the exported surface. No SDK bump = byte-identical stubs.
for F in LocalAuthentication AuthenticationServices Security; do
  shasum -a 256 "$SDK/System/Library/Frameworks/$F.framework/$F.tbd"
done
# Compare against the hashes you recorded at 27.0 GA. They match. They have to.

That covers the “did the API change” question for LocalAuthentication: no. What a point release can change is the implementation behind those symbols — and no symbol diff on earth catches that. Which is where the real work starts.

Sep 29 — the checks that symbol diffs can’t answer

Four surfaces the brief asked about. Three of them are boring, and boring is the correct outcome.

LocalAuthentication. Worth saying plainly because people keep getting it wrong: the Apple Watch has no Face ID and no Touch ID. The biometric policy is unavailable on the Watch by design, not because of this update. If your watch app gates something on .deviceOwnerAuthenticationWithBiometrics, it was already returning false before 24R365, and it still does.

1
2
3
4
5
6
7
8
9
10

import LocalAuthentication
​
let ctx = LAContext()
var error: NSError?
​
// false on watchOS — the Watch has no biometric sensors.
let bio = ctx.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error)
​
// true — passcode plus wrist detection is the Watch's owner-authentication story.
let any = ctx.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error)

Behaviour of both calls is unchanged post-update. The thing to protect is wrist detection: as long as the Watch stays unlocked on-wrist, the authenticated session holds. 24R365 doesn’t move that.

Passkeys / FIDO2. The Watch doesn’t mint platform passkeys on its own Secure Enclave the way an iPhone does. It consumes credentials that live in iCloud Keychain and sync down, then performs assertions through ASAuthorizationPlatformPublicKeyCredentialProvider. So the question isn’t “did passkey storage change on the Watch” — there’s barely any local storage to change — it’s “does sync still flow.” It does. Sign a Watch into a test account, confirm the synced credential is present, run an assertion. Mine completed with no new prompts and no re-registration.

Secure Enclave. The Watch has an SEP, and keys created with kSecAttrTokenIDSecureEnclave stay non-exportable the way they should. No SDK bump means no change to that API surface, and a round-trip create-sign-verify against a SE-bound key behaved exactly as it did on 27.0. Nothing to see, which is the point.

Sep 30 — the one that was actually worth the hour

Watch unlock for Mac. This is the check that earns its keep, because it’s the only one that fails silently and the only one that doesn’t live inside a framework you can diff. Auto Unlock and approve-with-Watch ride a continuity daemon and a secure proximity handshake — BLE range, wrist detection, both devices on the same Apple Account with two-factor. A Watch point release can regress that pathway without touching a single public symbol, and when it does, nobody gets an error dialog. They just start typing their Mac password again and quietly file a ticket.

So I tested it the only way that counts: on-wrist, unlocked Watch, lid open, walk up to a sleeping Mac. Unlock fired at the usual range. Then a sudo prompt, approved with a double-click on the side button. Both paths clean on 24R365. If you verify one thing before you push this build, verify this one.

Oct 1 — clearance

Ship it. watchOS 27.0.1 (24R365) does not touch the authentication surface in any way that gates a supervised deployment: no SDK change, no LocalAuthentication behaviour change, passkey sync intact, Secure Enclave untouched, Auto Unlock working. Push to your ring-0 pilot, run the Auto Unlock walk-up once because it’s the cheap insurance, then release the ring broadly.

One beat is still open on the calendar. As of this writing Apple hadn’t posted the security content page for 24R365 — just the download. When it lands, cross-check the CVE list against your actual exposure; a quiet point release with a late-published security page is usually fixing something that mattered, even if none of it was wearing an authentication badge. I’m not going to invent what’s on a page that doesn’t exist yet. Check it when it posts.