I've defined 'public' and 'private' configurations in CoreData and configured the 'public' configuration to be handled in the CloudKit publicDB. The two configurations contain disjoint sets of NSManagedObject entity types. Some of the entities in the private configuration reference an entity in the public configuration using a UUID; thereby avoiding cross-configuration CoreData relationships. Avoiding this is a requirement of CoreData + CloudKit.
Now, since the UUID is meant to point to an object, in the awakeFromFetch() method I decided to fill in a transient property. No go. Even for a transient property there cannot be a cross-configuration relationship.
Why? Is there a way to avoid this constraint?
The cost of not having a transient property is to do a fetch of the object based on the UUID every time it is needed. Is this something that one should never worry about?
Core Data
RSS for tagSave your application’s permanent data for offline use, cache temporary data, and add undo functionality to your app on a single device using Core Data.
Posts under Core Data tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
I've had a couple SwiftData crashes in production I can’t figure out. Both times the crash happened when setting a child Model to a parent Model. The child should already be inserted in the context before setting on the parent. But a crash still happens at CoreData: _PFManagedObject_coerceValueForKeyWithDescription. The child does have some Codable properties, but they’re just a couple enum. This isn’t a super common crash either. I can’t seem to reproduce. Any ideas?
Simplified models:
@Model
final class Note {
@Relationship(deleteRule: .nullify, inverse: \CoffeeBag.notes)
var coffeeBag: CoffeeBag?
}
@Model
final class CoffeeBag {
var notes: [Note]? = []
}
And the crash stack trace:
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 6 Abort trap: 6
Terminating Process: MyApp [19953]
Triggered by Thread: 0
Last Exception Backtrace:
0 CoreFoundation 0x1a2bbe678 __exceptionPreprocess + 164 (NSException.m:249)
1 libobjc.A.dylib 0x19ae63c80 objc_exception_throw + 60 (objc-exception.mm:356)
2 CoreData 0x1aad117a8 _PFManagedObject_coerceValueForKeyWithDescription + 1576 (NSManagedObject.m:0)
3 CoreData 0x1aad110e8 _sharedIMPL_setvfk_core + 180 (NSManagedObject_Accessors.m:1491)
4 SwiftData 0x23d9359c8 static _DefaultBackingData.setRelationship(value:key:managedObject:) + 360 (BackingData.swift:364)
5 SwiftData 0x23d9388fc closure #1 in static _DefaultBackingData.setValue(key:managedObject:newValue:) + 256 (BackingData.swift:215)
6 SwiftData 0x23d8d6e4c thunk for @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
7 SwiftData 0x23d8d6e74 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
8 CoreData 0x1aad087c4 developerSubmittedBlockToNSManagedObjectContextPerform + 156 (NSManagedObjectContext.m:3983)
9 CoreData 0x1aad08698 -[NSManagedObjectContext performBlockAndWait:] + 208 (NSManagedObjectContext.m:4094)
10 SwiftData 0x23d933758 static _DefaultBackingData.setValue(key:managedObject:newValue:) + 360 (BackingData.swift:211)
11 SwiftData 0x23d9383b0 _DefaultBackingData.setValue<A>(forKey:to:) + 232 (BackingData.swift:174)
12 SwiftData 0x23d93b328 protocol witness for BackingData.setValue<A>(forKey:to:) in conformance _DefaultBackingData<A> + 24 (<compiler-generated>:0)
13 SwiftData 0x23d8f32dc PersistentModel.setValue<A>(forKey:to:) + 288 (PersistentModel.swift:102)
14 MyApp 0x100f166d4 closure #1 in MyAppSchemaV6.Note.coffeeBag.setter + 132 (@__swiftmacro_7MyApp0aB8SchemaV6O4NoteC9coffeeBag18_PersistedPropertyfMa_.swift:15)
15 MyApp 0x100f22864 partial apply for closure #1 in MyAppSchemaV6.Note.coffeeBag.setter + 16 (<compiler-generated>:0)
16 libswiftObservation.dylib 0x247ff21b8 ObservationRegistrar.withMutation<A, B, C>(of:keyPath:_:) + 100 (ObservationRegistrar.swift:365)
17 MyApp 0x100f21c28 MyAppSchemaV6.Note.coffeeBag.setter + 172 (@__swiftmacro_7MyApp0aB8SchemaV6O4NoteC9coffeeBag18_PersistedPropertyfMa_.swift:14)
18 MyApp 0x100f21c28 closure #1 in closure #1 in closure #4 in BrewSummaryView.body.getter + 1076 (BrewSummaryView.swift:116)
19 SwiftUI 0x1a81b77b0 ButtonAction.callAsFunction() + 260 (Button.swift:598)
// the rest is trimmed off to fit...
I have an app that is already running with CoreData, and I want to allow the users to upload their data to iCloud so, in the case they need to delete their apps or change devices, they don't lose it.
Every time the app is opened, there is a synchronization that happens between CoreData and a JSON file fixture, in order to fill the app with its base values (creating NSManagedObject instances from the aforementioned fixture).
Before the iCloud sync, the CoreData model had some constraints for different entities, to enforce uniqueness, but these had to be stripped since CloudKit doesn't support them. Most of these constraints were basically ids that came from the JSON and represent an item in our Firebase database.
Given that, I want to make the underlying CKRecord.id the same as these ids, so I can avoid the situation where, if a person open the app in a second device, the fixture data is repeated, since the fixture runs before the sync with the iCloud happens.
Is that possible? Any help would be appreciated.
What interfaces do I use to propagate a CloudKit change in a shared zone to a notification/badge to all participants in the shared zone?
Assume I have a 'League' that is the root object in a shared zone and that N Players are members of the league. One of the players, the 'organizer', schedules a 'Game' that is open to any of the players. When the organizer creates the game (in the league's shared zone) and it is mirrored in CloudKit, how can the other players see it (as a timely notification)?
I already observe .NSPersistentStoreRemoteChange on NSPersistentStoreCoordinator and NSPersistentCloudKitContainer.eventChangedNotification on NSPersistentCloudKitContainer. Are these delivered in the background? Can/Should they generate a 'local/remote' notification for handling at the AppDelegate level? How?
Do I need to use a CKDatabaseSubscription looking for CD_Game records directly? (I'd rather not; because then I'd have a potential race between the remote iCloud database(s) and the local CoreData)
I'm sorta baffled right now. I am trying to wonder how I might detect a updated SQL Store in an older app.
have a baseline app, and create a SQL-based repository
in an updated app, change the model and verify that you can see the updated model version. Using lightweight migration
re-run the older app (which will inherit the newer SQL repository).
YIKES - no error when creating the NSPersistenStoreCoordinator!
Nothing in the metadata to imply the store is newer than the model:
[_persistentStoreCoordinator metadataForPersistentStore:store]
My question: is there any way to detect this condition?
David
I developing simple app to calculate personal money income and consumption.
I use CORE DATA to save my model.
The models consists of this
CDCatalogWallet
var name: String
var ref: String
CDCatalogStateIncome
var name: String
var ref: String
CDDocumentIncome
var ref: String
var wallet: CDCatalogWallet (relationship has one)
var states_: CDDocumentIncomeState (relationship has many)
CDDocumentIncomeState
var cdCatalogStateIncome: CDCatalogStateIncome (relationship has one)
var document: CDDocumentIncome (relationship has one)
CDDocumentIncome hasMany -> CDDocumentIncomeState hasOne -> CDCatalogStateIncome
The bug shows when we pushing CDDocumentIncomeState view
The model is simple.
The CDDocumentIncome has relationship property cdCatalogStateIncome (relationship many).
We open view with CDDocumentIncome and want to add new cdCatalogStateIncome to CDDocumentIncome
Then we open view with new cdCatalogStateIncome.
On this screen cdCatalogStateIncome has a relationship to CDDocumentIncomeState.
But view does not opened. Console constantly print messages
DocumentIncomeStateDetailView: @self changed.
DocumentIncomeStateDetailView: @self changed.
DocumentIncomeStateDetailView: @self changed.
DocumentIncomeStateDetailView: @self changed.
Also memory increase constantly and very fast.
I understand that the view renders constantly. But I cannot figure out what cause a bug.
The full code is available on github
Github Project
How can one avoid SwiftUI processing of views referencing a CoreData entity that has been deleted?
I've taken to 'wrapping' View body's with the following:
struct ManagedObjectDeleteWrapper<Object, Root> : View
where Object : NSManagedObject, Root : View {
var object: Object
var root: (Object) -> Root
var body: some View {
Group {
if object.isFault { EmptyView() }
else { root (object) }
}
}
}
like such:
struct GameView: View {
@EnvironmentObject private var game: Game
var body: some View {
ManagedObjectDeleteWrapper (object: game) { _ in
// Show `game` attributes and relationships
}
}
}
but this has become quite tedious. It is not as simple a wrapping the 'top-level' view (in my App, three or so TabViews), but one must wrap multiple subviews if they also reference game.
How can I approach this short of using game.isFault or ManagedObjectDeleteWrapper everywhere?
I'm cognizant that perhaps my 'view flow' is leading to this problem; is there a generic approach to view hierarchies that avoids the problem? Maybe 'only delete an object from a list view; only show the object content view a navigation link on that list view' ? My current design has three tab views showing game content and one tab showing 'competitions' (as set of games); a game is deleted from the competitions tab... and if that game is being displayed all the other tab views are invalid.
I've been trying to build an example of NSStagedMigrationManager from some Core Data migration tests to replace a custom migration manager solution I'd constructed, without much success.
The Core Data model has seven model versions. Most support lightweight migration, but two of the migrations in the middle of the sequence used NSMappingModel.
In the first beta, just attempting to construct an NSStagedMigrationManager from the series of stages failed with an unrecognized selector. That no longer happens in b4, but I now get an error that "Duplicate version checksums across stages detected."
If I restrict myself to just the first three versions of the model (that only require lightweight migration), I can build the migration manager. But if I attempt to use it to migrate a persistent store, it fails somewhere in NSPersistentStoreCoordinator with a nilError.
The documentation is almost nonexistent for this process, and the WWDC session that introduced it isn't much more than a breezy overview. So maybe I'm holding it wrong?
(And, yes: FB12339663)
From core data I generate data for map marker pins. When user selects a marker pin I display the data in a popup label with multiple rows, when I click on the pin. This is working for one marker pin. Now, I need to iterate over a list and generate several of those markers each with unique popup label data.
The code:
struct MapView: UIViewRepresentable {
var annotationOnTap: (_ title: String) -> Void
@Binding var pins: [GpsData.MyEndPt]
let key: String
private static var mapViewStore = [String : MKMapView]()
func makeUIView(context: Context) -> MKMapView {
if let mapView = MapView.mapViewStore[key] {
mapView.delegate = context.coordinator
return mapView
}
let mapView = MKMapView(frame: .zero)
mapView.delegate = context.coordinator
MapView.mapViewStore[key] = mapView
return mapView
}
func updateUIView(_ uiView: MKMapView, context: Context) {
uiView.addAnnotations(pins)
}
func makeCoordinator() -> MapCoordinator {
MapCoordinator(self)
}
final class MapCoordinator: NSObject, MKMapViewDelegate {
var parent: MapView
init(_ parent: MapView) {
self.parent = parent
}
func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> MKAnnotationView? {
let PINID:String = "MyEndPoint"
var mPin: MKMarkerAnnotationView? = nil
let subtitleView = UILabel()
subtitleView.font = subtitleView.font.withSize(12)
subtitleView.numberOfLines = 0
if (mPin == nil ) {
mPin = MKMarkerAnnotationView(annotation: annotation, reuseIdentifier: PINID)
mPin?.canShowCallout = true
} else{
mPin?.annotation = annotation
}
mPin?.leftCalloutAccessoryView = nil
let btn = UIButton(type: .detailDisclosure)
mPin?.rightCalloutAccessoryView = btn
let zip:String = "77065"
let formattedSalesStr:String = "100"
let totalTargetText:String = "500"
let paddedLoad = formattedSalesStr.padding(toLength: 50, withPad: " ", startingAt: 0)
let paddedCapacity = totalTargetText.padding(toLength: 50, withPad: " ", startingAt: 0)
subtitleView.text = "Total sales: "
subtitleView.text! += paddedLoad
subtitleView.text! += " \r\n"
subtitleView.text! += "Total Target: "
subtitleView.text! += paddedCapacity
subtitleView.text! += " \r\n"
subtitleView.text! += paddedzip
mPin!.detailCalloutAccessoryView = subtitleView
return mPin!
}
}
}
As you can see in the above method I have hardcoded values for my popup marker label. So I tried to iterate over the @Binding pins, populate each mPin, and return an array of MKAnnotationView, like this:
func mapView(_ mapView: MKMapView, viewFor annotation: MKAnnotation) -> [MKAnnotationView] {
let PINID:String = "MyEndPoint"
var i:Int = 1
var mPins = [MKAnnotationView]()
for detail in self.parent.pins {
var mPin: MKMarkerAnnotationView? = nil
let subtitleView = UILabel()
subtitleView.font = subtitleView.font.withSize(12)
subtitleView.numberOfLines = 0
if (mPin == nil ) {
mPin = MKMarkerAnnotationView(annotation: annotation, reuseIdentifier: PINID)
mPin?.canShowCallout = true
} else{
mPin?.annotation = annotation
}
mPin?.leftCalloutAccessoryView = nil
let btn = UIButton(type: .detailDisclosure)
mPin?.rightCalloutAccessoryView = btn
subtitleView.text! += String(i)
subtitleView.text = "Total Load: "
subtitleView.text! += String(detail.sales)
subtitleView.text! += " \r\n"
subtitleView.text! += "Total Target: "
subtitleView.text! += String(detail.target)
subtitleView.text! += " \r\n"
i += 1
// }
mPin!.detailCalloutAccessoryView = subtitleView
mPins.append(mPin!)
}
return mPins
}
The marker pins show up, but then the label does not popup. How to fix this?
Suggestions on what is causing this? Where to look? Could it be related to having a CoreData 'abstract entity' that occurs in two configurations - one configuration for 'public' and one for 'private/shared'?
Greetings - The following code appears to work, but when a list item is deleted from a Category section that contains other list items, the app crashes (error = "Thread 1: EXC_BREAKPOINT (code=1, subcode=0x180965354)"). I've confirmed that the intended item is deleted from the appData.items array - the crash appears to happen right after the item is deleted.
I suspect that the problem somehow involves the fact that the AppData groupedByCategory dictionary and sortedByCategory array are computed properties and perhaps not updating as intended when an item is deleted? Or maybe the ContentView doesn't know they've been updated? My attempt to solve this by adding "appData.objectWillChange.send()" has not been successful, nor has my online search for solutions to this problem.
I'm hoping someone here will either know what's happening or know I could look for additional solutions to try. My apologies for all of the code - I wanted to include the three files most likely to be the source of the problem. Length restrictions prevent me from including the "AddNewView" code and some other details, but just say the word if that detail would be helpful.
Many, many thanks for any help anyone can provide!
@main
struct DeletionCrashApp: App {
let persistenceController = PersistenceController.shared
// Not sure where I should perform this command
@StateObject var appData = AppData(viewContext: PersistenceController.shared.container.viewContext)
var body: some Scene {
WindowGroup {
ContentView()
.environment(\.managedObjectContext, persistenceController.container.viewContext)
.environmentObject(appData)
}
}
}
import Foundation
import SwiftUI
import CoreData
class AppData: NSObject, ObservableObject {
// MARK: - Properties
@Published var items: [Item] = []
private var fetchedResultsController: NSFetchedResultsController<Item>
private (set) var viewContext: NSManagedObjectContext // viewContext can be read but not set from outside this class
// Create a dictionary based upon the category
var groupedByCategory: [String: [Item]] {
Dictionary(grouping: items.sorted(), by: {$0.category})
}
// Sort the category-based dictionary alphabetically
var sortedByCategoryHeaders: [String] {
groupedByCategory.map({ $0.key }).sorted(by: {$0 < $1})
}
// MARK: - Methods
func deleteItem(itemObjectID: NSManagedObjectID) {
do {
guard let itemToDelete = try viewContext.existingObject(with: itemObjectID) as? Item else {
return // exit the code without continuing or throwing an error
}
viewContext.delete(itemToDelete)
} catch {
print("Problem in the first do-catch code: \(error)")
}
do {
try viewContext.save()
} catch {
print("Failure to save context: \(error)")
}
}
// MARK: - Life Cycle
init(viewContext: NSManagedObjectContext) {
self.viewContext = viewContext
let request = NSFetchRequest<Item>(entityName: "ItemEntity")
request.sortDescriptors = [NSSortDescriptor(keyPath: \Item.name, ascending: true)]
fetchedResultsController = NSFetchedResultsController(fetchRequest: request,
managedObjectContext: viewContext,
sectionNameKeyPath: nil,
cacheName: nil)
super.init()
fetchedResultsController.delegate = self
do {
try fetchedResultsController.performFetch()
guard let items = fetchedResultsController.fetchedObjects else {
return
}
self.items = items
} catch {
print("failed to fetch items: \(error)")
}
} // end of init()
} // End of AppData
extension AppData: NSFetchedResultsControllerDelegate {
func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
guard let items = controller.fetchedObjects as? [Item] else { return }
self.items = items
}
}
import SwiftUI
import CoreData
struct ContentView: View {
@Environment(\.managedObjectContext) private var viewContext
@EnvironmentObject var appData: AppData
@State private var showingAddNewView = false
@State private var itemToDelete: Item?
@State private var itemToDeleteObjectID: NSManagedObjectID?
var body: some View {
NavigationView {
List {
ForEach(appData.sortedByCategoryHeaders, id: \.self) { categoryHeader in
Section(header: Text(categoryHeader)) {
ForEach(appData.groupedByCategory[categoryHeader] ?? []) { item in
Text(item.name)
.swipeActions(allowsFullSwipe: false) {
Button(role: .destructive) {
self.itemToDelete = appData.items.first(where: {$0.id == item.id})
self.itemToDeleteObjectID = itemToDelete!.objectID
appData.deleteItem(itemObjectID: itemToDeleteObjectID!)
// appData.objectWillChange.send() <- does NOT fix the fatal crash
} label: {
Label("Delete", systemImage: "trash.fill")
}
} // End of .swipeActions()
} // End of ForEach(appData.groupedByReplacementCategory[categoryHeader]
} // End of Section(header: Text(categoryHeader)
} // End of ForEach(appData.sortedByCategoryHeaders, id: \.self)
} // End of List
.navigationBarTitle("", displayMode: .inline)
.navigationBarItems(
trailing:
Button(action: {
self.showingAddNewView = true
}) {
Image(systemName: "plus")
}
)
.sheet(isPresented: $showingAddNewView) {
// show AddNewView here
AddNewView(name: "")
}
} // End of NavigationView
} // End of body
} // End of ContentView
extension Item {
@nonobjc public class func fetchRequest() -> NSFetchRequest<Item> {
return NSFetchRequest<Item>(entityName: "ItemEntity")
}
@NSManaged public var category: String
@NSManaged public var id: UUID
@NSManaged public var name: String
}
extension Item : Identifiable {
}
I'm currently facing an interesting issue. A customer is reporting back that my app is crashing on launch for them. I can see the crash logs (using AppCenter for crash management), and the reason the app is crashing seems to be in CoreData:
(Attaching text for seachability, and screenshot for readability):
libsystem_platform.dylib
_platform_memmove$VARIANT$Haswell
CoreData
-[_PFExternalReferenceData initForExternalLocation:safeguardLocation:data:protectionLevel:]
CoreData
-[NSSQLSavePlan _populateRow:fromObject:timestamp:inserted:shouldAddToRowCache:]
CoreData
-[NSSQLSavePlan _createRowsForSave]
CoreData
-[NSSQLSaveChangesRequestContext executePrologue]
CoreData
-[NSSQLCore dispatchRequest:withRetries:]
CoreData
-[NSSQLCore executeRequest:withContext:error:]
CoreData
-[NSPersistentStoreCoordinator executeRequest:withContext:error:]
CoreData
-[NSPersistentStoreCoordinator _routeHeavyweightBlock:]
CoreData
-[NSPersistentStoreCoordinator executeRequest:withContext:error:]
CoreData
-[NSManagedObjectContext save:]
I have never seen that crash before, it's the first time it is appearing since CoreData has been incorporated into the app (in 2016 or so). Any hints on what could possibly be happening? I am unable to provoke the crash on my end, thus debugging is quite interesting.
I'm working on an iOS app using SwiftUI and CoreData and am running into a problem that I cannot seem to figure out.
To provide a little bit of information of what I am trying to do:
I have two CoreData entities that have a One-To-Many relationship:
Tarantula - A tarantula may molt many times (To Many) and when deleted, all of the molts shold also be removed (Cascade)
Molt - A molt belongs to a single Tarantula (To One) and when
deleted, should have the reference removed from the Tarantula (Nullify)
I then have a view that lists all of the molts for a given Tarantula that allows adding and deleting molts. It looks like this:
struct MoltListView: View {
		private static let DATE_FORMATTER: DateFormatter = {
						let d = DateFormatter()
						d.dateFormat = "MMM d, y"
						return d
				}()
		
