NSFetchedResultsController calls didChangeObject delete instead of update

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.

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.