To me, this kinda seems like it should be the default behavior but I'll freely admit I might be missing something :)
This tries to ensure that the scroll position doesn't change after calling -reloadData. If, for instance, the table view grows, this makes it behave like you'd probably expect it to (you won't be suddenly scrolled to the bottom).
keep the scroll position by maintaining and restoring the contentOffset
There's already a mechanism for this (unless I misunderstand). Check out:
(Note it requires participation from the caller because the mapping from items <-> index paths may change after a reload... think if an item gets inserted before another item). The table view doesn't have a semantic understanding of the stuff it's displaying.
Yeah, so that's some of the source of my confusion. -reloadDataMaintainingVisibleIndexPath:relativeOffset: is cool but:
I can totally see -reloadDataMaintainingVisibleIndexPath:relativeOffset: being useful, but I think this serves a different purpose.
OK, I buy it.