Cells disappearing during animation of UITableView

Question

I have a normal UITableView in my UIViewController, constrained to fullscreen. This tableView has a custom interactive tableHeaderView. The tableHeaderView is dynamic in size, and expands on its own. The headerView has a textField, and will change its own size depending on wether the textField has focus or not.

The problem is that the cells at the bottom of the screen aren't always animating correctly when changing the size of the tableHeaderView. I am calling tableView.beginUpdates() and tableView.endUpdates() after layoutIfNeeded() inside my animation-block. This has to be done, or the cells won't follow the dynamic size at all.

I've made this gif. Look specifically at the bottom cells during the animation. I have slowed down the animation considerably, so it's easy to see the problem.

Speculation: It seems to me like the tableView calls for cellForRow:indexPath: as soon as the animation starts, and somehow finds out what state the entire tableView will be in after the animation, and removing the unnecessary cells, even though the animation has not yet completed. The same way, when collapsing the header: the bottommost cells are not animated in the same way as the already loaded cells. They are animated in with a different animation..

Why is this happening? Is this preventable?

Edit: Animation code

self.navigationController?.setNavigationBarHidden(isEditing, animated: true)

var frame = tableHeaderView.frame
frame.size.height = tableHeaderView.headerHeight(forEditing: isEditing)

UIView.animate(withDuration: 0.3, animations: {

    if isEditing{
        let point = CGPoint(x: 0, y: -self.topLayoutGuide.length)
        self.tableView.setContentOffset(point, animated: false)
    }    

    tableHeaderView.frame = frame
    tableHeaderView.layoutIfNeeded()
    self.view.layoutIfNeeded()
    self.tableView.beginUpdates()
    self.tableView.endUpdates()
}) { [weak self](completed:Bool) in
    //Do stuff
}

Answer 1

I just heard back from the Apple Developer Technical Support team regarding this issue, and here's their response verbatim (emphasis mine):

Hello Nicolas,

Thank you for contacting Apple Developer Technical Support (DTS).

The behavior and resulting limitations you describe are by design.

If you believe an alternative approach should be considered by Apple, we encourage you to file an enhancement request with information on how this design decision impacts you, and what you’d like to see done differently.

Although there is no promise that the behavior will be changed, it is the best way to ensure your thoughts on the matter are seen by the team responsible for the decision.

Best Regards,

Apple Developer Technical Support

It seems we're just stuck with having to use a simple call to either tableView.setContentOffset(_:animated:) or tableView.scrollToRow(at:at:animated:).

Answer 2

Ok, I'll try to propose my version, though I can't check it, since I don't see your project. I didn't try to compile it, so it may have mistakes.

var navFrame = self.navigationController?.navigationBar.frame
navFrame.origin.y = isEditing ? -navFrame.size.height : 0

var frame = tableHeaderView.frame
frame.size.height = tableHeaderView.headerHeight(forEditing: isEditing)

UIView.animate(withDuration: 0.3, animations: {
    if isEditing{
        let point = CGPoint(x: 0, y: -self.topLayoutGuide.length)
        self.tableView.contentOffset = point
    }

    self.navigationController?.navigationBar.frame = navFrame

    tableHeaderView.frame = frame

    self.view.layoutIfNeeded()
}) { [weak self](completed:Bool) in
    //Do stuff
}