Animation issue when deleting the last row of UITableView - ios7

Question

UPDATE: This is now fixed in iOS 8.0 and above. See my accepted answer for details.
I have an iOS 7 UITableView that I allow swipe-to-delete on rows. I'm handling deletions in:
tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
With:
[tableView deleteRowsAtIndexPaths:#[indexPath] withRowAnimation:UITableViewRowAnimationTop];
All rows are deleted with the correct animation, except for the last one in the table. When the user swipes to show the delete button, then taps it, the cell slides completely off screen to the left but leaves a white cell behind with the delete button still on it for a few tenths of a second before disappearing abruptly. It appears that this is happening with all the cells, but all other cells have a row below them that slides up, covering it up.
This even happens when the row in question is the only row in the table, where I delete the entire section instead of just the row. The section header slides up into oblivion but the white cell with the delete button sticks around for a little bit.
I would like this last cell to have the same UITableViewRowAnimationTop animation that the others do. Any ideas of what's going on?

Answer 1

UPDATE: This bug has been corrected in iOS 8. That final cell deletion now slides off to the left, the delete button slides up and away, and the background is clear (no more white area that abruptly disappears after the animations complete). The iOS 7 fix below is still needed when running below iOS 8.
iOS 7 Fix:
I was able to correct this problem by adding another section to the end of the table with a sufficiently tall section header view. This header view is styled to look like the blank area at the bottom of the table, so you can't see that it's there. When the last row of the table is deleted, this blank section header slides up and over it, hiding the delete button that's stuck there. This is a bit of a hack, but it looks like it's a table view bug.

Answer 2

As an alternative to the keep-an-empty-row trick mentioned by Frank Li, I've gotten around this ugly glitch by simply special-casing the deletion of the last row: Instead of animating the cell away, simply call -reloadData on the table view.
You won't get any animation, but you also won't see the glitch so your table view won't look broken. A worthwhile tradeoff.

Answer 3

my solution was to simply disable the broken animation by hiding the cell that's being deleted.
- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
UITableViewCell* cell = [tableView cellForRowAtIndexPath:indexPath];
cell.hidden = YES;
}

Answer 4

I think a way-around is to always maintain an empty row below the last row in the table view. That will do the trick.

Answer 5

You can also use the UITableView.tableFooterView property:
- (void)viewDidLoad
{
[super viewDidLoad];
...
CGRect frame = [self.tableView rectForRowAtIndexPath:[NSIndexPath indexPathForRow:0 inSection:0]];
UIView *view = [[UIView alloc] initWithFrame:frame];
view.backgroundColor = self.tableView.backgroundColor;
self.tableView.tableFooterView = view;
}
This code goes into the view controller holding the UITableView.
Code assumes ARC.
It's a different story if you use background image for the table.
The code can be surrounded by "if (iOS > 7)" clause.