Deleting CoreData object results in EXC_BAD_INSTRUCTION - ios

Question

I have a list-based app. To support adding new elements to a list, what I do is that in the action handler, I create a new object, and I pass this to a details view. If the user cancels the details view, I want to delete the object - when I do this, I get an EXC_BAD_INSTRUCTION.
There must be some threading issue going on.
If I delete the note immediately after creating it (as a test), it works:
Button(action: {
self.newNote = NoteDataManager.makeNote(moc: self.moc, folder: self.savingFolder)
// DELETE immediately, as a test
self.moc.delete(self.newNote!)
self.showNewNoteView = true
}) {
Image(systemName: "square.and.pencil")
}
.sheet(isPresented: self.$showNewNoteView) {
CreateNoteView(newNote: self.newNote!, cancelAction: {
// DO NOTHING here (for now)
})
}
However, if I delete it in the handler for cancelAction (which is called when the user taps a cancel button), I get the exception:
Button(action: {
self.newNote = NoteDataManager.makeNote(moc: self.moc, folder: self.savingFolder)
self.showNewNoteView = true
}) {
Image(systemName: "square.and.pencil")
}
.sheet(isPresented: self.$showNewNoteView) {
CreateNoteView(newNote: self.newNote!, cancelAction: {
// MOVING the delete action here causes EXC_BAD_INSTRUCTION
self.moc.delete(self.newNote!)
})
}
My guess is that it's some sort of threading issue or something. Has anyone run into this and know how to work around this issue? It seems like it should work ...

Answer 1

Core Data is designed to work in a multithreaded environment. However, not every object under the Core Data framework is thread safe. To use Core Data in a multithreaded environment, ensure that:
Managed object contexts are bound to the thread (queue) that they are associated with upon initialization.
Managed objects retrieved from a context are bound to the same queue that the context is bound to.
Avoiding Problems
In general, avoid doing data processing on the main queue that is not user-related. Data processing can be CPU-intensive, and if it is performed on the main queue, it can result in unresponsiveness in the user interface. If your application will be processing data, like importing data into Core Data from JSON, create a private queue context and perform the import on the private context.
Do not pass NSManagedObject instances between queues. Doing so can result in corruption of the data and termination of the app. When it is necessary to hand off a managed object reference from one queue to another, use NSManagedObjectID instances.
You retrieve the managed object ID of a managed object by calling the objectID accessor on the NSManagedObject instance.
as per apple documentation
Concurrency is the ability to work with the data on more than one
queue at the same time. If you choose to use concurrency with Core
Data, you also need to consider the application environment. For the
most part, AppKit and UIKit are not thread-safe. In macOS in
particular, Cocoa bindings and controllers are not threadsafe—if you
are using these technologies, multithreading may be complex.
Using a Private Queue to Support Concurrency
In general, avoid doing data processing on the main queue that is not
user-related. Data processing can be CPU-intensive, and if it is
performed on the main queue, it can result in unresponsiveness in the
user interface. If your application will be processing data, such as
importing data into Core Data from JSON, create a private queue
context and perform the import on the private context.