Hi, I work on a financial app in Brazil and since Beta 1 we're getting several crashes. We already opened a code level support and a few feedback issues, but haven't got any updates on that yet. We were able to resolve some crashes changing some of our implementation but we aren't able to understand what might be happening with this last one. This is the log we got on console: erro 11:55:41.805875-0300 MyApp CoreData: error: Failed to load NSManagedObjectModel with URL 'file:///private/var/containers/Bundle/Application/0B9F47D9-9B83-4CFF-8202-3718097C92AE/MyApp.app/ServerDrivenModel.momd/' We double checked and the momd is inside the bundle. The same app works on any other iOS version and if we build using Xcode directly (without archiving and installing on an iOS26 device) it works as expected. Have anyone else faced a similar error? Any tips or advice on how we can try to solve that?

I am planning a Core Data migration for a macOS app targeting macOS 12 and later and I would appreciate guidance on structuring the rollout to minimise risk. Context The app currently uses a SQLite store located at: ~/Library/Containers/com.company.AppName/Data/Library/Application Support/AppName I want to: Relocate the persistent store to an app group container: ~/Library/Group Containers/group.com.company.AppName Perform schema migration, including: Renaming attributes Deleting attributes Using a custom NSEntityMigrationPolicy subclass Adopt iCloud sync using NSPersistentCloudKitContainer Potentially leverage staged migration (macOS 14+) Additionally, I intend to port the app to iOS, so the end state needs to support an app group container and CloudKit with the latest schema from the outset. Questions Store relocation vs schema migration Is it advisable to perform store relocation and schema migration in a single step, or should these be separate releases? If combined, are there pitfalls when moving the SQLite file and running a migration in the same launch cycle? Custom migration policy Any best practices for structuring NSEntityMigrationPolicy when also relocating the store? Should migration policies assume the store has already been moved, or handle both concerns? Staged migration (macOS 14+) Is staged migration worth adopting when still supporting macOS 12–13? Would you gate it conditionally, or avoid it entirely for consistency? CloudKit adoption Is introducing NSPersistentCloudKitContainer in the same release as the above migrations too risky? Are there known issues when enabling CloudKit immediately after a migration? Release strategy Would you recommend: A single release handling everything Two phases: (1) store & schema migration, (2) CloudKit Or three phases: store relocation → schema migration → CloudKit Goal I want a smooth, reliable transition without data loss or duplication, particularly for existing users with non-trivial datasets. Any insights, practical experience, or recommended sequencing strategies would be very helpful.

Hello all Synopsis: document based SwiftData app breaks document handling after first save due to internal error saving the -shm file. Long: i am working on a small document based SwiftData app for macOS. The UI works well as long as the document was not saved. After saving the document and reopening it, I get an error consistently in console: BUG IN CLIENT OF libsqlite3.dylib: database integrity compromised by API violation: vnode unlinked while in use: /Users/vrunkel/Library/Containers/de.ecoobs.CurtailmentAnalyzer/Data/tmp/TemporaryItems/NSIRD_CurtailmentAnalyzer_mrXKMs/NewDocument/StoreContent-shm So somehow the -shm file is still referenced to NewDocument created when the app opens an untitled document and resides in the temporary folder. I have saved the document to my documents folder. After reopening and the above error deletion or addition of items crashes the app with a long backtrace to view updating: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. I am not creating any threads or do background work. If I do not save the document but work within the new untitled document no problems occur. Even closing the app and reopening the untitled new doc (happens automatically) all is fine. To rule out any influence of my existing view structure I have created the most simple test case - Xcode -> New Project -> macOS document based app configured to use SwiftData. Same behaviour. After saving a new document the addition/deletion of items causes the thread-induced crash and shows the error in console when opening the document. I am using latest versions of Xcode 15.0 and macOS 14.0 Any ideas? thx, volker

For the past several days every time I log in to to the Cloudkit dashboard I get Error looking up Developer Teams, Please sign out and try again. No amount of singing out and back in changes anything.

When subscribing to NSPersistentCloudKitContainer.eventChangedNotification events, quota exceeded events aren't delivered to the app at runtime. I get CKError.partialFailure, but without any additional information in any of the properties. https://developer.apple.com/documentation/cloudkit/ckerror/code/partialfailure states information should be available, but it isn't. When a debugger is attached, the information is logged by another process, but my app cannot access that at runtime to provide users with additional information. Is there any workaround to get this to work? References: Older post: https://forums.developer.apple.com/forums/thread/696523 FB13773922

