I Diffed iOS 27.2 RC. The Release Notes Weren’t the Story.

The build dropped October 19. 24B115. By the time I’d pulled the release notes page for iOS 27.2 RC, I already knew what I’d find in the security section: nothing I could act on. Point releases get a changelog aimed at people who care about Messages reactions, and a security-content page that stays a stub until the day GA ships. If you run identity for a fleet, that stub is the problem. Your Sign in with Apple validation, your Passkey registration, your LAContext prompts—none of it is in those notes, and some of it moves anyway.

So I stopped reading the notes and started diffing the frameworks. Seven days, two devices, one IPSW on each OS. Here’s the methodology and what it’s actually for.

The diff, not the changelog

You don’t need a jailbreak and you don’t need to guess. Pull both IPSWs, crack the dyld shared cache, and compare the frameworks that matter: AuthenticationServices, LocalAuthentication, DeviceManagement, CryptoKit, Security. blacktop’s ipsw tool does the heavy lifting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# grab both builds, extract the shared caches
ipsw download ipsw --device iPhone17,1 --build 24A348   # 27.1 GA
ipsw download ipsw --device iPhone17,1 --build 24B115   # 27.2 RC
​
ipsw extract --dyld 27.1_*.ipsw -o ./271
ipsw extract --dyld 27.2_*.ipsw -o ./272
​
# symbol-level diff of the one framework an auth engineer cares about
ipsw dyld symaddr ./271/dyld_shared_cache_arm64e \
  --image AuthenticationServices | sort > as_271.txt
ipsw dyld symaddr ./272/dyld_shared_cache_arm64e \
  --image AuthenticationServices | sort > as_272.txt
​
diff as_271.txt as_272.txt

New exported symbols, removed selectors, bumped framework Info.plist versions—that’s your real changelog. Do the same for the LocalAuthentication binary. Then grep the shared cache for string constants: new LAError codes or entitlement keys show up as literals long before anyone documents them. A point release usually gives you a short, boring diff. Boring is the win. A short diff you’ve verified beats an empty changelog you trusted.

This is the part where my colleague—call him the one who’s been burned by my “quick checks” before—starts pushing back.

“You spent a week on a point release. Apple has never once documented an identity change in a .2. Why is this different?”

It isn’t different. That’s the point. They don’t document these, which is exactly why the diff exists. The 2 a.m. incident I’m insuring against isn’t a headline CVE—it’s a silent change to evaluatedPolicyDomainState behaviour that invalidates every biometric-gated session in a managed app the morning the fleet auto-updates. No note. No warning. Just a help desk queue.

“Fine, but your server validates SIWA tokens. That logic lives on your box, not the phone. The RC can’t touch it.”

Mostly right, and that’s the trap. The token is signed by Apple’s keys, served from https://appleid.apple.com/auth/keys, and those rotate on Apple’s schedule regardless of any iOS build. What the client build can change is the shape of what lands in your callback—whether a user gets issued a private-relay address, whether email_verified comes through as a string or a bool, whether the nonce round-trips when the system flow is reconstructed after an OS update. So validate the token properly, every field, and don’t assume the client gave you what it gave you last month.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import JWTKit
​
struct AppleIdentityToken: JWTPayload {
    let iss: IssuerClaim          // must equal https://appleid.apple.com
    let aud: AudienceClaim        // must equal your client_id / bundle id
    let exp: ExpirationClaim
    let sub: SubjectClaim         // the stable user id — trust this, not email
    let email: String?
    let emailVerified: BoolClaim? // type can vary; validate defensively
    let isPrivateEmail: BoolClaim?
    let nonce: String?
​
    func verify(using _: some JWTAlgorithm) throws {
        try exp.verifyNotExpired()
        guard iss.value == "https://appleid.apple.com" else {
            throw JWTError.claimVerificationFailure(
                failedClaim: iss, reason: "unexpected issuer")
        }
    }
}

Run a real token from the RC through that. If is_private_email flips on for a test account that never had it, your downstream email-matching logic is the thing that breaks—not Apple.

The LAContext trap

The field to watch is evaluatedPolicyDomainState: a blob that changes whenever the enrolled biometric set changes. Plenty of apps persist it and refuse a cached credential if it moves—reasonable defence against someone adding a face. The sharp edge is that an OS update can legitimately change how that blob is derived. If it does, every device in your fleet looks like it re-enrolled Face ID the moment it updates, and every biometric-gated keychain item needs a fresh prompt. That’s the forward-looking risk the RC exists to rule out.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import LocalAuthentication
​
let ctx = LAContext()
var error: NSError?
​
guard ctx.canEvaluatePolicy(
    .deviceOwnerAuthenticationWithBiometrics, error: &error) else {
    // log LAError code AND biometryType before/after the RC
    print("unavailable:", error?.code ?? -1, ctx.biometryType.rawValue)
    return
}
​
// snapshot this on 27.1, snapshot again on 27.2.
// if it differs with no re-enrollment, your invalidation logic fires fleet-wide.
let state = ctx.evaluatedPolicyDomainState?.base64EncodedString() ?? "nil"
print("domainState:", state, "biometry:", ctx.biometryType.rawValue)

Compare the two snapshots. Same device, same enrolled face, only the OS changed. If the blob is stable, you ship with confidence. If it isn’t, you’ve just found the thing worth a week.

“And MDM? You’re going to tell me to re-test enrollment for a point release too.”

Enrollment, no. Declarative device management, yes—watch the status channel. DDM status reports are where Apple quietly adds or reshapes keys, and your server is supposed to tolerate unknown ones. A point release that tightens a declaration’s required predicate, or starts reporting a new key path, won’t announce itself. Push your existing declarations to an RC device and read what comes back.

1
2
3
4
5
6
7
8
9

<dict>
    <key>StatusItems</key>
    <dict>
        <key>management.declarations</key>
        <true/>
        <key>device.operating-system.version</key>
        <true/>
    </dict>
</dict>

If your status subscription handler throws on an unexpected key instead of logging and moving on, that’s a bug you own, and the RC is a free place to find it.

What the week bought me

If Apple ships a companion Xcode 27.2 RC, it matters here too: should the SDK bump a deployment target or change a default entitlement for AuthenticationServices, you want to recompile your auth-critical app against it now, not discover it in App Store review after GA. Build, run the Passkey registration and assertion flow end to end against a real relying party, confirm the associated-domains fetch still resolves your apple-app-site-association.

Historically a .2 RC goes GA inside a week to ten days. Call it October 27 to 29, give or take. That’s your window. Devices on automatic updates will take the GA build whether your validation server is ready or not, and “we didn’t know it changed” has never once worked as an incident post-mortem.

Read the release notes. Then don’t believe them. The diff is the document Apple didn’t write, and for once you get to read it before your users do.