		@Environment(\.managedObjectContext) private var viewContext
		
		@ObservedObject private var tarantula: Tarantula
		@FetchRequest private var molts: FetchedResults<Molt>
		@State private var userMessage: String = ""
		@State private var displayMessage: Bool = false
		
		init(tarantula: Tarantula) {
				self.tarantula = tarantula
				self._molts = FetchRequest(entity: Molt.entity(),
																	 sortDescriptors: [NSSortDescriptor(keyPath: \Molt.date, ascending: false)],
																	 predicate: NSPredicate(format: "tarantula = %@", tarantula))
		}
		
		var body: some View {
				List {
						Section(header: Text("Summary")) {
								Text("\(molts.count) Molt\(molts.count == 1 ? "" : "s")")
						}
						Section(header: Text("Molts")) {
								NavigationLink(destination: MoltView(tarantula: tarantula, molt: Molt.newModel())) {
										Text("Add Molt").foregroundColor(.blue)
								}
								ForEach(molts, id: \.self) { molt in
										NavigationLink(destination: MoltView(tarantula: tarantula, molt: molt)) {
												Text(MoltListView.DATE_FORMATTER.string(from: molt.modelDate))
										}
								}
								.onDelete(perform: deleteItems)
						}
				}.alert(isPresented: $displayMessage) {
						Alert(title: Text("Save Failure"), message: Text(userMessage), dismissButton: .default(Text("Ok")))
				}
		}
		
