iOS8 - constraints ambiguously suggest a height of zero

Question

Has anyone got any idea how to debug this?

Warning once only: Detected a case where constraints ambiguously suggest a height of zero for a tableview c

Answer 1

I went round and round for days between this error and another error in which constraints were being created (no idea where) that conflicted with the constraints I wanted. I even had it working in one instance where every visible property was identical to the other. The only solution I found was to go atomic - create an entirely new file with xib and start again reconnecting outlets copy-pasting the old code. It might not be the best solution, but sometimes, if the problem is not visible, there is little else to do. At very least, going atomic is a good way to review what is going on.

Answer 2

Yes, You get all constrains "happy" even in case when you only have horizontal constrains for items in table view cell. I had same issue. You need to add also vertical constrains. Doing so, that warning will go away.

Answer 3

I used Row Height 43 (or <> 44) in the Table View size inspector and the error disappeared. Using 44 I get the error. Xcode version 6.0.1.

-- This answer was removed by a moderator, please don't, it fixes the problem. This SOLVES the problem for me and may do it for others too. So could you be so kind not to delete it again.

Answer 4

While the answers on this page discussing adding height constraints or manually returning rowHeights like 44 in heightForRowAtIndexPath cause the warning to go away, they are superfluous because this is a bug in Xcode visible in at least Version 6.3.2 (6D2105).

If you set a breakpoint in viewDidLoad, you'll see that self.tableView.rowHeight = -1 (UITableViewAutomaticDimension) even if you specify a row height of 44 in the storyboard. This is because Apple incorrectly assumes that you want dynamic row heights if you leave the row height at 44, because they didn't provide a flag for you to specify your preference.

Here are some possible solutions and their results:

• Set row height to 43 or 45 in storyboard (works).

• Manually return a height of 44 in heightForRowAtIndexPath (works).

• Add height constraints between the UITableViewCell’s elements and its contentView (works).

Unfortunately, these solutions either require you to change your design, add unnecessary constraints or add unnecessary code to work around a bug. I tried (what I thought to be) the simplest solution:

• Set each UITableViewCell’s height to 44 (Custom) in the storyboard (fails).

I really wanted a pure storyboard solution to this, so finally I tried:

• Add a user-defined runtime attribute to the UITableView in the storyboard, and name the UITableView with a note about how its rowHeight is being set so future developers can find it: (works):



These bugs are all too common in iOS development and force developers to spend excessive time weighing the ramifications of how their solutions will affect maintainability in the long run.

Since finding a conceptually correct solution that is maintainable and doesn’t seem obfuscated is so elusive, and assuming that Apple will fix the bug and that 44 is going to be the default row height for the foreseeable future, then the constraint or user-defined runtime attribute solutions are probably the most maintainable.

Answer 5

If you're using autoLayout constraints and UITableViewAutomaticDimension, this error is not some erroneous problem to be discarded by overriding your height in code. It means that determining the cell height automatically isn't working because you don't have the proper vertical constraints needed.

If you're like me and were getting this error and needed help identifying which cell was throwing the error, you can add the following line right before the return of your 'heightforRowAtIndexPath' method.

NSLog(@"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);

This will print out a long list of sections and rows, but the error will appear immediately following the particular cell that is causing the error, and you can quickly identify which cell is causing the problem and fix your constraints accordingly. This is particularly helpful for static cells. Overriding the height with a manually entered number will work if you're not using autoLayout and automatic cell heights, but will essentially disable these features which is a very poor solution if its something you're trying to utilize.

If you weren't previously using the 'heightForRowAtIndexPath' method but want to debug this error without undoing your UITableViewAutomaticDimension setting, simply add this to your code:

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    NSLog(@"Section %ld Row %ld", (long)[indexPath section], (long)[indexPath row]);
    return UITableViewAutomaticDimension;
}

Answer 6

There are two important things happening here, I think.

1) It's super easy to make the constraints wrong if you're ctrl+dragging. So, double check that you have it done correctly. Best to use the tray on the left side of the screen to draw these constraints.

2) Instead of specifying the estimatedRowHeight in ViewDidLoad or somewhere else, use the delegate method

override func tableView(tableView: UITableView, estimatedHeightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {}

This fixed the problem right away for me.