_PFBatchFaultingArray objectAtIndex:

You relly didn't give enough info for any guesses... but here you are:

1. Do you use CoreData? Someone thinks your CoreData contains data, but when asked there's none. Crash would happen, when someone asks fetchedResultsController.fetchedObjects for first object (index 0 as mentioned in crash report), but that doesn't exists (beyond bounds 0 in crash report)
2. "index beyond bounds" is a generic error note related to arrays. Error reports says that someone was asking for first item of array (index 0), but that array was empty (bounds 0). That's a crash.

Fix is to make sure there is data before you ask for it. One way is to check

if ([myArray count] > index)    value = [myArray objectAtIndex:index];

Anyways, my best guess is that PFBatchFaultingArray refers to CoreData and that means there are no easy answers.

Did you have e.g. authentication failure, which forced CoreData update, but FRCs are still pointing to old data? Crash would happen, when "old" frc thinks there still as much data as last time it looked, but the "new" data in CoreData is actually less in number. Then automatic UITableView update would be asking data for row, which doesn't exists any more == crash. Then you need to refresh your frcs BEFORE anyone tries to use the data. Only you will know, when or where that refresh can be done.

Ok, I think I figured out why. It's 'cause of the cache in NSFetchedResultsController. It's crappy. If you even so much as change the NSSortDescriptor from ascending to descending, you have to delete the cache manually.

So when the context changes and the cache doesn't realize this, it gets pissy and throws errors like the one you see. This can happen when you hit build in XCode: the context hasn't saved (and loses its data) but the cache thinks it should have so when it restarts with zero data, it gets surprised and doesn't know how to handle it.

Removing the cache gets rid of this problem. I think this may be why Apple stopped using it with UICollectionViewController. Just such a problem.

EDIT: checking for if the row/section doesn't exceed the respective count of NSFetchedResultsController doesn't work, because again, it THINKS the data should be there but it isn't.

If you are setting a "propertiesToFetch" on the NSFetchRequest, and if those properties are nil in the database, then you'll get this error as well.

The fix is to make that property optional, and don't prefetch it.

Example:

if 'Student<--->Backpack' is your model.

    let fetchRequest = ...    fetchRequest.propertiesToFetch = ["backpack"]    ...

The crash happens when backpack is nil.