		private func deleteItems(offsets: IndexSet) {
				withAnimation {
						offsets.map { molts[$0] }.forEach(viewContext.delete)
						do {
								try viewContext.save()
						} catch {
								viewContext.rollback()
								userMessage = "\(error): \(error.localizedDescription)"
								displayMessage.toggle()
						}
				}
		}
}
The error I am experiencing comes from whenever I try to delete a molt from the list view. The app instantly crashes and the error is:
Simultaneous accesses to 0x7f92efc61cb8, but modification requires exclusive access
Find the complete error here:
error - https://developer.apple.com/forums/content/attachment/6d74dcde-d82b-4024-ade0-5936d8926488
I have tried removing the animation block and have played around with removing different UI components/restructuring.
The only way I have been able to prevent this error is to remove the delete rule on the Molt->Tarantula relationship from Nullify to No Action. However, this seems more like a hack to me instead of a fix.
Was hoping for some help on this issue.
When I add or delete data of my entity type I can see the updates (between the simulator and the phone) but when i edit I dont see the updates although table view is reloaded. The console says
Ignoring remote change notification because it didn't change any entities tracked by persistent history
When I rebuild the app for both device and simulator I see it reflecting the most current changes.
Any help?
Neerav
Can anyone tell me how to use Swift Data and Core Data with playground?
Hello, developers,
I'm experiencing UI lag in SwiftUI when updating Core Data or SwiftData entities in the background, noticeable during scrolling. This issue arises regardless of whether the updated entity is currently displayed. For instance, updating a "Song" entity with a new localURL from a background download and saving background context affects an unrelated "Artists" list view.
Scenario: The lag is most evident when completing background downloads and updating entity properties, causing a hitch in scrolling interactions when using SwiftUI @FetchRequest or @Query for displaying data.
Observations:
The issue occurs with both Core Data @FetchRequest and SwiftData @Query property wrappers.
It affects unrelated views, suggesting a broader issue with SwiftUI's handling of data updates during user interactions.
Seeking Community Insights:
Has anyone faced similar issues with SwiftUI and background data updates?
Any strategies for reducing this lag/hitch?
Insights into SwiftUI's data update and view re-rendering process in this context?
For a practical example, Apple's project on loading and displaying a large data feed demonstrates this issue. Try tapping the refresh button while scrolling to observe the lag.
Appreciate any advice or solutions!
Best Regards,
[Personal Information Edited by Moderator]
I have a CoreData entity with a transformable property data that stores an NSDictionary. All of the classes inside the dictionary conform to NSSecureCoding
I have been getting many instances of this warning :
'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release
In trying to clean up the warning and future-proof my app, but I am running into a lot of trouble.
My understanding is that using NSKeyedUnarchiveFromData as the transformer in my data properties attribute should work, since the top level class is a dictionary and all of the contents conform to NSSecureCoding.
However, my data dictionary is now coming back as NSConcreteMutableData so I cannot access the data in it.
I have also tried creating a custom value transformer with additional allowedTopLevelClasses, but that hasn't helped, and again, the topLevel type is an NSDictionary, which should be allowed.
Thank you for any guidance.
I'm experiencing an unresponsive UI since MacOS 14.0 and iOS 17.0 when calling record(for: ) or recordID(for:) on the instance of NSPersistentCloudKitContainer.
On MacOS, the UI freeze almost always happens when calling the function.
On iOS, it is necessary that the device (or simulator) does not have any network connection.
I would like to ask if anyone experienced the same problem. I have posted the problem twice to Apple via the Feedback app (once for iOS and once for MacOS). No reply yet on MacOS but on iOS Apple marked it as resolved because apparently no one but me has experienced this problem.
In the meantime, I have set up a minimum reproducible example app (MRE).:
https://github.com/DominikButz/NotesApp-Cloud-Kit-Record-UI-Freeze-
Anyone interested, please read the readme of the repository. It includes step by step instructions on how to reproduce the bug.
I can't rule out I have misunderstood the usage of CoreData and CloudKit - in that case please point me in the right direction.
The app I'm working on should also work offline (and on MacOS!) but it doesn't do so properly as long as this bug exists.
I'm exploring switching to SwiftData (which would mean no one using macOS 13 / iOS 16 can use my app...) but I would still need to access cloud kit records even with SwiftData and I fear the bug also exists in SwiftData.
Thanks
In Core data public configuration, added new attribute to entities, new entities, but the changes are neither synchronized nor data is transferred to existing container schema in cloudkit.
private var _publicPersistentStore: NSPersistentStore?
var publicPersistentStore: NSPersistentStore {
return _publicPersistentStore!
}
private var _privatePersistentStore: NSPersistentStore?
var privatePersistentStore: NSPersistentStore {
return _privatePersistentStore!
}
private var _sharedPersistentStore: NSPersistentStore?
var sharedPersistentStore: NSPersistentStore {
return _sharedPersistentStore!
}
static let shared = PersistenceController()
static var preview: PersistenceController = {
let result = PersistenceController(inMemory: true)
let viewContext = result.container.viewContext
do {
try viewContext.save()
} catch {
// Replace this implementation with code to handle the error appropriately.
// fatalError() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
let nsError = error as NSError
fatalError("Unresolved error \(nsError), \(nsError.userInfo)")
}
return result
}()
let container: NSPersistentCloudKitContainer
init(inMemory: Bool = false) {
container = NSPersistentCloudKitContainer(name: “GS”)
if inMemory {
container.persistentStoreDescriptions.first!.url = URL(fileURLWithPath: "/dev/null")
}
guard let defaultDescription = container.persistentStoreDescriptions.first else {
fatalError("###\(#function): failed to retrieve a persistent store description.")
}
let containerIdentifier = defaultDescription.cloudKitContainerOptions!.containerIdentifier
print(containerIdentifier)
print(defaultDescription.url as Any)
let url = defaultDescription.url?.deletingLastPathComponent()
print(url as Any)
// Public
let publicDescription = NSPersistentStoreDescription(url: url!.appendingPathComponent("public.sqlite"))
publicDescription.configuration = "Public"
print(publicDescription.url)
let publicOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: containerIdentifier)
publicOptions.databaseScope = .public
publicDescription.cloudKitContainerOptions = publicOptions
publicDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
publicDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey)
// Private
let privateDescription = NSPersistentStoreDescription(url: url!.appendingPathComponent("private.sqlite"))
privateDescription.configuration = "Private"
print(privateDescription.url)
let privateOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: containerIdentifier)
privateOptions.databaseScope = .private
privateDescription.cloudKitContainerOptions = privateOptions
privateDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
privateDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey)
// Shared
guard let sharedDescription = privateDescription.copy() as? NSPersistentStoreDescription else {
fatalError("#\(#function): Copying the private store description returned an unexpected value.")
}
sharedDescription.url = url!.appendingPathComponent("shared.sqlite")
print(sharedDescription.url)
sharedDescription.configuration = "Shared"
let sharedOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: containerIdentifier)
sharedOptions.databaseScope = .shared
sharedDescription.cloudKitContainerOptions = sharedOptions
sharedDescription.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey)
sharedDescription.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey)
container.persistentStoreDescriptions = [publicDescription, privateDescription, sharedDescription]
container.loadPersistentStores(completionHandler: { (storeDescription, error) in
if let error = error as NSError? {
// Replace this implementation with code to handle the error appropriately.
// fatalError() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
/*
Typical reasons for an error here include:
* The parent directory does not exist, cannot be created, or disallows writing.
* The persistent store is not accessible, due to permissions or data protection when the device is locked.
* The device is out of space.
* The store could not be migrated to the current model version.
Check the error message to determine what the actual problem was.
*/
fatalError("Unresolved error \(error), \(error.userInfo)")
}
else {
if let cloudKitContainerOptions = storeDescription.cloudKitContainerOptions {
if #available(iOS 16.0, *) {
if .public == storeDescription.cloudKitContainerOptions?.databaseScope {
print("loaded public store")
// self._publicPersistentStore = container.persistentStoreCoordinator.persistentStore(for: storeDescription.url!)
} else if .private == storeDescription.cloudKitContainerOptions?.databaseScope {
print("loaded private store")
//self._privatePersistentStore = container.persistentStoreCoordinator.persistentStore(for: storeDescription.url!)
} else if .shared == storeDescription.cloudKitContainerOptions?.databaseScope {
print("loaded shared store")
//self._sharedPersistentStore = container.persistentStoreCoordinator.persistentStore(for: storeDescription.url!)
}
} else {
// Fallback on earlier versions
}
}
}
})
container.viewContext.automaticallyMergesChangesFromParent = true
container.viewContext.mergePolicy = NSMergeByPropertyStoreTrumpMergePolicy // external changes trumping in-memory changes.
}
func save() {
let context = container.viewContext
if context.hasChanges {
do {
try context.save()
} catch {
// Show some error here
print("save error")
}
}
}
}
Tried new container on cloudkit, problem persists. Working previously until I updated Xcode to 15.2 and iOs 16.2. Can you please tell me why coredata is not synchronized for public configuration.
We are facing a challenging memory issue during a Core Data heavy weight migration in our app.
Background: We store sizable data(~250kb/record) in a Core Data entity called "Email." We have roughly 20k records. We are loading the "Email" list using fetchedResultsController with batching. Recently, we split the another entity named "Profile" into "Profile" and "Address" entities, requiring a heavyweight migration.
The Problem: This migration consumes an exorbitant amount of memory, causing the OS to kill our app. Interestingly, the "Email" entity is causing the brunt of the memory usage, even though the actual migration code deals with the "Profile" entity to create "Address." If we remove the "sizable" data from "Email" and attempt for migration then the migration is successful.
My Questions: Is this memory consumption expected behavior? Why does the "Email" entity, seemingly unrelated to the actual migration, seem to be the main memory culprit?
How can I prevent the OS from terminating my app during migration? Are there strategies to optimize memory usage or mitigate memory pressure?
Also we are encountering a delay in loading the email list on the very first launch of app. Subsequent launches work comparatively faster. Is that related to storing bigger size data in Email entity?