Hi all, I’m trying to understand SwiftData’s runtime semantics around optional to-many relationships, especially in the context of CloudKit-backed models. I ran into behavior that surprised me, and I’d like to confirm whether this is intended design or a potential issue / undocumented behavior. Minimal example import SwiftUI import SwiftData @Model class Node { var children: [Node]? = nil var parent: Node? = nil init(children: [Node]? = nil, parent: Node? = nil) { self.children = children self.parent = parent print(self.children == nil) } } struct ContentView: View { var body: some View { Button("Create") { _ = Node(children: nil) } } } Observed behavior If @Model is not used, children == nil prints true as expected. If @Model is used, children == nil prints false. Inspecting the macro expansion, it appears SwiftData initializes relationship storage using backing data placeholders and normalizes to-many relationships into empty collections at runtime, even when declared as optional. CloudKit context From the SwiftData + CloudKit documentation: “The iCloud servers don’t guarantee atomic processing of relationship changes, so CloudKit requires all relationships to be optional.” Because of this, modeling relationships as optional is required when syncing with CloudKit, even for to-many relationships. This is why I’m hesitant to simply switch the model to a non-optional [Node] = [], even though that would match the observed runtime behavior. Questions Is it intentional that optional to-many relationships in SwiftData are never nil at runtime, and instead materialize as empty collections? If so, is Optional<[Model]> effectively treated as [Model] for runtime access, despite being required for CloudKit compatibility? Is the defaultValue: nil in the generated Schema.PropertyMetadata intended only for schema/migration purposes rather than representing a possible runtime state? Is there a recommended modeling pattern for CloudKit-backed SwiftData models where relationships must be optional, but runtime semantics behave as non-optional? I’m mainly looking to ensure I’m aligning with SwiftData’s intended design and not relying on behavior that could change or break with CloudKit sync. Thanks in advance for any clarification!

My iOS app uses CloudKit key-value storage. I have not updated the app in a few years but it works fine. Since it was last updated, I transferred the app from an old organization to my personal developer account. Now that I'm working on the app again I get an error: Provisioning profile "iOS Team Provisioning Profile: com.company.app" doesn't match the entitlements file's value for the com.apple.developer.ubiquity-kvstore-identifier entitlement. In the entitlement file, it has $(TeamIdentifierPrefix)$(CFBundleIdentifier) as the value for iCloud Key-Value Store. I've verified the variables resolve as expected. When I parse the provisioning profile there is no entitlement value for key-value storage. What am I getting wrong?

Hi, I did cloudkit synchronization using swiftdata. However, synchronization does not occur automatically, and synchronization occurs intermittently only when the device is closed and opened. For confirmation, after changing the data in Device 1 (saving), when the data is fetched from Device 2, there is no change. I've heard that there's still an issue with swiftdata sync and Apple is currently troubleshooting it, is the phenomenon I'm experiencing in the current version normal?

I have been working on an app for the past few months, and one issue that I have encountered a few times is an error where quick subsequent deletions cause issues with detached tasks that are triggered from some user actions. Inside a Task.detached, I am building an isolated model context, querying for LineItems, then iterating over those items. The crash happens when accessing a Transaction property through a relationship. var byTransactionId: [UUID: [LineItem]] { return Dictionary(grouping: self) { item in item.transaction?.id ?? UUID() } } In this case, the transaction has been deleted, but the relationship existed when the fetch occurred, so the transaction value is non-nil. The crash occurs when accessing the id. This is the error. SwiftData/BackingData.swift:1035: Fatal error: This model instance was invalidated because its backing data could no longer be found the store. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0xb43fea2c4bc3b3f5 &lt;x-coredata://A9EFB8E3-CB47-48B2-A7C4-6EEA25D27E2E/Transaction/p1756&gt;))) I see other posts about this error and am exploring some suggestions, but if anyone has any thoughts, they would be appreciated.

Summary On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops. Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time. Root Cause The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool. The deadlock cycle: cloudd requests an upload to the GCS storage endpoint nsurlsessiond provides the cached (broken) HTTP/3 session The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0) cloudd retries with a new connectionUUID — but nsurlsessiond still routes through the same poisoned QUIC session This repeats indefinitely Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation. The Smoking Gun After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly: Before Kill After Kill Protocol h3 (QUIC) http/1.1 (TCP) Largest upload Failed at partial offsets 26 MB in 1.6 seconds Server response 0 bytes 596 bytes (normal) Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond. Reproduction Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern: Small files (<100 KB) squeeze through before the QUIC session stalls Larger files trigger the deadlock every time 5–6 retries with fresh connectionUUIDs, all failing over protocol=h3 After kill cloudd + nsurlsessiond: immediate flush via protocol=http/1.1 An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report. Symptom Check (for others hitting this) /usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \ | grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l Output > 0 = this deadlock. Output = 0 = different issue. Recovery (one-liner) kill $(ps -axo user,pid,command | awk -v u="$USER" \ '($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \ || ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \ {print $2}') Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance. What was ruled out Network connectivity (Photos uploaded 8 MB through the same pool simultaneously) iCloud account (metadata operations succeeding, only body uploads failing) File type/content (random data, correlation is with size, not type) Storage quota (1.65 TB free) CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1) Suggested fixes (from the Feedback report) CFNetwork: Invalidate the QUIC session after N consecutive requestDuration=-1.000 failures CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:] cloudd: Self-healing retry — create a fresh NSURLSession after M consecutive deadlock-signature failures Finder: At minimum, surface the stuck state to the user instead of failing silently Filed as FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables. If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count. System MacBook Air, macOS 26.4.1 (25E253) iCloud Drive with Desktop & Documents sync en0 (WLAN) + en5 (USB-LAN via Studio Display)

