Your HealthKit completion handler reports success = YES, but no permission was ever granted. UserDefaults.standard.integer(forKey:) crashes inside App.init(). A system extension that worked all last year now fails with errno 13 for half your customers. These are not edge cases — they are real regressions that shipped in iOS 26.5 and iOS 27 beta 1, and they are the texture of supporting Apple platforms in 2026.

This post walks through the four worst regressions I have seen in the current beta cycle, the actual root causes, and the defensive code patterns that keep your app working while Apple’s Feedback Assistant queue does its slow work.

The HealthKit Blood Pressure trap on iOS 26.5

Starting with iOS 26.5 RC1 (build 23F75), requesting HKQuantityTypeIdentifierBloodPressureSystolic and HKQuantityTypeIdentifierBloodPressureDiastolic is silently broken. If you request Blood Pressure alone, a modal flashes and dismisses. If you request it alongside other types, the dialog appears for everything except Blood Pressure. In both cases the completion handler returns success = true, error = nil — so your code believes the user said yes.

The user can fix it manually in Settings → Privacy & Security → Health → [your app], but they won’t, because nothing in your UI told them anything was wrong.

The defensive pattern

Never trust the success flag from requestAuthorization. Apple’s own getRequestStatusForAuthorization(toShare:read:completion:) is the source of truth.

import HealthKit

let store = HKHealthStore()
let bpTypes: Set<HKSampleType> = [
    HKQuantityType(.bloodPressureSystolic),
    HKQuantityType(.bloodPressureDiastolic)
]

store.requestAuthorization(toShare: bpTypes, read: bpTypes) { success, error in
    // Do NOT trust `success` on iOS 26.5.
    store.getRequestStatusForAuthorization(toShare: bpTypes, read: bpTypes) { status, statusError in
        switch status {
        case .unnecessary:
            break
        case .shouldRequest:
            DispatchQueue.main.async { self.showHealthSettingsHint() }
        case .unknown:
            DispatchQueue.main.async { self.showHealthSettingsHint() }
        @unknown default:
            break
        }
    }
}

If status stays .shouldRequest after a request that “succeeded”, show an in-app banner that deep-links to the Health privacy pane. Apple included an attempted fix in iOS 26.6 beta 2 (build 23G5043d), but until your usage telemetry shows most of your users off 26.5.x, keep the status check in place.

UserDefaults.standard.integer(forKey:) crashes on iOS 27 beta 1

On iOS 27 beta 1, iPadOS 27 beta 1, and visionOS 27 beta 1, calling UserDefaults.standard.integer(forKey:) from a singleton initializer during App.init() crashes with EXC_BAD_ACCESS (code=1, address=0x0). The contract for integer(forKey:) is to return 0 when the key is missing — instead, the runtime dereferences a null pointer. The reporting developer filed FB23310748.

Two ways to protect yourself

First, register defaults early — before any read:

@main
struct MyApp: App {
    init() {
        UserDefaults.standard.register(defaults: [
            "launchCount": 0,
            "lastSyncTimestamp": 0,
            "preferredTheme": "system"
        ])
    }

    var body: some Scene {
        WindowGroup { ContentView() }
    }
}

The register(defaults:) call seeds the in-memory defaults domain so any subsequent read returns a real value.

Second, defer the read. Don’t pull values out of UserDefaults from a singleton’s stored properties. Make them lazy and read on first use:

final class Settings {
    static let shared = Settings()
    private init() {}

    private(set) lazy var launchCount: Int = {
        UserDefaults.standard.integer(forKey: "launchCount")
    }()
}

NEURLFilter and the hardcoded UID 501 assumption

If you ship a Network Extension that uses NEURLFilter, you have an invisible bug on any Mac whose primary user is not UID 501. Apple’s implementation is wired to UID 501 — so on migrated Macs, MDM-provisioned fleets, or any host with a recreated primary account, you get errno 13 (Permission denied) and silent NEBloomFilter failures. This is tracked as FB22281393 and FB23265799.

1. Check the primary user’s UID at install time. If it isn’t 501, show a clear degraded-feature notice.
2. Log NEBloomFilter failures explicitly.
3. File your own duplicate Feedback Assistant report referencing FB22281393.

Virtualizing macOS 27 from a macOS 26 host

The macOS 27 IPSW will not install cleanly via VZMacOSInstaller on a macOS 26.6 host — installs stall at 77–78%. An Apple systems engineer confirmed the incompatibility.

Three viable paths:

1. Create the VM on a macOS 27 host, then move the bundle back.
2. Upgrade an existing macOS 26 VM in-place via Software Update → Beta Updates.
3. Use VirtualBuddy 2.2 beta 2 — ships macOS 27 IPSW support on macOS 26 hosts before Apple’s own tooling.

Do not install the Xcode 27 beta on your CI host yet. It breaks VM creation entirely.

A defensive checklist for every beta cycle

• Never trust completion-handler success flags alone. Re-query authorization via the dedicated read API.
• Register all UserDefaults keys explicitly in App.init(). Combine with lazy reads.
• Log every failure that the framework “handles” for you.
• Pin your CI Xcode version.
• File Feedback Assistant reports as duplicates, referencing existing FB numbers.

Apple’s Feedback Assistant queue is what it is. Your code can be ready anyway.

---