You should consider carefully whether you want to update the table view as each change is made. If a large number of modifications are made simultaneously—for example, if you are reading data from a background thread—it may be computationally expensive to animate all the changes. Rather than responding to changes individually (as illustrated in Typical Use), you could just implement controllerDidChangeContent(_:) (which is sent to the delegate when all pending changes have been processed) to reload the table view.
The fetched results controller reports changes to its section before changes to the fetched objects themselves.
In general, NSFetchedResultsController is designed to respond to changes at the model layer. If you allow a user to reorder table rows, then your implementation of the delegate methods must take this into account.
Typically, if you allow the user to reorder table rows, your model object has an attribute that specifies its index. When the user moves a row, you update this attribute accordingly. This, however, has the side effect of causing the controller to notice the change, and so inform its delegate of the update (using controller(_:didChange:at:for:newIndexPath:)). If you simply use the implementation of this method shown in Typical Use, then the delegate attempts to update the table view. The table view, however, is already in the appropriate state because of the user’s action.
In general, therefore, if you support user-driven updates, you should set a flag if a move is initiated by the user. In the implementation of your delegate methods, if the flag is set, you bypass main method implementations; for example: