One of the best QA people I have ever worked with caught something that really impressed me.  She was working on reports of crashes while touching cells in a UITableView which was the result of a search.  When the user would touch one of the cells, the app would sometimes crash.  She noticed that the crashes only happened IF autocorrect was showing when the user touched the cell AND the auto-corrected search string would produce no results.  (I really wonder if I would have noticed such a detail.)

As it turned out, once the auto-correct is showing, any touch that is not the keyboard or the auto-correct’s popup (for dismissal) then the touch is considered an “accept” of the suggestion.

The part of this that caused the crash was the combination and simultaneous nature of the events. The auto-correct is accepted first. This causes a change in the search results which are the data source for the table. But the touch is also processed for the UITableView. It results in a didSelect call for the index path originally touched.  This can result in an attempt to access something that no longer exists.

The quick and easy solution is to disable auto-correct on the search bar.  That prevents the whole mess.

But, it also shows that if the data source is not prepared for the possible attempt to use bad numbers, it could result in a crash. And are we really sure that some other subtle combinations of things won’t also result in bad numbers?

A final thought:  If you correct your code to handle the invalid indexPath after the change of search, assume there is a result that winds up with the same indexPath.  It probably will not be the same result that was there before. Now the user will think there is a bug and file a bug report.