Is it possible to have differing heights in a UITableView Cell when I use several different ways of displaying the cell?

Question

I\'ve spent several days trying to figure this out, but there doesn\'t seem to be a solution. I have a very basic UITableView cell with two labels in it. One of them will be

Answer 1

As others have mentioned, make sure you're letting the table view cells dynamically resize with:

tableView.estimatedRowHeight = 
tableView.rowHeight = UITableViewAutomaticDimension

But you've mentioned that you're already doing this.

The rest of the problem is a case of missing constraints. You've already told autolayout that you want your multi-line label to match the top and bottom of the stack view, as in the code below:

englishWordLabel.topAnchor.constraintEqualToAnchor(stackView.topAnchor).active = true
englishWordLabel.bottomAnchor.constraintEqualToAnchor(stackView.bottomAnchor).active = true

But you haven't mentioned to autolayout how this stack view relates to the cell's content view (its superview). This is necessary for dynamically-sized cells because according to Apple:

To define the cell’s height, you need an unbroken chain of constraints and views (with defined heights) to fill the area between the content view’s top edge and its bottom edge. If your views have intrinsic content heights, the system uses those values. If not, you must add the appropriate height constraints, either to the views or to the content view itself.

Your labels have intrinsic content, so that's no problem, but in order to complete the "unbroken chain," you need to tell autolayout that the stack view's top and bottom should be equal to the content view's top and bottom, like so:

// stackView.superview! is the table view cell's content view
stackView.topAnchor.constraintEqualToAnchor(stackView.superview!.topAnchor).active = true
stackView.bottomAnchor.constraintEqualToAnchor(stackView.superview!.bottomAnchor).active = true

Add these two lines after you've added the stack view to the content view, and I believe you'll be in business.

FYI, even if you're programmatically adding these views to your cells like you are, you can still visually debug layout issues quite well with Xcode's awesome Capture View Hierarchy ability. While your app is running from Xcode, click the menu item Debug > View Debugging > Capture View Hierarchy. It's very easy to see what's going on in your view hierarchy, what constraints are active, where your disappearing views went, etc..

2nd FYI, destroying views and then reinstantiating new ones every time a cell appears on screen significantly degrades performance while scrolling. As much as you can, you'll want to take existing views from dequeued cells and reassign their contents with the proper content for that row (and thus avoid view instantiation). You can still do this using your purely-programmatic way of doing things by dequeueing a cell and calling cell.viewWithTag for each possible view. If the method returns nil, you do a one-time instantiation of the view for the cell and give the view a tag (let's say 1 for wordLabel and 2 for englishWordLabel). Then assign the proper content for the row to the view.