12

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:

Screenshot describing the issue

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?

shim
  • 9,289
  • 12
  • 69
  • 108
VDub19
  • 131
  • 1
  • 1
  • 4
  • Does the problem go away if you disable your expand-contract logic? – Frank Schmitt Nov 01 '17 at 20:24
  • Have you added the header from a storyboard, if yes, please share the "headers of tableview in storyboard" screenshot
    Also are you calculating the row height? are calculations as expected?     – Raj Sep 15 '17 at 20:26
  • 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` – VDub19 Sep 16 '17 at 12:29

4 Answers4

51

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.

shim
  • 9,289
  • 12
  • 69
  • 108
ahmedre
  • 1,684
  • 1
  • 14
  • 18
  • 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. – VDub19 Sep 18 '17 at 13:58
  • Setting these back to zero fixed the issue for me, thanks! – amleszk Oct 01 '17 at 22:01
  • No need to set the row height (`self.tableView.estimatedRowHeight = 0;`), just setting the `estimatedSectionHeaderHeight` and `estimatedSectionFooterHeight` works for me. – Itachi Oct 23 '17 at 09:46
3

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
shim
  • 9,289
  • 12
  • 69
  • 108
A.Mysik
  • 31
  • 2
2

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
}
Arco
  • 614
  • 5
  • 13
1

Try to change table style from plain to grouped.

Anas Alhasani
  • 97
  • 9
  • 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. – VDub19 Sep 16 '17 at 12:55