I ran into this issue as well and did some research.
To reproduce it, it seems like you need a custom table view cell that uses auto layout to lay out its subviews. The indentation occurs when the table view is scrolled AND the scroll direction is changed AND the affected cell moves outside the visible screen AND subsequently back in view again WHILE the finger is not lifted off the screen during the change of direction.
The obvious first suspect was cell reuse. Overriding prepareForReuse in the custom cell implementation like this seems to solve the problem:
-(void)prepareForReuse{
[super prepareForReuse];
[self layoutSubviews];
}
The question is whether or not this is a bug. It does seem like something happens that invalidates the auto layout constraints when a cell is queued for reuse. Further research (breakpoints, NSLog etc) shows that all the layout constraints remain in place with correct values. From there comes the conclusion that layoutSubviews could probably solve the problem, which turned out to be the case.
Is it a bug? Maybe not. The docs for prepareForReuse say:
For performance reasons, you should only reset attributes of the cell that are not related to content, for example, alpha, editing, and selection state. The table view's delegate in tableView:cellForRowAtIndexPath: should always reset all content when reusing a cell.
So a strict interpretation of that would be that when auto layout is involved you probably have to re-leyout in tableView:cellForRowAtIndexPath: by calling layoutSubviews on the cell from there, since the auto layout constraints are part of the content. This also seems to indicate that prepareForReuse might not be the intended place to re-layout. Anyway, both ways seem to do the job, if someone knows more details as to which way is better, please feel free to comment.