iOS 11 Floating TableView Header

Question

Have an app going with multiple sections, a few rows per section when "expanded", none when "collapsed". Each section has a section header, was reusing them using a subclass of UITableViewHeaderFooterView etc. So far so good.

Then in iOS 11:

I've used the visual debugger, and confirmed it's my section header floating. All the rows beneath the header are displaying correctly, the other headers show fine.

In an effort to restore sanity, I threw out all of the reuse logic for the header and just made them programatically. Same same. All work pre-iOS 11, still float in iOS 11. The section which floats seems to change each time, so there's that.

Any ideas?

Nogging

Have you added the header from a storyboard, if yes, please share the "headers of tableview in storyboard" screenshot<br> Also are you calculating the row height? are calculations as expected? – Nikolai

Loaded them from an XIB originally, then created them programatically. Both cause the issue. As for height, I have an estimated height & it's calculated via constraints & UITableViewAutomaticDimension – Nogging

Does the problem go away if you disable your expand-contract logic? – Interurban

Answer 1

Just ran into a similar issue and found the discussion on this issue which worked for me:

self.tableView.estimatedRowHeight = 0
self.tableView.estimatedSectionHeaderHeight = 0
self.tableView.estimatedSectionFooterHeight = 0

Seems like the default behavior of UITableView changed in iOS 11 to use estimated heights. The release notes for iOS 11 beta 2 say:

Table views now use estimated heights by default, which also means that cells and section header/footer views now self-size by default. The default value of the estimatedRowHeight, estimatedSectionHeaderHeight, and estimatedSectionFooterHeight properties is now UITableViewAutomaticDimension, which means the table view selects an estimated height to use. You should still provide a more accurate estimate for each property if possible, which is your best guess of the average value of the actual heights. If you have existing table view code that behaves differently when you build your app with the iOS 11 SDK, and you don’t want to adopt self-sizing, you can restore the previous behavior by disabling estimated heights by setting a value of zero for each estimated height property. (30197915)

see also the beta 2 release notes mirrored here.

Hoxsie

Not sure this is related to row height, as the heights appear correctly (just the row itself is misplaced). Making the suggested change just zero's out a bunch of rows. – Nogging

Setting these back to zero fixed the issue for me, thanks! – Eudora

No need to set the row height (self.tableView.estimatedRowHeight = 0;), just setting the estimatedSectionHeaderHeight and estimatedSectionFooterHeight works for me. – Zolnay

Answer 2

If you want to make change like in ahmedre answer for entire app, You can set this properties in AppDelegate didFinishLaunchingWithOptions

UITableView.appearance().estimatedRowHeight = 0
UITableView.appearance().estimatedSectionHeaderHeight = 0
UITableView.appearance().estimatedSectionFooterHeight = 0

Hertzog

Answer 3

I don't know why in my case, @ahmedre answer is not working...

So my answer maybe help you if you set all estimated properties to 0 also not working:

func tableView(_ tableView: UITableView, estimatedHeightForHeaderInSection section: Int) -> CGFloat {
    return 0.1
}

func tableView(_ tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
    return 0.1
}

Ogee

Answer 4

Try to change table style from plain to grouped.

Sempiternal

Interesting. This seems to have corrected the visual bug, but leaves behind a few other problems (all related to a grouped tableView - footer heights, background colours & slightly altered animations). Any idea what is affecting plain tableviews? On the surface this seems like a needless change to avoid a larger issue. – Nogging