iOS 9 - "attempt to delete and reload the same index path"

This seems to be a bug in iOS 9 (which is still beta) and is also discussed in the Apple Developer Forum

• iOS 9 CoreData NSFetchedResultsController update causes blank rows in UICollectionView/UITableView

I can confirm the problem with the iOS 9 Simulator from Xcode 7 beta 3.I observed that for an updated managed object, the didChangeObject: delegate method is called twice: Once with the NSFetchedResultsChangeUpdate event and then again with the NSFetchedResultsChangeMove event (and indexPath == newIndexPath).

Adding an explicit check for indexPath != newIndexPathas suggested in the above thread seems to solve the problem:

        case .Move:            if indexPath != newIndexPath {                tableView.deleteRowsAtIndexPaths([indexPath!], withRowAnimation: .Fade)                tableView.insertRowsAtIndexPaths([newIndexPath!], withRowAnimation: .Fade)        }

Update: the described problem occurs only on iOS 8 when building against iOS 9.0 or iOS 9.1 (beta) SDK.

I came up with some horrible workaround today after playing with Xcode 7 beta 6 (iOS 9.0 beta 5) and it seems that it works.

You cannot use reloadRowsAtIndexPaths because in certain cases it's called too early and may cause inconsistency, instead you should manually update your cell.

I still think that the best option is to simply call reloadData.

I believe you can adapt my code for swift with no efforts, I have objective-c project here.

@property NSMutableIndexSet *deletedSections, *insertedSections;// ...- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller {    [self.tableView beginUpdates];    self.deletedSections = [[NSMutableIndexSet alloc] init];    self.insertedSections = [[NSMutableIndexSet alloc] init];}- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller {    [self.tableView endUpdates];}- (void)controller:(NSFetchedResultsController *)controller didChangeSection:(id<NSFetchedResultsSectionInfo>)sectionInfo atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type {    NSIndexSet *indexSet = [NSIndexSet indexSetWithIndex:sectionIndex];    switch(type) {        case NSFetchedResultsChangeDelete:            [self.tableView deleteSections:indexSet withRowAnimation:UITableViewRowAnimationAutomatic];            [self.deletedSections addIndexes:indexSet];            break;        case NSFetchedResultsChangeInsert:            [self.tableView insertSections:indexSet withRowAnimation:UITableViewRowAnimationAutomatic];            [self.insertedSections addIndexes:indexSet];            break;        default:            break;    }}- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath {    switch(type) {        case NSFetchedResultsChangeDelete:            [self.tableView deleteRowsAtIndexPaths:@[ indexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];            break;        case NSFetchedResultsChangeInsert:            [self.tableView insertRowsAtIndexPaths:@[ newIndexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];            break;        case NSFetchedResultsChangeMove:            // iOS 9.0b5 sends the same index path twice instead of delete            if(![indexPath isEqual:newIndexPath]) {                [self.tableView deleteRowsAtIndexPaths:@[ indexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];                [self.tableView insertRowsAtIndexPaths:@[ newIndexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];            }            else if([self.insertedSections containsIndex:indexPath.section]) {                // iOS 9.0b5 bug: Moving first item from section 0 (which becomes section 1 later) to section 0                // Really the only way is to delete and insert the same index path...                [self.tableView deleteRowsAtIndexPaths:@[ indexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];                [self.tableView insertRowsAtIndexPaths:@[ indexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];            }            else if([self.deletedSections containsIndex:indexPath.section]) {                // iOS 9.0b5 bug: same index path reported after section was removed                // we can ignore item deletion here because the whole section was removed anyway                [self.tableView insertRowsAtIndexPaths:@[ indexPath ] withRowAnimation:UITableViewRowAnimationAutomatic];            }            break;        case NSFetchedResultsChangeUpdate:            // On iOS 9.0b5 NSFetchedResultsController may not even contain such indexPath anymore            // when removing last item from section.            if(![self.deletedSections containsIndex:indexPath.section] && ![self.insertedSections containsIndex:indexPath.section]) {                // iOS 9.0b5 sends update before delete therefore we cannot use reload                // this will never work correctly but at least no crash.                 UITableViewCell *cell = [self.tableView cellForRowAtIndexPath:indexPath];                [self _configureCell:cell forRowAtIndexPath:indexPath];            }            break;    }}