I have a CloudKit container that I share across several apps. when I look at the App Privacy Report for these apps, it reflects the app connecting to Google storage APIs. While Apple might host with Google, the perception for users is iCloud and Apple. Can something be done about this? FB16410232 (CloudKit: CloudKit requests contacting google upload servers unexpectedly in app privacy report)

Hi, I was testing the new iOS 18 behavior where NSPersistentCloudKitContainer wipes the local Core Data store if the user logs out of iCloud, for privacy purposes. I ran the tests both with a Core Data + CloudKit app, and a simple one using SwiftData with CloudKit enabled. Results were identical in either case. In my testing, most of the time, the feature worked as expected. When I disabled iCloud for my app, the data was wiped (consistent with say the Notes app, except if you disable iCloud it warns you that it'll remove those notes). When I re-enabled iCloud, the data appeared. (all done through the Settings app) However, in scenarios when NSPersistentCloudKitContainer cannot immediately sync -- say due to rate throttling -- and one disables iCloud in Settings, this wipes the local data store and ultimately results in data loss. This occurs even if the changes to the managed objects are saved (to the local store) -- it's simply they aren't synced in time. It can be a little hard to reproduce the issue, especially since when you exit to the home screen from the app, it generally triggers a sync. To avoid this, I swiped up to the screen where you can choose which apps to close, and immediately closed mine. Then, you can disable iCloud, and run the app again (with a debugger is helpful). I once saw a message with something along the lines of export failed (for my record that wasn't synced), and unfortunately it was deleted (and never synced). Perhaps before NSPersistentCloudKitContainer wipes the local store it ought to force sync with the cloud first?

I am using SwiftData with CloudKit to synchronize data across multiple devices, and I have encountered an issue: occasionally, abnormal sync behavior occurs between two devices (it does not happen 100% of the time—only some users have reported this problem). It seems as if synchronization between the two devices completely stops; no matter what operations are performed on one end, the other end shows no response. After investigating, I suspect the issue might be caused by both devices simultaneously modifying the same field, which could lead to CloudKit's logic being unable to handle such conflicts and causing the sync to stall. Are there any methods to avoid or resolve this situation? Of course, I’m not entirely sure if this is the root cause. Has anyone encountered a similar issue?

Hi everyone, Im trying to set up CloudKit for my Unreal Engine 5.4 project but seem to be hitting some roadblocks on how to set up the Record Types. From my understanding I need to set up a "file" record type with a "contents" asset field - but even with this it doesn't seem to work :( Any unreal engine devs with some experience on this who could help me out? Thanks!

