There’s a fairly well-known problem with UITableView, that its support for interactive navigation transitions is slightly broken. The folks behind Castro have posted an excellent analysis and solution to this in the past.
We’re using their solution in The Hit List, but with a slight tweak. First, a quick reminder of their code:
When the user is swiping instead of having tapped a back button it behaves differently. The default behaviour is that instead of deselecting the cell immediately, UITableViewController waits to see if the transition completes before deselecting.
The key here is the check for if there’s a selected row. This setup relies on super (i.e. Apple) to deselect under normal circumstances, but then to leave the selection alone for our code to kick in during an interactive transition.
This works pretty well, but we’ve discovered an extra edge case that can need handling. If your table supports multiple selection, UITableViewController appears to also take this as a cue not to clear the selection. I think this makes sense; during multiple selection it seems reasonable that the user wants their selection to remain until something more explicit is done to change it.
The above code breaks under multiple selection. In our case we’re allowing multiple selection during editing mode for some tables. So here’s a modified version of the gist that takes that into account:
Followup: How to handle other transitions types, such as a modal dismissal