I'm trying to review whether my database files are actually populating to the CloudKit private database. For Private and Shared databases, I get a message that I need to sign in again. I do sign in again, but this message never goes away. I have also tried acting as iCloud User. When I enter my iCloud user id and password, I get an authentication error.

Hello, I am building an iOS app that uses NSPersistentCloudKitContainer with a two-store configuration (.private + .shared), following the "Sharing Core Data objects between iCloud users" sample. Sharing works in one direction only: the owner's records reach the participant, but nothing the participant writes is ever exported. I have spent a full day isolating this and have ruled out every cause I can think of. I would appreciate guidance on what else to check, or confirmation that this is a limitation I have misunderstood. I have deliberately kept the details below complete, because the interesting part of this report is not the failure itself but everything that has already been eliminated. Environment Xcode 26.6 (17F113) Owner device: iPhone 15 Pro, iOS 26.5.2 Participant device: iPhone 13 mini, iOS 26.0.1 Two devices, two different iCloud accounts CloudKit container: iCloud.com.onton.quipuledger, Development environment NSPersistentCloudKitContainer with two stores: private.sqlite — databaseScope = .private shared.sqlite — databaseScope = .shared Both created exactly as in the sample (the shared description is a copy() of the private one, with a new NSPersistentCloudKitContainerOptions whose scope is .shared) Both stores have NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey set viewContext has transactionAuthor, mergePolicy (NSMergeByPropertyObjectTrumpMergePolicy) and automaticallyMergesChangesFromParent = true What works The owner calls share(_:to:) with a set of objects and gets a CKShare. The owner sets publicPermission = .readWrite, saves the share via CKDatabase.modifyRecords, then calls persistUpdatedShare(_:in:). The participant accepts the invitation link. All shared records arrive correctly in the participant's shared.sqlite (164 objects), and subsequent owner-side changes continue to arrive. Import events succeed. What fails Every export from the participant's .shared store fails, regardless of what is written. On the participant device: New object assigned to the shared store via context.assign(_:to:) → never exported Update to an existing record that arrived from the owner → never exported Both are saved successfully to the local store (verified by reading the sqlite file) and appear in the persistent history The corresponding NSPersistentCloudKitContainer.Event reports: type: .export succeeded: false error: NSCocoaErrorDomain Code=134060 userInfo: [:] // completely empty — no underlying error countAffectedObjects: 0 Reading the store's internal metadata tables shows the export never begins: ANSCKEXPORTMETADATA — empty (no history token was ever recorded) ANSCKEXPORTEDOBJECT — 0 rows ANSCKEXPORTOPERATION — 0 rows Meanwhile the same device's .private store exports successfully, and the owner device's .private store (which holds the shared zone) exports successfully as well. What I have ruled out Permissions. On the participant, share.currentUserParticipant reports permission == .readWrite, role == .publicUser, acceptanceStatus == .accepted. Record types. All types exist in the Development schema (verified in CloudKit Console). I also ran initializeCloudKitSchema() to be certain. Server-side rejection. The CloudKit Console Logs show no errors at all — the request never reaches the server. The records themselves. Failure is independent of content: a single entity with no relationships fails exactly like a multi-object graph. Association with the share. fetchShares(matching:) on the participant returns the correct share for the record, with the correct zone name and owner name. Core Data does know the object belongs to the shared zone. Corrupted mirroring metadata. Deleting and reinstalling the app on the participant device reproduces the problem from a clean state. CloudKit itself refusing participant writes. Using the raw CloudKit API on the same device, I saved a CKRecord directly into the same shared zone — this succeeded, and the owner device received a push notification for it. So the account, the zone, the permissions and the record type are all fine; only the Core Data mirroring path fails. Question Given that Core Data correctly associates the object with the share, and that the same device can write to the same zone through the raw CloudKit API, why would the mirroring delegate never schedule an export for the .shared store? Specifically: Is exporting participant-side changes from a .shared store supported by NSPersistentCloudKitContainer? The sample project demonstrates share management and owner-side writes, but I could not find an example of a participant creating or modifying objects in the shared store. If it is supported, what would cause NSCocoaErrorDomain 134060 with an empty userInfo and zero affected objects? Is there a way to obtain the underlying reason? (-com.apple.CoreData.CloudKitDebug 1 produced no additional output for me when the app was launched via devicectl.) Is there any additional setup required on the participant side beyond accepting the share — for example, does a newly created object need to be related to an object that is already part of the share in order to be exported? Thank you very much for your help.

