I have some code which handles doing some computation on a background thread before updating Core Data NSManagedObjects by using the NSManagedObjectContext.perform functions. This code is covered in Sendable warnings in Xcode 26 (beta 6) because my NSManagedObject subclasses (autogenerated) are non-Sendable and NSManagedObjectContext.perform function takes a Sendable closure. But I can't really figure out what I should be doing. I realize this pattern is non-ideal for Swift concurrency, but it's what Core Data demands AFAIK. How do I deal with this? let moc = object.managedObjectContext! try await moc.perform { object.completed = true // Capture of 'object' with non-Sendable type 'MySpecialObject' in a '@Sendable' closure try moc.save() } Thanks in advance for your help!

I'm developing a SwiftUI app using SwiftData and encountering a persistent issue: Error Message: Thread 1: Fatal error: Duplicate keys of type 'Bland' were found in a Dictionary. This usually means either that the type violates Hashable's requirements, or that members of such a dictionary were mutated after insertion. Details: Occurrence: The error always occurs on the first launch of the app after installation. Specifically, it happens approximately 1 minute after the app starts. Inconsistent Behavior: Despite no changes to the code or server data, the error occurs inconsistently. Data Fetching Process: I fetch data for entities (Bland, CrossZansu, and Trade) from the server using the following process: Fetch Bland and CrossZansu entities via URLSession. Insert or update these entities into the SwiftData context. The fetched data is managed as follows: func refleshBlandsData() async throws { if let blandsOnServer = try await DataModel.shared.getBlands() { await MainActor.run { blandsOnServer.forEach { blandOnServer in if let blandOnLocal = blandList.first(where: { $0.code == blandOnServer.code }) { blandOnLocal.update(serverBland: blandOnServer) } else { modelContext.insert(blandOnServer.bland) } } } } } This is a simplified version of my StockListView. The blandList is a @Query property and dynamically retrieves data from SwiftData: struct StockListView: View { @Environment(\.modelContext) private var modelContext @Query(sort: \Bland.sname) var blandList: [Bland] @Query var users: [User] @State private var isNotLoaded = true @State private var isLoading = false @State private var loadingErrorState = "" var body: some View { NavigationStack { List { ForEach(blandList, id: \.self) { bland in NavigationLink(value: bland) { Text(bland.sname) } } } .navigationTitle("Stock List") .onAppear { doIfFirst() } } } // This function handles data loading when the app launches for the first time func doIfFirst() { if isNotLoaded { loadDataWithAnimationIfNotLoading() isNotLoaded = false } } // This function ensures data is loaded with an animation and avoids multiple triggers func loadDataWithAnimationIfNotLoading() { if !isLoading { isLoading = true Task { do { try await loadData() } catch { // Capture and store any errors during data loading loadingErrorState = "Data load failed: \(error.localizedDescription)" } isLoading = false } } } // Fetch data from the server and insert it into the SwiftData model context func loadData() async throws { if let blandsOnServer = try await DataModel.shared.getBlands() { for bland in blandsOnServer { // Avoid inserting duplicate keys by checking for existing items in blandList if !blandList.contains(where: { $0.code == bland.code }) { modelContext.insert(bland.bland) } } } } } Entity Definitions: Here are the main entities involved: Bland: @Model class Bland: Identifiable { @Attribute(.unique) var code: String var sname: String @Relationship(deleteRule: .cascade, inverse: \CrossZansu.bland) var zansuList: [CrossZansu] @Relationship(deleteRule: .cascade, inverse: \Trade.bland) var trades: [Trade] } CrossZansu: @Model class CrossZansu: Equatable { @Attribute(.unique) var id: String var bland: Bland? } Trade: @Model class Trade { @Relationship(deleteRule: .nullify) var user: User? var bland: Bland } User: class User { var id: UUID @Relationship(deleteRule: .cascade, inverse: \Trade.user) var trades: [Trade] } Observations: Error Context: The error occurs after the data is fetched and inserted into SwiftData. This suggests an issue with Hashable requirements or duplicate keys being inserted unintentionally. Concurrency Concerns: The fetch and update operations are performed in asynchronous tasks. Could this cause race conditions? Questions: Could this issue be related to how @Relationship and @Attribute(.unique) are managed in SwiftData? What are potential pitfalls with Equatable implementations (e.g., in CrossZansu) when used in SwiftData entities? Are there any recommended approaches for debugging "Duplicate keys" errors in SwiftData? Additional Info: Error Timing: The error occurs only during the app's first launch and consistently within the first minute.

I’m building an app that edits files in iCloud and uses an NSFilePresenter to monitor changes. When a conflict occurs, the system calls presentedItemDidGain(_:). In that method, I merge the versions by reading the current (canonical) version using NSFileVersion.currentVersionOfItem(at:) and the conflicting ones using NSFileVersion.unresolvedConflictVersionsOfItem(at:). This generally works, but sometimes, if two devices edit the same file at the same time, each device sees its own local version as the current one. For example: Device A writes fileVerA (slightly later in real time) Device B writes fileVerB On Device A all works fine, currentVersionOfItem returns fileVerA, as expected, and unresolvedConflictVersionsOfItem returns [fileVerB]. But on Device B, currentVersionOfItem returns fileVerB!? And unresolvedConflictVersionsOfItem returns the same, local file [fileVerB], without any hint of the other conflicting version, fileVerA. Later, the newer version from the Device A arrives on Device B as a normal, non-conflicting update via presentedItemDidChange(_:). This seems to contradict Apple’s documentation: “The currentVersionOfItemAtURL: method returns an NSFileVersion object representing what’s referred to as the current file; the current file is chosen by iCloud on some basis as the current “conflict winner” and is the same across all devices.” Is this expected behavior, or a bug in how iCloud reports file versions?

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?

I have an app that from day 1 has used Swiftdata and successfully sync'd across devices with Cloudkit. I have added models to the data in the past and deployed the schema and it continued to sync across devices. Sometime I think in June.2025 I added a new model and built out the UI to display and manage it. I pushed a version to Test Flight (twice over a matter of 2 versions and a couple of weeks) and created objects in the new model in Test Flight versions of the app which should push the info to Cloudkit to update the schema. When I go to deploy the schema though there are no changes. I confirmed in the app that Cloudkit is selected and it's point to the correct container. And when I look in Cloudkit the new model isn't listed as an indes. I've pushed deploy schema changes anyway (more than once) and now the app isn't sync-ing across devices at all (even the pre-existing models aren't sync-ing across devices). I even submitted the first updated version to the app store and it was approved and released. I created objects in the new model in production which I know doesn't create the indexes in the development environment. But this new model functions literally everywhere except Cloudkit and I don't know what else to do to trigger an update.

I have a single multiplatform application that I use NSPersistentCloudKitContainer on. This works great, except I noticed when I open two instances of the same process (not windows) on the same computer, which share the same store, data duplication and "Metadata Inconsistency" errors start appearing. This answer (https://stackoverflow.com/a/67243833) says this is not supported with NSPersistentCloudKitContainer. Is this indeed true? If it isn't allowed, is the only solution to disable multiple instances of the process via a lock file? I was thinking one could somehow coordinate a single "leader" process that syncs to the cloud, with the others using NSPersistentContainer, but this would be complicated when the "leader" process terminates. Currently, it seems iPad split views are new windows, not processes -- but overall I'm still curious :0 Thank you!

Hello Apple Team, We are looking at developing an iOS feature on our current development that stores user-generated images as CKAssets in the public CloudKit database, with access control enforced by our app’s own logic (not CloudKit Sharing as that has a limit of 100 shares per device). Each story or post is a public record, and users only see content based on buddy relationships handled within the app. We’d like to confirm that this pattern is consistent with Apple’s best practices for social features. Specifically: Is it acceptable to store user-uploaded CKAssets in the public CloudKit database, as long as access visibility is enforced by the app? Are there any performance or quota limitations (e.g., storage, bandwidth, or user sync limits) that apply to CKAssets in the public database when used at scale? Would CloudKit Sharing be recommended instead, even if we don’t require user-to-user sharing invitations? For App Review, is this model (public CKAssets + app-enforced access control) compliant with Apple’s data and security expectations? Are there any caching or bandwidth optimization guidelines for handling image-heavy public CKAsset data in CloudKit? Thanks again for your time

Hello Apple Team, We’re building a CloudKit-enabled Core Data app and would like clarification on the behavior and performance characteristics of Binary Data attributes with “Allows External Storage” enabled when used with NSPersistentCloudKitContainer. Initially, we tried storing image files manually on disk and only saving the metadata (file URLs, dimensions, etc.) in Core Data. While this approach reduced the size of the Core Data store, it introduced instability after app updates and broke sync between devices. We would prefer to use the official Apple-recommended method and have Core Data manage image storage and CloudKit syncing natively. Specifically, we’d appreciate guidance on the following: When a Binary Data attribute is marked as “Allows External Storage”, large image files are stored as separate files on device rather than inline in the SQLite store. How effective is this mechanism in keeping the Core Data store size small on device? Are there any recommended size thresholds or known limits for how many externally stored blobs can safely be managed this way? How are these externally stored files handled during CloudKit sync? Does each externally stored Binary Data attribute get mirrored to CloudKit as a CKAsset? Does external storage reduce the sync payload size or network usage, or is the full binary data still uploaded/downloaded as part of the CKAsset? Are there any bandwidth implications for users syncing via their private CloudKit database, versus developer costs in the public CloudKit database? Is there any difference in CloudKit or Core Data behavior when a Binary Data attribute is managed this way versus manually storing image URLs and handling the file separately on disk? Our goal is to store user-generated images efficiently and safely sync them via CloudKit, without incurring excessive local database bloat or CloudKit network overhead. Any detailed guidance or internal performance considerations would be greatly appreciated. Thank you, Paul Barry Founder & Lead Developer — Boat Buddy / Vessel Buddy iOS App Archipelago Environmental Solutions Inc.

Starting 20th March 2025, I see an increase in bandwidth and latency for one of my CloudKit projects. I'm using NSPersistentCloudKitContainer to synchronise my data. I haven't changed any CloudKit scheme during that time but shipped an update. Since then, I reverted some changes from that update, which could have led to changes in the sync behaviour. Is anyone else seeing any issues? I would love to file a DTS and use one of my credits for that, but unfortunately, I can't because I cannot reproduce it with a demo project because I cannot travel back in time and check if it also has an increase in metrics during that time. Maybe an Apple engineer can green-light me filing a DTS request, please.

Every time I insert a subclass (MYShapeLayer) into the model context, the app crashes with an error: DesignerPlayground crashed due to fatalError in BackingData.swift at line 908. Never access a full future backing data - PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(backing: SwiftData.PersistentIdentifier.PersistentIdentifierBacking.managedObjectID(0xb2dbc55f3f4c57f2 <x-coredata://B1E3206B-40DE-4185-BC65-4540B4705B40/MYShapeLayer/p1>))) with Optional(A6CA4F89-107F-4A66-BC49-DD7DAC689F77) struct ContentView: View { @Environment(\.modelContext) private var modelContext @Query private var designs: [MYDesign] var layers: [MYLayer] { designs.first?.layers ?? [] } var body: some View { NavigationStack { List { ForEach(layers) { layer in Text(layer.description) } } .onAppear { let design = MYDesign(title: "My Design") modelContext.insert(design) try? modelContext.save() } .toolbar { Menu("Add", systemImage: "plus") { Button(action: addTextLayer) { Text("Add Text Layer") } Button(action: addShapeLayer) { Text("Add Shape Layer") } } } } } private func addTextLayer() { if let design = designs.first { let newLayer = MYLayer(order: layers.count, kind: .text) newLayer.design = design modelContext.insert(newLayer) try? modelContext.save() } } private func addShapeLayer() { if let design = designs.first { let newLayer = MYShapeLayer(shapeName: "Ellipse", order: layers.count) newLayer.design = design modelContext.insert(newLayer) try? modelContext.save() } } } #Preview { ContentView() .modelContainer(for: [MYDesign.self, MYLayer.self, MYShapeLayer.self], inMemory: true) } @Model final class MYDesign { var title: String = "" @Relationship(deleteRule: .cascade, inverse: \MYLayer.design) var layers: [MYLayer] = [] init(title: String = "") { self.title = title } } @available(iOS 26.0, macOS 26.0, *) @Model class MYLayer { var design: MYDesign! var order: Int = 0 var title: String = "" init(order: Int = 0, title: String = "New Layer") { self.order = order self.title = title } } @available(iOS 26.0, macOS 26.0, *) @Model class MYShapeLayer: MYLayer { var shapeName: String = "" init(shapeName: String, order: Int = 0) { self.shapeName = shapeName super.init(order: order) } }

I'm getting the following error message when executing the rollback method in a modelContext, what could be causing this ? SwiftData/ModelSnapshot.swift:46: Fatal error: A ModelSnapshot must be initialized with a known-keys dictionary

When my app starts it loads data (of vehicle models, manufacturers, ...) from JSON files into CoreData.  This content is static. Some CoreData entities have fields that can be set by the user, for example an isFavorite boolean field. How do I tell CloudKit that my CoreData objects are 'static' and must not be duplicated on other devices (that will also load it from JSON files). In other words, how can I make sure that the CloudKit knows that the record created from JSON for vehicle model XYZ on one device is the same record that was created from JSON on any other device? I'm using NSPersistentCloudKitContainer.

Hello, In my iOS/SwiftUI/SwiftData app, I want the user to be able to hit [Cancel] from editing in a detail screen and return to the previous screen without changes being saved. I believed that setting autosaveEnabled to false and/or calling .rollback would prevent changes from being saved, unless/until I call .save() when the user clicks [Save], but this does not seem to be correct. I set modelContext.autosaveEnabled = false and I call modelContext.rollback() when the user hits [Cancel], but any changes they made are not rolled back, but saved even if I don’t call save(). I have tried setting autosaveEnabled to false when I create the ModelContainer on a @MainActor function when the App starts, and in the detail/edit screen’s .onAppear(). I can see that .rollback is being called when the [Cancel] button is tapped. In all cases, any changes the user made before hitting [Cancel] are saved. The Developer Documentation on autosaveEnabled includes this: “The default value is false. SwiftData automatically sets this property to true for the model container’s mainContext." I am working on the mainContext, but it appears that setting autosaveEnabled to false has no effect no matter where in the code I set it. If someone sees what I am doing wrong, I’d sure appreciate the input. If this description doesn’t explain the problem well enough, I’ll develop a minimal focused example.

I'm testing my app before releasing to testers, and my app (both macOS and iOS) is crashing when I perform one operation, but only in the production build. I have data that loads from a remote source, and can be periodically updated. There is an option to delete all of that data from the iCloud data store, unless the user has modified a record. Each table has a flag to indicate that (userEdited). Here's the function that is crashing: func deleteCommonData<T:PersistentModel & SDBuddyModel>(_ type: T.Type) throws { try modelContext.delete(model: T.self, where: #Predicate<T> { !$0.userEdited }) } Here's one of the calls that results in a crash: try modelManager.deleteCommonData(Link.self) Here's the error from iOS Console: SwiftData/DataUtilities.swift:85: Fatal error: Couldn't find \Link.<computed 0x0000000104b9d208 (Bool)> on Link with fields [SwiftData.Schema.PropertyMetadata(name: "id", keypath: \Link.<computed 0x0000000104b09b44 (String)>, defaultValue: Optional("54EC6602-CA7C-4EC7-AC06-16E7F2E22DE7"), metadata: nil), SwiftData.Schema.PropertyMetadata(name: "name", keypath: \Link.<computed 0x0000000104b09b84 (String)>, defaultValue: Optional(""), metadata: nil), SwiftData.Schema.PropertyMetadata(name: "url", keypath: \Link.<computed 0x0000000104b09bc4 (String)>, defaultValue: Optional(""), metadata: nil), SwiftData.Schema.PropertyMetadata(name: "desc", keypath: \Link.<computed 0x0000000104b09c04 (String)>, defaultValue: Optional(""), metadata: nil), SwiftData.Schema.PropertyMetadata(name: "userEdited", keypath: \Link.<computed 0x0000000104b09664 (Bool)>, defaultValue: Optional(false), metadata: nil), SwiftData.Schema.PropertyMetadata(name: "modified", keypath: \Link.<computed 0x0000000104b09c44 (Date)>, defaultVal<…> Here's a fragment of the crash log: Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x000000019373222c Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5 Terminating Process: exc handler [80543] Thread 0 Crashed: 0 libswiftCore.dylib 0x19373222c _assertionFailure(_:_:file:line:flags:) + 176 1 SwiftData 0x22a222160 0x22a1ad000 + 479584 2 SwiftData 0x22a2709c0 0x22a1ad000 + 801216 3 SwiftData 0x22a221b08 0x22a1ad000 + 477960 4 SwiftData 0x22a27b0ec 0x22a1ad000 + 844012 5 SwiftData 0x22a27b084 0x22a1ad000 + 843908 6 SwiftData 0x22a28182c 0x22a1ad000 + 870444 7 SwiftData 0x22a2809e8 0x22a1ad000 + 866792 8 SwiftData 0x22a285204 0x22a1ad000 + 885252 9 SwiftData 0x22a281c7c 0x22a1ad000 + 871548 10 SwiftData 0x22a27cf6c 0x22a1ad000 + 851820 11 SwiftData 0x22a27cc48 0x22a1ad000 + 851016 12 SwiftData 0x22a27a6b0 0x22a1ad000 + 841392 13 SwiftData 0x22a285b2c 0x22a1ad000 + 887596 14 SwiftData 0x22a285a10 0x22a1ad000 + 887312 15 SwiftData 0x22a285bcc 0x22a1ad000 + 887756 16 SwiftData 0x22a27cf6c 0x22a1ad000 + 851820 17 SwiftData 0x22a27cc48 0x22a1ad000 + 851016 18 SwiftData 0x22a27a6b0 0x22a1ad000 + 841392 19 SwiftData 0x22a27c0d8 0x22a1ad000 + 848088 20 SwiftData 0x22a27a654 0x22a1ad000 + 841300 21 SwiftData 0x22a1be548 0x22a1ad000 + 70984 22 SwiftData 0x22a1cfd64 0x22a1ad000 + 142692 23 SwiftData 0x22a1b9618 0x22a1ad000 + 50712 24 SwiftData 0x22a1d2e8c 0x22a1ad000 + 155276 25 CoreData 0x187fbb568 thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 28 26 CoreData 0x187fc2300 partial apply for thunk for @callee_guaranteed () -> (@out A, @error @owned Error) + 24 27 CoreData 0x187fc19c4 closure #1 in closure #1 in NSManagedObjectContext._rethrowsHelper_performAndWait<A>(fn:execute:rescue:) + 192 28 CoreData 0x187fbbda8 thunk for @callee_guaranteed @Sendable () -> () + 28 29 CoreData 0x187fbbdd0 thunk for @escaping @callee_guaranteed @Sendable () -> () + 28 30 CoreData 0x187f663fc developerSubmittedBlockToNSManagedObjectContextPerform + 252 31 libdispatch.dylib 0x180336ac4 _dispatch_client_callout + 16 32 libdispatch.dylib 0x18032c940 _dispatch_lane_barrier_sync_invoke_and_complete + 56 33 CoreData 0x187fd7290 -[NSManagedObjectContext performBlockAndWait:] + 364 34 CoreData 0x187fc1fb8 NSManagedObjectContext.performAndWait<A>(_:) + 544 35 SwiftData 0x22a1b877c 0x22a1ad000 + 46972 36 SwiftData 0x22a1be2a8 0x22a1ad000 + 70312 37 SwiftData 0x22a1c0e34 0x22a1ad000 + 81460 38 SwiftData 0x22a23ea94 0x22a1ad000 + 596628 39 SwiftData 0x22a256828 0x22a1ad000 + 694312 40 Sourdough Buddy 0x104e5dc98 specialized ModelManager.deleteCommonData<A>(_:) + 144 (ModelManager.swift:128) [inlined] 41 Sourdough Buddy 0x104e5dc98 closure #1 in SettingsView.clearStarterData.getter + 876 (SettingsView.swift:243) It works if I do the following instead: try modelContext.delete(model: Link.self, where: #Predicate { !$0.userEdited }) Why would the func call work in development, but crash in production? And why does doing the more verbose way work instead? I think this is a bug. Thanks

I have been using the basic NSPersistentContainer with 100k+ records for a while now with no issues. The database size can fluctuate a bit but on average it takes up about 22mb on device. When I switch the container to NSPersistentCloudKitContainer, I see a massive increase in size to ~150mb initially. As the sync engine uploads records to iCloud it has ballooned to over 600mb on device. On top of that, the user's iCloud usage in settings reports that it takes up 1.7gb in the cloud. I understand new tables are added and history tracking is enabled but the size increase seems a bit drastic. I'm not sure how we got from 22mb to 1.7gb with the exact same data. A few other things that are important to note: I import all the 100k+ records at once when testing the different containers. At the time of the initial import there is only 1 relation (an import group record) that all the records are attached to. I save the background context only once after all the records and the import group have been made and added to the context. After the initial import, some of these records may have a few new relations added to them over time. I suppose this could be causing some of the size increase, but its only about 20,000 records that are updated. None of the records include files/ large binary data. Most of the attributes are encrypted. I'm syncing to the dev iCloud environment. When I do make a change to a single attribute in a record, CloudKit reports that every attribute has been modified (not sure if this is normal or not ) Also, When syncing to a new device, the sync can take hours - days. I'm guessing it's having to sync both the new records and the changes, but it exponentially gets slower as more records are downloaded. The console will show syncing activity, but new records are being added at a slower rate as more records are added. After about 50k records, it grinds to a halt and while the console still shows sync activity, only about 100 records are added every hour. All this to say i'm very confused where these issues are coming from. I'm sure its a combination of how i've setup my code and the vast record count, record history, etc. If anyone has any ideas it would be much appreciated.

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.

Apple WTF? What did you do to all my Apps? none of them work in iOS26.1 (all worked in 26.0). XCode simply says: CoreData: error: addPersistentStoreWithType:configuration:URL:options:error: returned error NSCocoaErrorDomain (134140) * SwiftData is supposed to do all these automatically 🤷🏻

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 } }

What have people's experience with converting locally stored app data to a more browser based accessible format? Firebase seems expensive, Subabase a bit more challenging, and CloudKit too restrictive.

it seems that is going to the appstore to find the app to execute the share but my app is not in the appstore yet. I am using a sandboxed user and a non sandboxed user, I have tried real phones connected to xcode and simulator same effect, looking for how to test my ckshare in testflight thanks