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 cell's content view. We're considering the collapse unintentional and using standard height instead.

The rows have a fixed height as set by

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath{
   return 34.0;
}

And all the constraints seem to be happy...

score 130 · Accepted Answer · edited Oct 09 '14 at 17:35

130

Forcing a return height and estimated height made the warning disappear in my case.

- (CGFloat)tableView:(UITableView *)tableView 
           estimatedHeightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

- (CGFloat)tableView:(UITableView *)tableView 
           heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44;
}

Another solution where you don't need the two overrides is simply to use self.tableView.rowHeight = 44; in your loadView or init method.

edited Oct 09 '14 at 17:35

Alex Cio

6,014
5
44
74

answered Sep 15 '14 at 20:44

FBronner

1,672
1
11
5

1

I have multiple type rows in section and only one of them have dynamic height. then it is not working – Raj Aggrawal Sep 16 '16 at 10:25
If we set the default height in xib/storyboard, we dont have to implement these methods. – Satyam Feb 17 '17 at 10:00

score 76 · Answer 2 · answered Sep 25 '14 at 16:09

76

What can also be done is adding vertical constraints from the top and to the bottom of the content view. This will make autolayout happy (because he now knows how to calculate the height of the cell himself).

answered Sep 25 '14 at 16:09

MonsieurDart

6,005
2
43
45

2

This worked for me. I went through all container cells and made sure at least one subview has both a "top space to container" and a "bottom space to container" constraint. – Rog182 Oct 10 '14 at 06:33
7

That's the right answer for iOS 8 when using self-sizing table view cells. – tsafrir Jan 04 '15 at 22:54
1

Do you mean constraints from elements inside of the content view to the top and bottom of the content view? – Zack Shapiro Feb 25 '15 at 20:26
I tried this but I keep getting conflicting constraint warning. – Shirish Kumar Apr 17 '15 at 21:14
2

Make sure you are adding the top and bottom constraint to the content view of the cell, not the cell itself. If you add constraint to the cell, the code will still work but will attempt to use height of 0. – frin Jan 25 '16 at 12:55

score 26 · Answer 3 · answered Apr 10 '15 at 15:19

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;
}

Thanks you so much. This helped me a lot. At first i thought, that problem was with another table view cell. After debugging it turned out, that problem was with another. — akozin, Sep 03 '16 at 19:15
I'd like to do this, but long, section and row are unidentified. Could you clarify what these should be in Swift? — DrWhat, Sep 05 '19 at 12:23

score 9 · Answer 4 · answered Oct 29 '14 at 21:05

9

There appears to be a bug in XCode 6.1 that causes this problem if using auto-layout and you don't specify a value for the Row Height for each Table View Cell, but instead you leave the "default" value. Simply checking the "Custom" checkbox next to the Row Height, for every cell, makes the warning go away.

answered Oct 29 '14 at 21:05

ltm

111
6

2

If you are using self-sizing cells you need to leave the row height set to "default". – phatmann Nov 17 '14 at 19:23
1

This solved the warning. But I believe it only appears when using Static Cells in TableView – MontiRabbit Nov 25 '14 at 14:43
1

@phatmann This issue only appears for static cells hence the cells should not be self-sizing. – ltm Dec 11 '14 at 14:49
@ltm could self-sizing cells not be useful, in static cells, if the user has enlarged text maybe? (You know, under accessibility in iPhone settings) – Byron Coetsee Dec 14 '14 at 16:02
I think it's not a bug, It might be a problem with the vertical constraints, they have to fully describe the height of the cell, for tableviews with automatic dimension at least. – juanjo Nov 24 '15 at 21:05

score 3 · Answer 5 · answered Oct 13 '14 at 18:27

3

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.

answered Oct 13 '14 at 18:27

Juraj Antas

3,059
27
37

score 3 · Answer 6 · edited May 23 '17 at 12:02

The constraints can be happy for the purpose of layout, but not happy for the purpose of automatic row height. A happy layout would mean the content can be laid out without ambiguity. That would satisfy the checks in Interface Builder.

A happy layout for automatic row height would mean that, in addition to the above, you're also including constraints to the bottom of the cell.

More here: Detected a case where constraints ambiguously suggest a height of zero

score 3 · Answer 7 · answered Oct 18 '14 at 17:23

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.

score 2 · Answer 8 · answered Sep 13 '14 at 16:46

2

I couldn't get to remove the warning, but to make constraints work I set the ,new to iOS8 , tableview property estimatedRowHeight to the fixed height, and removed heightForRowAtIndexPath implementation.