Since approximately 03:11 UTC on 2026-08-28, every CloudKit private-database write from my iCloud account fails. The app had been syncing normally for weeks before this moment. Failure signature: Every record save returns HTTP 500 with an empty response body (Server: AppleHttpServer, via icloud-xrail). Client-side error: CKErrorDomain 15 (Server Rejected Request) with underlying CKInternalErrorDomain: 2001. Reads succeed. CKContainer.accountStatus reports available. Authentication is fine. Only writes fail. Reproduces identically via NSPersistentCloudKitContainer mirroring and via a raw CKModifyRecordsOperation probe. Device: iPhone 15 Pro Max, iOS 17.2.1. Development environment, private database. Evidence this is account-scoped server state, not app configuration: It reproduces identically in two containers: the original production container and a freshly created container set up after the failures began. A brand-new container failing the same way rules out container-specific corruption or schema issues. Entitlements, embedded provisioning profile, and App ID iCloud capability have all been verified correct (codesign inspection and App Store Connect API). No code or configuration change coincided with the onset. The failure follows my Apple ID across probes over many hours. Every write 500s, without exception. Correlating event: the legal name on my Apple Account was changed at account.apple.com the same morning, shortly before the failures began. I cannot prove causation, but the timing is exact, and the account-scoped, writes-only signature is consistent with a wedge in the account's server-side state (PCS / user-record layer) introduced by the identity change. I request a check of this account's CloudKit/PCS state. Sample failing request UUIDs (x-apple-request-uuid) for locating these in server logs: 244DA811-E4AA-4771-88F0-7C092EFD8DEF, 2026-08-28 ~09:57 UTC 1FD544D6-6ED2-4181-8976-B4F4C35830D9 E55EFF8F-FC32-48BD-9165-F4EA263F130A Many more available on request. The app logs every attempt. Related reports: this appears closely related to thread 843819 (same week, same signature: private-db writes CKError 15 / HTTP 500, fresh container also affected, Console works), and possibly to the recent cluster of private-database reports in threads 838743, 840248, and 839650. Please correlate rather than triage in isolation. Impact: this blocks shipping a family-sharing feature built on CKShare, the purchase-deciding feature of the app. All development on sync is stopped. I can supply on request: a CloudKit sysdiagnose captured during a failing save (per TN3163), additional request UUIDs with timestamps, and the exact local timeline of the account name change.

Hi, I’m running into a strange CloudKit issue and I’m trying to figure out whether this could be related to the China mainland iCloud environment, or whether I’m missing something on the client side. I’m testing on macOS with Xcode 26.6, using the CloudKit Development environment and the Private Database. The Apple Account signed in on the Mac is a China mainland account, and CKAccountStatus reports available. The original container is: iCloud.com.hu.sujian With that container: I can create a custom zone in CloudKit Console. The app can save a normal CKRecord to the Private Database default zone. But the app consistently fails when creating a custom CKRecordZone. The error is: CKErrorDomain Code=15 (serverRejectedRequest) Underlying CKInternalErrorDomain Code=2000 I also opened DTS case 21678909 and filed FB24394907. As part of the DTS investigation, I created a completely new CloudKit container: iCloud.com.hu.sujian.dtstest21678909 I then repeated the same tests using the same Apple Account and the same minimal test app. On the new container, both of these app-side operations fail: Saving a CKRecord to the Private Database default zone CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: D4B4DC7A-4167-4987-8BB1-4C61E658EDB6 Creating a custom CKRecordZone named SujianLibrary CKErrorDomain Code=15 (serverRejectedRequest) CKInternalErrorDomain Code=2000 HTTP status: 500 Request UUID: 00B4A294-9C63-4DBC-9133-03D969536B73 However, if I open CloudKit Console for that same new container, I can create a custom Private Database zone successfully. I created: DTSConsoleTest21678909 and it shows up normally as: REGULAR_CUSTOM_ZONE The code is very small. The relevant paths are essentially: let container = CKContainer(identifier: containerIdentifier) let database = container.privateCloudDatabase let record = CKRecord(recordType: "DTSWriteTest") record["message"] = "test" as CKRecordValue try await database.save(record) and: let zone = CKRecordZone(zoneName: "SujianLibrary") try await database.save(zone) What confuses me is that CloudKit Console works, while the app receives an HTTP 500 from the CloudKit service. The behavior also changed slightly between the two containers: Original container: default-zone record write from app: works custom-zone creation from app: fails custom-zone creation in Console: works New container: default-zone record write from app: fails custom-zone creation from app: fails custom-zone creation in Console: works FB24394907 contains the full reproduction details and logs. Has anyone seen something similar, especially with a China mainland iCloud account? I also have a small standalone reproduction project if that would be useful. Thanks.

