Fair distinction — you're right that print(…) and _ = aren't equivalent, and I conflated them. Our code had the _ = variant, which is why it failed silently. That said, our recommendation remains: explicit framework linking under Build Phases → Link Binary With Libraries is more reliable than either source-level approach, because it can't be affected by optimizer decisions at all — it's a linker directive, not a Swift expression. Whether print(CKRecord.self) survives in all build configurations may depend on inlining, LTO settings, or where in the call graph it appears. Explicit linking has no such dependencies. For anyone reading this thread: verify with otool -L on your actual built binary before assuming any source-level workaround has taken effect.

Adding a data point that may save others some time: the _ = CKRecord.self (or print(CKRecord.self)) workaround described here is not reliable — at least not in Release/Distribution builds with whole-module optimization. We had that exact line in our App.init(), added for this exact reason, and still hit sandboxd: deny(1) mach-lookup com.apple.cloudd / CKErrorDomain Code=6 on a shipped TestFlight build (reproduced on macOS 26.6.2 / 25G83). Running otool -L on the actual installed binary showed CloudKit.framework was not in the load commands at all, despite that line being present in source. Our read: since the expression's result is discarded and provably unused, the optimizer strips the reference entirely in Release builds — so the "fix" silently does nothing while looking correct in code review. The only thing that actually worked was adding CloudKit.framework explicitly under Build Phases → Link Binary With Libraries (not a source-level reference at all), then re-verifying with otool -L that it's really in the binary. Once that was in place, otool -L showed CloudKit linked on both arch slices and the sandbox denial went away — confirmed since via a real production build shipped to beta testers, syncing cleanly on both Mac and iPhone with no recurrence. TL;DR: don't trust the .self-reference trick without independently confirming via otool -L on the actual built binary — explicit framework linking is the only version we could get to reliably survive Release optimization.