answered Sep 13 '14 at 16:46

amir

1,332
8
15

If it didn't remove the warning than it's the system that's making up for the missing constraint and setting the row height == to the cell.rowHeight property. The warning is about an auto heal property, if it auto healed that means the problem was there no? – Pedro Borges Oct 17 '14 at 23:15

wrightak · Answer 9 · 2014-10-10T06:36:25.650

If you're getting that warning, it's most likely because you're using auto layout and your cells don't have any constraints inside them.

You should either stop using auto layout or implement constraints that unambiguously define the height of the cells.

You can turn auto layout off in interface builder by unchecking the "Use Autolayout" option in the file inspector on the right.

If you choose to use auto layout and the height of your cells is fixed, implementing the appropriate constraints should be easy. Simply add height constraints for subviews of the cell's content view, and implement vertical space constraints between the subviews, and between the subviews and the content view. For example if your cell has one label in it, this would work:

Vertical constraints

Vertical space constraint between the top of the content view and the top of the label
Fixed height constraint of label
Vertical space constraint between the bottom of the label and the bottom of the content view

Horizontal constraints

Horizontal space constraint between the leading edge of the content view and the leading edge of the label
Fixed width constraint of label
Horizontal space constraint between the trailing edge of the label and the trailing edge of the content view

I am using constraints, and they all seem to be happy, as mentioned in the question. — Chris, Oct 10 '14 at 10:08
Are those constraints for the subviews of the cell's content view? What do they look like? Is it possible you have some cells which are different? If you're defining the cells to have a fixed height using Frederic Bonner's solutions, the constraints are being overridden. — wrightak, Oct 20 '14 at 06:46

score 1 · Answer 10 · answered Sep 24 '14 at 12:09

1

You can use AutoLayout to calculate the right height for you. Here is a nice post about Dynamic Cell Height on iOS 8: http://natashatherobot.com/ios-8-self-sizing-table-view-cells-with-dynamic-type/

answered Sep 24 '14 at 12:09

ricardopereira

11,118
5
63
81

I wish it was this simple. Adding these two lines didn't fix my autosizing problem unfortunately – Zack Shapiro Feb 25 '15 at 20:30

King-Wizard · Answer 11 · 2014-12-13T22:07:26.150

1

In Swift forcing a return height fixed my problem:

override func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {
    if(indexPath.row == 0){
       return CGFloat(131.0)
    }else if(indexPath.row == 8){
       return CGFloat(97.0)
    }else{
       return CGFloat(44.0)
    }
}

edited Dec 13 '14 at 22:07

answered Dec 13 '14 at 21:57

King-Wizard

15,628
6
82
76

score 1 · Answer 12 · answered Jan 31 '15 at 09:03

For a bog standard fix, no constraints, no estimating heights, or over engineering the problem. I created a default project, wired up the tableview but forgot to put the height delegate in the view controller. To simply make this warning go away you need this.

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
    return 44;
}

In your table's view controller.

score 1 · Answer 13 · answered Dec 13 '16 at 06:28

I was using a mapView inside uitableviewcell. I changed the height of map view to 1/3th of the device screen size. I got the same error. I fixed the error by adding missing constraints to the content view of the uitableviewcell.

1) Clear the contentView constraints.

2) Set Reset to Suggested constants to contentView.

3) Add missing constraints - if any

4) We make sure the content view has all the required constraints.

score 0 · Answer 14 · answered Nov 11 '14 at 17:03

0

In my case, it is because I'm designing the cell with xib, and I forget to add that xib file to the target.

After I add that xib file to the target, the problem is gone

answered Nov 11 '14 at 17:03

onmyway133

45,645
31
257
263

score 0 · Answer 15 · answered Jun 22 '15 at 18:25

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):

enter image description here

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.

score 0 · Answer 16 · answered Sep 23 '15 at 03:51

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.

Why are you using override? – FractalDoctor Dec 16 '15 at 09:15 — FractalDoctor, Dec 16 '15 at 09:15

score 0 · Answer 17 · answered Jan 05 '16 at 22:50

I've also seen this error when using universal storyboards or xibs. If you neglect to specify proper constraints for the Any x Any size class, I've seen this error appear.

Apple seems to have fixed this for iOS9. The error only happened on 8.4 for me.

score 0 · Answer 18 · answered Aug 08 '19 at 14:30

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.

iOS8 - constraints ambiguously suggest a height of zero

18 Answers18

Linked