A sandboxed Mac app with correct CloudKit entitlements fails to connect to com.apple.cloudd (the CloudKit daemon) when distributed via TestFlight (Mac Team Store Provisioning Profile). The identical binary works correctly when launched from Xcode (Mac Team Provisioning Profile also present). All entitlements are correctly embedded and the App ID is properly configured in Apple Developer Portal.
Environment
macOS 26.5.1 (25F80) Xcode 26.5 (17F42) SwiftData with NSPersistentCloudKitContainer / ModelConfiguration(cloudKitDatabase: .private(...)) Steps to Reproduce
Create a sandboxed Mac app using SwiftData with CloudKit sync Enable iCloud + CloudKit in Signing & Capabilities Archive and distribute to TestFlight (Mac Team Store Provisioning Profile) Install via TestFlight on macOS 26 and launch Check Console for kernel sandbox messages Expected Result
CloudKit connects to com.apple.cloudd and syncs data, matching behavior of the iOS version using the same container.
Actual Result
Console shows repeated kernel sandbox denials followed by CloudKit setup failure:
kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.cloudd kernel Sandbox: CheatSheet Mac(82347) deny(1) mach-lookup com.apple.duetactivityscheduler CheatSheet Mac CoreData+CloudKit: Failed to set up CloudKit integration for store Error Domain=CKErrorDomain Code=6 "Error connecting to CloudKit daemon."
Key Diagnostic Finding
When launched from Xcode, taskgated-helper validates both the Mac Team Store Provisioning Profile AND the Mac Team Provisioning Profile, and CloudKit succeeds:
cloudd: TCC approved access for container containerID=iCloud.com.michaelendres.CheatSheet:Production When launched from TestFlight, only the Mac Team Store Provisioning Profile is present, and the sandbox denies com.apple.cloudd despite identical entitlements in the binary:
codesign -d --entitlements shows: com.apple.developer.icloud-services: [CloudKit] com.apple.developer.icloud-container-identifiers: [iCloud.com.michaelendres.CheatSheet] com.apple.developer.icloud-container-environment: Production com.apple.security.app-sandbox: true
Conclusion
The Mac Team Store Provisioning Profile on macOS 26 does not appear to grant the sandbox exception for mach-lookup com.apple.cloudd, while the Mac Team Provisioning Profile (development) does. This prevents any Mac App Store / TestFlight app using CloudKit from syncing on macOS 26.
Oh wow, thank you @DTS Engineer ! That was it.
Disabling Enable Debug Dylib Support alone did not fix it, the standalone Release launch still denied. But adding an explicit CloudKit symbol reference did:
import CloudKit
@main
struct YouriBeaconSimulatorApp: App {
init() {
print(CKRecord.self)
}
...
}
After that, no more deny(1) mach-lookup com.apple.cloudd. Just confirmed it also resolves the issue on an External Distribution build, not just local Release runs.
That explains the whole pattern I was seeing. I'm using NSPersistentCloudKitContainer (CoreData+CloudKit), so my code never references any CloudKit symbol directly, CoreData talks to CloudKit dynamically under the hood. With whole-module optimization in Release, the linker had no reason to add a CloudKit.framework load command, since nothing in my source named a CloudKit type. App Sandbox's framework scan never saw CloudKit linked, so it never granted the cloudd exception.
Debug worked the whole time for probably an unrelated reason. Enable Debug Dylib Support bundles most of the app into a single dylib for fast incremental builds, which happens to pull in a much broader set of frameworks regardless of whether the code references them. That's what should be the one masking the real problem in every test I ran against Debug.
So the underlying issue seems to be that CoreData+CloudKit's dynamic only reference to CloudKit isn't sufficient for App Sandbox to detect and grant the Mach service exception, an explicit static symbol reference somewhere in the app is required for Release/Distribution builds. Any app using CoreData+CloudKit without ever referencing a CloudKit symbol directly would hit this in production. Given that, would it be worth filing this as a separate, more targeted bug, either against the CoreData+CloudKit/App Sandbox interaction, or as a documentation gap? Let me know if you want a fresh Feedback report for it, and I'm happy to include full repro steps.
Really appreciate you sticking with this one! this had me stuck for days.
