I have a shipped App Store app (bundle ID com.stoolkit.app) using a private iCloud container (iCloud.com.stoolkit.app) purely for file-based backup via FileManager's ubiquity container APIs, not CloudKit database/CKContainer. The availability check is as simple as: FileManager.default.ubiquityIdentityToken != nil
This consistently returns nil, even though: the app's embedded provisioning profile (verified by extracting embedded.mobileprovision from the built .ipa and parsing it) correctly includes com.apple.developer.icloud-container-identifiers, com.apple.developer.ubiquity-container-identifiers (both = iCloud.com.stoolkit.app), and com.apple.developer.icloud-services. The app's entitlements plist correctly declares com.apple.developer.icloud-container-identifiers: [iCloud.com.stoolkit.app] and com.apple.developer.icloud-services: [CloudDocuments]. The test device is signed into iCloud. Settings > Apple ID > iCloud > Apps Using iCloud shows the app listed and toggled on. The device-wide iCloud Drive toggle is on. No Content and Privacy / Screen Time restrictions are active. It reproduces identically on two separate physical devices (an iPad via TestFlight, an iPhone via the live App Store), both running the same signed build. Relaunching the app and toggling iCloud Drive off/on device-wide did not change the behavior.
I don't currently have access to a Mac/Xcode to produce a verified minimal reproduction project, but the check itself is a single system API call, so I'd expect a fresh single-view app with the same iCloud container entitlement to reproduce it directly.
What could cause ubiquityIdentityToken to return nil under these conditions? Is there an account- or container-side initialization step I might be missing beyond registering the container under the App ID's capabilities?