[LucaCappelletti94]

Enables the blanket safety defaults for DeviceCheck, which makes DCDevice and the DCAppAttestService instance methods safe. Their completion handlers already take a SendableBlock, and on macOS 26.6.2 the token handler does run on a framework thread, so nothing more is needed there.

DCAppAttestService::sharedService stays unsafe. Every instance method first goes through -[DCAppAttestService appAttestController], which creates its controller lazily with a plain load, store and release of the previous value, and sharedService hands that one instance to every thread. Calling isSupported from eight threads on a fresh instance crashes within a thousand rounds on macOS 15.7.9, 26.6.2 and 27.0.1, while the same harness with the controller created beforehand runs cleanly (FB25187723). An instance from new is neither Send nor Sync, so its methods stay safe.

App Attest only works on iOS and iPadOS, since isSupported answers NO on a Mac. The iOS 26.1 decompilation shows the same lazy _appAttestController getter, while the iOS 18.2 one has no such ivar.

Code that forbids unsafe still cannot read the *mut NSData and *mut NSError these handlers receive until #837 lands.

The regenerated bindings are in the generated fork.

[madsmtm]

Thanks for working on this.

Same as with #864, could I get you to file a FB with Apple about this?

---

Surprisingly, we probably could work around this by adding this to lib.rs:

// #[ctor]
#[used]
#[link_section = "__DATA,__mod_init_func,mod_init_funcs"]
static INIT: extern "C" fn() = {
    extern "C" fn init() {
        let service = DCAppAttestService::sharedService();
        service.isSupported();
        service.xyz();
    }
    init
};

Not sure how good of an idea this would be though, since the user could (very theoretically) still end up in a situation where they themselves spawn threads and use DCAppAttestService from a ctor that runs before this one, so I'd prefer to wait with doing that until we hear from Apple.

[madsmtm]

Am I misunderstanding? Isn't it DCAppAttestService.sharedService that should be unsafe, and the rest that are safe?

[LucaCappelletti94]

sharedService is the unsafe one now, and the four instance methods together with new and init are safe. DCAppAttestService is neither Send nor Sync, so an instance from new stays on one thread, and only sharedService can hand the same instance to several threads.

[LucaCappelletti94]

The Apple report is FB25187723.

The initializer would need to call an instance method as well, for example DCAppAttestService::sharedService().isSupported(). sharedService itself is already guarded by dispatch_once, and the race is in the controller that the first instance method call creates.