This is the code, I save the model via Magical Record:
MagicalRecord.saveWithBlock({ (localContext) -> Void in
var localNotification =
I know, late answer, but maybe helpful. I had the same problem with iOS 11.3 and Xcode 9.3 and it was driving me mad. The solution was to provide the correct data type in the arguments array for the predicate. After changing it from string interpolation to the actual expected type (NSNumber
in that particular case), the correct NSFetchedResultsChangeType
was Update
instead of Delete
.
I chose string interpolation, because the data type (Bool
in that particular case), was used as scalar type in the Core Data model and NSPredicate
accepted the scalar type during compilation, but raised an runtime exception. Changing it to string interpolation fixed the runtime error and the predicate worked as expected, except the wrong NSFetchedResultsChangeType
was called.
So it seems the bug in Core Data still exists or maybe this was intended to force the correct data type usage.
What is happening here is that instead of the NSFetchedResultsChangeUpdate
change event you expect, you are getting a NSFetchedResultsChangeDelete
followed by NSFetchedResultsChangeInsert
. You may also see a NSFetchedResultsChangeMove
with the same indexPath as source and destination. This is a known issue in several beta versions of iOS 9 22380191 and others.