Xcode 7 / iOS 9.0 only

In Xcode 7 / iOS 9.0 NSFetchedResultsChangeMove is still being sent instead of "update".

As a simple workaround, just disable animations for that case:

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath {    UITableViewRowAnimation animation = UITableViewRowAnimationAutomatic;    switch(type) {        case NSFetchedResultsChangeMove:            // @MARK: iOS 9.0 bug. Move sent instead of update. indexPath = newIndexPath.            if([indexPath isEqual:newIndexPath]) {                animation = UITableViewRowAnimationNone;            }            [self.tableView deleteRowsAtIndexPaths:@[ indexPath ] withRowAnimation:animation];            [self.tableView insertRowsAtIndexPaths:@[ newIndexPath ] withRowAnimation:animation];            break;        // ...    }}

With regard to this happening on iOS8, with builds compiled against iOS9, on top of the indexPath==newIndexPath problem addressed by some other answers, something else happens which is very weird.

The NSFetchedResultsChangeType enum has four possible values (comments with values are mine):

public enum NSFetchedResultsChangeType : UInt {    case Insert // 1    case Delete // 2    case Move   // 3    case Update // 4}

.. however, the controller:didChangeObject:atIndexPath:forChangeType function is sometimes called with an invalid value 0x0.

Swift seems to default to the first switch case at that point so if you have the following structure:

func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath?, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath?) {        switch type {            case .Insert: tableView.insertRowsAtIndexPaths([newIndexPath!], withRowAnimation: UITableViewRowAnimation.Fade)            case .Delete: tableView.deleteRowsAtIndexPaths([indexPath!], withRowAnimation: UITableViewRowAnimation.Fade)            case .Update: tableView.reloadRowsAtIndexPaths([indexPath!], withRowAnimation: UITableViewRowAnimation.None)            case .Move: tableView.moveRowAtIndexPath(ip, toIndexPath: nip)        }    }

.. the invalid call will result in an Insert, and you will get an error like the following:

Invalid update: invalid number of rows in section 0. The number of rows contained in an existing section after the update (7) must be equal to the number of rows contained in that section before the update (7), plus or minus the number of rows inserted or deleted from that section (1 inserted, 0 deleted)

Simply swapping the cases so that the first case is a rather innocuous Update fixes the problem:

func controller(controller: NSFetchedResultsController, didChangeObject anObject: AnyObject, atIndexPath indexPath: NSIndexPath?, forChangeType type: NSFetchedResultsChangeType, newIndexPath: NSIndexPath?) {        switch type {            case .Update: tableView.reloadRowsAtIndexPaths([indexPath!], withRowAnimation: UITableViewRowAnimation.None)            case .Insert: tableView.insertRowsAtIndexPaths([newIndexPath!], withRowAnimation: UITableViewRowAnimation.Fade)            case .Delete: tableView.deleteRowsAtIndexPaths([indexPath!], withRowAnimation: UITableViewRowAnimation.Fade)            case .Move: tableView.moveRowAtIndexPath(ip, toIndexPath: nip)        }    }

Another option would be checking type.rawValue for an invalid value.

Note: while this addresses a slightly different error message than the one posted by the OP, the issue is related; it's somewhat likely that as soon as you fix the indexPath==newIndexPath problem, this one will pop up.Also, the above code blocks are simplified to illustrate the sequence; the appropriate guard blocks are missing, for instance - please don't use them as is.

Credits: this was originally discovered by iCN7, source: Apple Developer Forums — iOS 9 CoreData NSFetchedResultsController update causes blank rows in UICollectionView/UITableView