Good morning everyone! Today I have a question about using SwiftData with CloudKit and Widgets. I recently set up my project for SwiftData and CloudKit synchronization, but for some reason, I’m not able to give my Widget access to this data. CloudKit works perfectly fine for my main app, but the Widget only shows placeholder data(the placeholder data which were defined in the get functions as catch, this is sure). I have set the CloudKit capability for my Widget extension and tried fetching data with the get-functions in the code below. I also ensured that the data model files are members of the Widget extension target and that the Widget extension uses the same CloudKit container as the main app. I wondered if it is possible and reasonable to save a copy of my CloudKit data in an App Group container, but in that case, the information shown in the Widget are not always up-to-date, so a solution that fetches data directly from CloudKit would be better. Has anyone had experience with this case? I couldn’t find much information about this problem online. In the code below, many parts have been deleted or altered because they are not relevant to the problem, as they don’t fetch data. The variables, functions, and data models in the code may sometimes have German names, but I hope you can still understand it. Thanks for your help! struct Provider: AppIntentTimelineProvider { //[Placeholder and snapshot] func timeline(for configuration: ConfigurationAppIntent, in context: Context) async -> Timeline<CleverEntry> { let entry = await loadAllVariables() return Timeline(entries: [entry], policy: .after(Date().addingTimeInterval(60 * 5))) } @MainActor private func getExam() -> [PruefungM] { //Old, local version /* guard let modelContainer = try? ModelContainer(for: PruefungM.self) else { return [] } let descriptor = FetchDescriptor<PruefungM>() let PRF = try? modelContainer.mainContext.fetch(descriptor) return PRF ?? [] */ do { let configuration = ModelConfiguration(cloudKitDatabase: .private("iCloud.my_bundle_id")) let container = try ModelContainer( for: PruefungM.self, configurations: configuration ) let descriptor = FetchDescriptor<PruefungM>() return try container.mainContext.fetch(descriptor) } catch { print("❌ Error(CloudKit): \(error)") return [] } } @MainActor private func getHAF() -> [HausaufgabeM] { do { let configuration = ModelConfiguration(cloudKitDatabase: .private("iCloud.my_bundle_id")) let container = try ModelContainer( for: HausaufgabeM.self, configurations: configuration ) let descriptor = FetchDescriptor<HausaufgabeM>() return try container.mainContext.fetch(descriptor) } catch { print("❌ Error (CloudKit): \(error)") return [] } } @MainActor private func loadAllVariables() -> CleverEntry { print("Function started") let HAF = getHAF() let PRF = getExam() //handling and returning the data } }

Hi everyone, In the simple app below, I have a QueryView that has LazyVStack containing 100k TextField's that edit the item's content. The items are fetched with a @Query. On launch, the app will generate 100k items. Once created, when I press any of the TextField's , a severe hang happens, and every time I type a single character, it will cause another hang over and over again. I looked at it in Instruments and it shows that the main thread is busy during the duration of the hang (2.31 seconds) updating QueryView. From the cause and effect graph, the update is caused by @Observable QueryController <Item>.(Bool). Why does it take too long to recalculate the view, given that it's in a LazyVStack? (In other words, why is the hang duration directly proportional to the number of items?) How to fix the performance of this app? I thought adding LazyVStack was all I need to handle the large dataset, but maybe I need to add a custom pagination with .fetchLimit on top of that? (I understand that ModelActor would be an alternative to @Query because it will make the database operations happen outside of the main thread which will fix this problem, but with that I will lose the automatic fetching of @Query.) Thank you for the help! import SwiftData import SwiftUI @main struct QueryPerformanceApp: App { var body: some Scene { WindowGroup { ContentView() .modelContainer(for: [Item.self], inMemory: true) } } } @Model final class Item { var name: String init(name: String) { self.name = name } } struct ItemDetail: View { @Bindable var item: Item var body: some View { TextField("Name", text: $item.name) } } struct QueryView: View { @Query private var items: [Item] var body: some View { ScrollView { LazyVStack { ForEach(items) { item in VStack { ItemDetail(item: item) } } } } } } struct ContentView: View { let itemCount = 100_000 @Environment(\.modelContext) private var context @State private var isLoading = true var body: some View { Group { if isLoading { VStack(spacing: 16) { ProgressView() Text("Generating \(itemCount) items...") } } else { QueryView() } } .task { for i in 1...itemCount { context.insert(Item(name: "Item \(i)")) } try? context.save() isLoading = false } } }

In the past I ran into issues where the CloudKit client SDK was not attributing network usage in MetricKit. Since MetricKit got a major update this year I’d like to make sure usage goes here agains the app. I would expect transfer metrics to also count for CKSyncEngine, or the CloudKit config for core/swift data too. Is this assumption correct? FB12673917 (CloudKit / MetricKit: CloudKit queries are not counting towards network transfer metrics in MetricKit - WWDC23 lab, possible missing URLSession 'attributedBundleIdentifier' not being set)

Hi all - figured I would kick off with a CloudKit question. Recently in development of a multi-device app I got into a state where all iOS devices could not write to the (production) CloudKit container - however macOS could still write (multi-device SwiftUI code). After ruling out a lot of other things it seemed like there had been some corruption in the production zone's PCS key chain. The only fix was deleting the zone from the CloudKit Console (safe for my pre-release beta data, but destructive). Is there a safer or developer-accessible recovery path for PCS chain corruption? Is this situation detectable earlier, or is there guidance on avoiding it during pre-release testing? The error in the logs in this scenario had "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "returnedRecordTypes":"_pcs_data".

I don’t have a feedback for this yet, but I’d like to see some analytics reports for CloudKit performance. Things to capture stats, performance, failures, etc. lots of the data in the console, but exposed through analytics reports. Related but different, if I had something like a generated OpenAPI client, I’d add instrumentation via client middleware. I could do most of what I’d want to instrument that way, status codes, timeouts, durations, payload sizes, etc. Alternatively, if the CloudKit client API exposed URLSession, or a hook to the delegate / metrics, a lot of what I am interested in could be achieved via session task metrics too. FB13628463 (CloudKit: Expose URLSessionTaskMetrics from CloudKit client)

Are there good ways to guide an app to pause iCloud syncing if the app is busy with an intensive activity? Also, is there a way to suggest that it check iCloud for updates?