Hi! I'm working on the app where users can share their content via collaboration or just send copy as a json file. The problem I'm facing is that I cannot make it work correctly in Messages. Having only one option like Collaboration or Send Copy work just fine but with active selector between those two options on share sheet is confuse me a lot. I use ShareLink along with Transferable protocol @ViewBuilder private var control: some View { if let presentation { ShareLink( item: shareItem(for: presentation), preview: preview(for: presentation) ) { label } } else { Button {} label: { label } .disabled(true) } } public static var transferRepresentation: some TransferRepresentation { CKShareTransferRepresentation { item in return item.exportedShare(for: plan) } .exportingCondition { $0.collaborationPlan != nil } FileRepresentation(exportedContentType: .customDocumentType) { item in SentTransferredFile(item.copyFileURL) } } private func exportedShare( for plan: ShareCollaborationPlan ) -> CKShareTransferRepresentation<Self>.ExportedShare { let container = CKContainer(identifier: plan.containerIdentifier) let allowedSharingOptions = LiveCollaborationPermissionPolicy .makeAllowedSharingOptions() switch plan { case let .existing(handle): return .existing( handle.shareForPresentation(title: title), container: container, allowedSharingOptions: allowedSharingOptions ) case .prepare: return .prepareShare( container: container, allowedSharingOptions: allowedSharingOptions ) { [prepareCollaboration] in try await prepareCollaboration().shareForPresentation(title: title) } } } In general this works fine except Messages. When I trying to start Collaboration in Messages, it show an error "Collaboration Not Available" and it is trying to send a file instead of Collaboration link I setup my CKShare like this func shareForPresentation(title: String) -> CKShare { share[CKShare.SystemFieldKey.title] = title if let thumbnailImageData = Self.thumbnailImageData { share[CKShare.SystemFieldKey.thumbnailImageData] = thumbnailImageData } return share } private static let thumbnailImageData: Data? = { #if canImport(UIKit) UIImage(named: "SharePreviewIcon", in: .main, compatibleWith: nil)? .pngData() #else nil #endif }() I have tried to use UIActivityController with NSItemProvider where I use registerCKShare and registerFileRepresentation on the same provider. It works also just fine, except Messages, where it always trying to send Collaboration no matter what I choose Collaboration or Send Copy on share sheet selector. I have tried to use two NSItemProvider's for CKShare and file, this works as I wanted but it messed-up metadata which is I'm not able to setup in the way I want. Please help me to understand how I can setup share where Collaboration and Send Copy work correctly with Messages?

I have a Mac and iOS app intended to sync data in iCloud. Both apps in TestFlight, the iOS reads and writes to iCloud but the Mac fails as the App Sandbox denies mach-lookup com.apple.cloudd, so NSCloudKitMirroringDelegate` never reaches the daemon and setup fails permanently. I have a minimal app reproducing the issue on for the Mac app. I also submitted a feedback FB24450529

My SwiftData app (NSPersistentCloudKitContainer mirroring, private database only) cannot save any record to its CloudKit Production environment, for any user. Development works flawlessly for the same devices, accounts, and code. Signature, from CloudKit Console Production logs: every RecordSave to zone com.apple.coredata.cloudkit.zone fails with overallStatus USER_ERROR, error BAD_REQUEST, returnedRecordTypes "_pcs_data". Reads and zone setup succeed in the same sessions (ZoneSave, SubscriptionCreate, DatabaseChanges, ZoneChanges). Zero successful RecordSaves have ever occurred in this container's Production environment. Facts established so far: 4 of 4 users fail identically (my account + 3 TestFlight testers on unrelated iCloud accounts, iPhone and iPad, iOS 26.6/26.6.x) — so this is not one account's Advanced Data Protection key state. Schema was deployed Dev to Production via Console; the Deploy sheet now reports zero pending changes, and Export Schema from BOTH environments yields identical record type sets. _pcs_data appears in neither export — it is a server-managed system type, so there is no developer action (Console or cktool) that can add it to Production. The model declares no encrypted attributes (allowsCloudEncryption appears nowhere). Entitlements verified with codesign on the shipped TestFlight binary: icloud-container-identifiers, icloud-services=CloudKit, production environment — all correct. Client-side the failure is silent: CKAccountStatus is .available, the container initializes, no error surfaces; the mirroring delegate just stops exporting. Tried without effect: reboots, reinstalls, force-quits, per-app iCloud toggles; storage has ample headroom. This matches the signature in thread 838743 (FB23731287, FB24150787), where multiple developers report the same behavior, unresolved. Filed as FB24378074, which now carries: a CloudKit-profile sysdiagnose captured during a timestamped reproduction, the matching server-side requestId/operationId for that exact save (9265D1CA-86BF-4CEB-A432-43F3F39C891E / A2A2B0F98B389DF8), schema exports from both environments, and a full fault-elimination audit. Question for DTS: what makes a Production environment reject _pcs_data record saves that Development accepts, and what is the supported path to repair this container's Production PCS handling? A live TestFlight beta (a family app; device-to-device sync fully down for all users) is waiting on this. Happy to run further diagnostics on request — a minimal repro project against a fresh container is prepared. Case-ID: 21696635

Hello, I am building an multiplatform app for iOS and macOS that uses CloudKit. I want give prerelease versions of my app to testers in my team. I want those builds to use the CloudKit development environment, as some of the schema is still experimental and subject to breaking changes. However, when I distribute my app via TestFlight, the iCloud container environment is automatically set to production, even though in my entitlements file I've set the iCloud container environment to development. I also tried the 'Release Testing' distribution method, but also with this option the container environment is overridden and set to production. Does anyone know how I can distribute a release build for internal testing that uses the CloudKit development environment?

Since ~July 10, NSPersistentCloudKitContainer export has failed on every device on my iCloud account; import still works. In CloudKit Console → Logs (Production), the only failing operations are RecordDelete/RecordSave of record type pcs_data (error BAD_REQUEST) in the private com.apple.coredata.cloudkit.zone. No CD* app-record failures; the app schema is fully deployed to Production. Advanced Data Protection is enabled on the account, so PCS keys are managed end-to-end on-device. This looks like a wedged PCS key state rather than an app/schema problem. Tried with no effect: toggling ADP off/on, toggling iCloud Keychain, multiple reboots, app reinstall, extended foreground on Wi-Fi. Still failing after updating from iOS 27 Seed 3 to beta 4. Is there a way to get the account's Protected Cloud Storage key state reset so export can resume? Happy to share the Feedback number and sysdiagnoses privately with an Apple engineer.

macOS 26.6.1 on an M4 Mac mini, Xcode 26.6 (building against the macOS 26.5 SDK). Sandboxed SwiftUI app using NSPersistentCloudKitContainer. App: com.klausmack-software.NoteManagerPro Container: iCloud.com.klausmack-software.NoteManagerPro When I launch NoteManagerPro from Xcode, CloudKit sync works. When I launch the exact same build by double-clicking it — from /Applications or straight from the build products folder — CloudKit setup fails with CKError 6 ("Error connecting to CloudKit daemon"), and the kernel logs: Sandbox: NoteManagerPro(4338) deny(1) mach-lookup com.apple.cloudd launchd: denied lookup: name = com.apple.cloudd, requestor = NoteManagerPro[4338], error = 159: Sandbox restriction Sandbox: NoteManagerPro(4338) deny(1) mach-lookup com.apple.duetactivityscheduler Immediately before those lines: secinitd: NoteManagerPro[4338]: AppSandbox request successful kernel: (Sandbox) Sandbox apply: NoteManagerPro[4338] CloudKit additionally logs that the process may need (allow user-preference-read (preference-domain "com.apple.CloudKit")) in its sandbox profile. So the sandbox profile is built, but seemingly without the grants the iCloud entitlements should provide. Everything below is measured, not assumed: codesign -dv --verbose=4: signed with "Apple Development: Klaus Mack", valid on disk, satisfies its designated requirement, hardened runtime, flags=0x10000(runtime) codesign -d --entitlements: app-sandbox, network.client, files.user-selected.read-write, com.apple.developer.icloud-services (CloudKit), com.apple.developer.icloud-container-identifiers, com.apple.developer.ubiquity-kvstore-identifier, com.apple.developer.aps-environment (development), get-task-allow launchctl procinfo on the running process reports the same set as granted, plus "entitlements validated" Contents/embedded.provisionprofile present; platform OSX; contains this Mac's hardware UUID; entitlements include the iCloud container and both container environments Same failure for Debug and Release builds No effect from: deleting the app container (Terminal and Finder with authorisation), restarting the Mac, removing and re-adding the iCloud capability in Xcode, clearing Xcode's provisioning profiles A second app of mine on the same machine, same team, same development certificate, with an almost identical entitlement set, launches from /Applications and syncs without any problem — zero sandbox denials: App: com.klausmack-software.LicenseManager Container: iCloud.com.klausmack-software.LicenseManagerPro The only structural difference I can find is that in the working app the bundle identifier and the container name differ, while in the failing app the container is exactly iCloud. plus the bundle identifier. One more data point. If I change only the bundle identifier of the failing app to com.klausmack-software.NoteManagerPro2 and leave everything else alone, the sandbox denials disappear completely (zero), and CloudKit then reaches the server, which replies: CKError "Partial Failure" (2/1011); "Failed to modify some record zones" com.apple.coredata.cloudkit.zone:defaultOwner = CKError "Permission Failure" (10/2007); server message = "Invalid bundle ID for container" That error is expected, since the container is registered to the original identifier. Changing the identifier back reproduces the original CKError 6 and the sandbox denials exactly. That makes it look as though something is bound to the original bundle identifier rather than to the container directory, the signature, or the launch path. My questions: Where does the sandbox profile get its iCloud-related grants from, given that the entitlements are present and validated at process level? What persistent state could cause those grants to be omitted for one bundle identifier but not another on the same machine, with the same certificate and team? Is there a supported way to inspect or reset that state?

Starting a couple of hours ago all CloudKit request (both private and public database) fail with CKError 0x114e01a10: "Service Unavailable" (6/2009); "Request failed with http status code 503. CloudKit dashboard also fails to load private and public databases

I have an existing CoreData + CloudKit app which I would like to migrate to SwiftData + CloudKit. In the existing CoreData implementation, I have many optional fields (most of which have default values). I want to migrated them to SwiftData non-optional fields with default values. Can someone please confirm that I can do this without causing issues for my existing (CoreData + CloudKit) customers? I.e., I know I can do the migration on the local copy of the database, but I am worried about the CloudKit interaction. Specifically, I'm concerned about properties such as var title: String? which is implemented in CloudKit as CD_title CD_title_ckAsset Can I safely implement this in SwiftData as var title: String = "" without causing a problem with the CloudKit implementation?

Our production container has hit the record type ceiling. Any schema change that adds a new type is rejected with: The request was not allowed: max user record types limit exceeded A schema export taken from production with cktool shows exactly 250 record types: 148 our active schema, CKSyncEngine based 98 CD_* types, auto-generated by NSPersistentCloudKitContainer years ago, before we migrated to CKSyncEngine. The current binary does not use that mirroring path at all (every ModelConfiguration is created with .cloudKitDatabase: .none, and there is not a single CD_ literal in our source). They are never read and never written. 4 system and pre-migration legacy types So 39% of the budget belongs to a framework we no longer use, and because the production schema is append-only we cannot reclaim any of it. Our effective ceiling is 152 types, and we have used 148. The user-visible symptom is CKError 12, "Cannot create new type in production schema". The record is created locally, the client uploads it, the server correctly rejects it, and the data never reaches the user's other Mac or iPad. It fails silently from the user's point of view. Eight shipped features are affected. One of them carries allergen availability, which our restaurant customers print on recipes and communicate to guests, so this is not cosmetic for us. The wall is exactly 250 and it is deterministic: a batch of 13 new types was rejected (245 + 13), and a batch of 5 succeeded, landing the container on 250 precisely. What I have already done: Filed FB24239614 with the full schema export attached. Opened Developer Support case 20000130013570, which came back with general information about what CloudKit is and did not address the quota. Adopted an internal rule that new synchronised data lives as a field or blob on an existing record type wherever the data model allows. Adding fields to existing types works fine and does not consume the budget — that part is not the problem. Some of the eight genuinely need to be their own type. My questions: Is there any supported way to reclaim record type slots left behind by NSPersistentCloudKitContainer after migrating off it? Everything I have found says the production schema is append-only with no exceptions, but these types were generated by the framework rather than authored by us, so I wanted to ask before assuming. If slots cannot be reclaimed, is a per-container record type limit increase something that can be requested through a channel that reaches the CloudKit team? The Developer Support case did not get there. Has anyone migrated a container that uses CKShare-based sharing to a new container? Our model gives each customer a shared zone that their staff accept through a CKShare. My understanding is that shares cannot be migrated, which would force every one of those users to re-accept access. I would like to know if that understanding is correct before treating it as an option. Happy to share the container identifier with an Apple engineer, and the Feedback report has the full export.

I want to prompt users when their iCloud storage quota is full. My test device's iCloud space is full, and when subscribing to the NSPersistentCloudKitContainer-eventChangedNotification event, events exceeding the quota will not be passed to the application at runtime. When I tried to add data to Core data using NSPersistentCloudKitContainer, I got an error: <CKError 0x600000c15890: "Quota Exceeded" (25/2035); server message = "Quota exceeded"; op = 1ECF73B9554DF79F; uuid = 34D12DF0-A307-49EB-AD3A-BB646FF66F54; Retry after 316.0 seconds>}> My iCloud storage space is full, but I am unable to retrieve the 'Quota exceeded' error.I have written a demo, please help me fix the issue. github: CloudKit Sync Demo

Container ID: iCloud.com.bluecrestcreative.HouseholdWizard (and a brand-new test container, iCloud.com.bluecrestcreative.HouseholdWizard2 — see below) Calling persistentContainer.share(_:to:) on an NSPersistentCloudKitContainer never successfully completes against the Production CloudKit environment. The identical code works fine against Development. What I've ruled out so far, each with a real test: Stale local state — wiped the local Core Data store entirely and retried from empty. Same failure, new share/zone UUID each time. Container-specific corruption — created a brand-new CloudKit container under the same team (never used before, zero history) and pointed the app at it instead. Same failure. Permissions — confirmed full "Edit Production" access in Container Permissions for my account. Entitlements mismatch — verified identical entitlements between a working Development build and the failing Production build (only the environment key differs). Daemon/session staleness — rebooted the Mac, retried. Same failure. CloudKit Dashboard schema — "Deploy Schema Changes to Production" shows zero pending changes even after a successful share in Development, so the cloudkit.share system type doesn't appear to be tracked by the normal schema-deploy mechanism. The specific error captured from the original container (Xcode 26.6, macOS): NSCloudKitMirroringDelegate _requestAbortedNotInitialized: Never successfully initialized and cannot execute request due to error: CKError "Partial Failure" (2/1011); "Failed to modify some records"; partial errors: { cloudkit.zoneshare:(com.apple.coredata.cloudkit.share.:defaultOwner) = CKError "Invalid Arguments" (12/2006); server message = "Cannot create new type cloudkit.share in production schema" } On the brand-new test container, the failure mode was slightly different (an initial CKError Code=5 / notAuthenticated during user-identity fetch, then CKShare.url simply never populates, indefinitely), but the end result is identical: sharing never actually completes. Has anyone seen this, or know what's needed to make CKShare record creation work against Production for a container? Already have a DTS incident open (Case-ID 21466535) but wanted to ask here in parallel since code-level questions get routed here anyway.

Hello, I am investigating a persistent CloudKit Web Services authentication failure that occurs in both Production and Development for the same container. I filed Feedback Assistant report FB24212003 with the full private configuration and timestamps. Configuration The site is served over HTTPS. Its allowed origin and web authentication return URL exactly match the CloudKit Dashboard configuration. The Web Services API token is origin-restricted. No token, Apple Account, container identifier, or user data is included here. Minimal reproduction Configure CloudKit JS with apiTokenAuth for the target environment. Begin CloudKit web authorization and complete Apple Account authorization successfully. The browser returns with a one-time ckWebAuthToken/ckSession callback parameter. On that callback page, make exactly one GET request to /database/1/[container]/[environment]/public/users/current, passing only ckAPIToken and the one-time ckWebAuthToken. The request uses credentials: omit, cache: no-store, and no referrer. Actual result The first request immediately returns HTTP 421 with serverErrorCode AUTHENTICATION_REQUIRED and reason "request needs authorization". Production request UUID: 19e12af3-4cc1-474f-910e-cc98a18a6637 Development request UUID: 2ebabb8d-efba-41c5-8268-69123e056fd6 Controls completed A direct one-time REST probe on the callback page reproduces the failure while bypassing CloudKit JS entirely. CloudKit JS default Cookie store and a custom same-origin authTokenStore both reproduce it. Fresh authorization reproduces in Edge and in an independent Safari profile. Native iOS CloudKit synchronization for this container and Apple Account succeeds, including an explicit web-sync upload. The Production schema is deployed. A previous query-index issue was resolved separately; this failure occurs at users/current before any record read. Questions Could a container-level or team-level CloudKit Web Services authorization/provisioning state cause callback tokens to be rejected by users/current in both environments? Is there a server-side configuration or remediation that should be checked? I can provide the container identifier, exact endpoint timestamps, and additional redacted diagnostics privately through FB24212003. I will not post credentials or user data publicly.

The traditional way to initialize a SwiftData app looks like some variation of the following: @main struct TrainingCornerApp: App { let dbSchema: Schema = ... init() { } var body: some Scene { WindowGroup { MainAppScreen() .modelContainer(modelContainer) } } } private var modelContainer: ModelContainer { let container: ModelContainer let modelConfiguration = ModelConfiguration(schema: dbSchema, isStoredInMemoryOnly: false, cloudKitDatabase: .automatic) do { container = try ModelContainer(for: dbSchema, migrationPlan: MigrationPlan.self, configurations: [modelConfiguration]) } catch { fatalError("Failed to create model container: \(error.localizedDescription)") } return container } } That is, if creating the modelContainer fails, the app aborts with a fatalError. What I want to do is have the application present an alert message for the user before terminating. (Let the user know the app can't run and suggest how to get help -- that sort of thing.) However, I've been having a hard time getting this to work, and it seems that the problems are related to trying to generate the alert at such an early stage in app startup. Does anyone have ideas/suggestions on how I might do this?

I have an Apple app that uses SwiftData and icloud to sync the App's data across users' devices. Everything is working well. However, I am facing the following issue: SwiftData does not support public sharing of the object graph with other users via iCloud. How can I overcome this limitation without stopping using SwiftData? Thanks in advance!

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Hello, I've been working on this side project to help me understand the uses of Swift and CloudKit. In the middle of this project my "MHLocation" Data Record always keeps facing an internal error and this has been happening on and off for the past 6 months. What can I do to stop this error? I am willing to work with anyone on this. Best, Jordan