title: Should the contentView.translatesAutoResizingMaskToConstraints of a UICollectionViewCell subclass be set to `false`?
body: <p>TL;DR</p>
  
  <p>When trying to size UICollectionViewCells via auto layout, you can easily get auto layout warnings with even a simple example. </p>
  
  <p>Should we be setting <code>contentView.translatesAutoResizingMaskToConstraints = false</code> to get rid of them?</p>
  
  <hr>
  
  <p>I'm trying to create a UICollectionView with <a href="https://stackoverflow.com/a/25896386/35690">self sizing auto layout cells</a>.</p>
  
  <p>In viewDidLoad:</p>
  
  <pre><code>let layout = UICollectionViewFlowLayout()
  layout.estimatedItemSize = CGSize(width: 10, height: 10)
  collectionView.collectionViewLayout = layout
  </code></pre>
  
  <p>My cell is very basic. It's a single blue view with width and height 75 for testing purposes. The constraints are created by pinning the view to the superview on all 4 edges, and giving it a height and width.</p>
  
  <pre><code>class MyCell: UICollectionViewCell {
    override init(frame: CGRect) {
      view = UIView()
  
      super.init(frame: frame)
  
      view.backgroundColor = UIColor.blueColor()
      contentView.addSubview(view)
  
      installConstraints()
    }
  
    required init?(coder aDecoder: NSCoder) {
      fatalError("init(coder:) has not been implemented")
    }
  
    var view: UIView
  
    func installConstraints() {
      view.translatesAutoresizingMaskIntoConstraints = false
  
      var c: NSLayoutConstraint
  
      // pin all edges
      c = NSLayoutConstraint(item: contentView, attribute: .Leading, relatedBy: .Equal, toItem: view, attribute: .Leading, multiplier: 1, constant: 0)
      c.active = true
      c = NSLayoutConstraint(item: contentView, attribute: .Trailing, relatedBy: .Equal, toItem: view, attribute: .Trailing, multiplier: 1, constant: 0)
      c.active = true
      c = NSLayoutConstraint(item: contentView, attribute: .Top, relatedBy: .Equal, toItem: view, attribute: .Top, multiplier: 1, constant: 0)
      c.active = true
      c = NSLayoutConstraint(item: contentView, attribute: .Bottom, relatedBy: .Equal, toItem: view, attribute: .Bottom, multiplier: 1, constant: 0)
      c.active = true
  
      // set width and height
      c = NSLayoutConstraint(item: view, attribute: .Width, relatedBy: .Equal, toItem: nil, attribute: .NotAnAttribute, multiplier: 1, constant: 75)
      c.active = true
      c = NSLayoutConstraint(item: view, attribute: .Height, relatedBy: .Equal, toItem: nil, attribute: .NotAnAttribute, multiplier: 1, constant: 75)
      c.active = true
    }
  }
  </code></pre>
  
  <p>When running the code, I get two errors about not being able to simultaneously satisfy constraints:</p>
  
  <pre><code>Unable to simultaneously satisfy constraints.
      Probably at least one of the constraints in the following list is one you don't want. 
      Try this: 
          (1) look at each constraint and try to figure out which you don't expect; 
          (2) find the code that added the unwanted constraint or constraints and fix it. 
      (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to the documentation for the UIView property translatesAutoresizingMaskIntoConstraints) 
  (
      "&lt;NSAutoresizingMaskLayoutConstraint:0x7fed88c1bac0 h=--&amp; v=--&amp; H:[UIView:0x7fed8a90c2f0(10)]&gt;",
      "&lt;NSLayoutConstraint:0x7fed8ab770b0 H:[UIView:0x7fed8a90bbe0(75)]&gt;",
      "&lt;NSLayoutConstraint:0x7fed8a90d610 UIView:0x7fed8a90c2f0.leading == UIView:0x7fed8a90bbe0.leading&gt;",
      "&lt;NSLayoutConstraint:0x7fed8ab005f0 H:[UIView:0x7fed8a90bbe0]-(0)-|   (Names: '|':UIView:0x7fed8a90c2f0 )&gt;"
  )
  
  Will attempt to recover by breaking constraint 
  &lt;NSLayoutConstraint:0x7fed8ab770b0 H:[UIView:0x7fed8a90bbe0(75)]&gt;
  
  Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch this in the debugger.
  The methods in the UIConstraintBasedLayoutDebugging category on UIView listed in &lt;UIKit/UIView.h&gt; may also be helpful.
  </code></pre>
  
  <p>(The second error about the vertical constraints is omitted but it's nearly identical.)</p>
  
  <p>These errors make sense. Essentially, the contentView (<code>0x7fed8a90c2f0</code>) has <code>translatesAutoresizingMask = true</code>, thus its bounds set to 10x10 (from the estimated size) creates that <code>NSAutoresizingMaskLayoutConstraint</code> constraint. There's no way the view can be both 10 pixels wide and 75 pixels wide, so it outputs an error.</p>
  
  <p>I tried several different things to resolve this problem, with only 2 of them seeming to work.</p>
  
  <h3>Solution 1: Set at least one of the constraints to 999 or less</h3>
  
  <p>In this case, if I change the constraint that pins the bottom of the blue view to the bottom of the contentView to 999 priority (and do the same with the trailing constraint), it resolves the problem. Similarly, I could have chosen Top+Leading, or Width+Height so long as I don't have 1000 priorities in every direction. At least one has to "give" for the initial layout.</p>
  
  <p>Although it may sound like this would cause the view to have an incorrect height/width, it actually appears to be the correct size.</p>
  
  <h3>Solution 2: Set <code>contentView.translatesAutoresizingMaskIntoConstraints = false</code></h3>
  
  <p>By setting this to <code>false</code>, it essentially gets rid of the <code>NSAutoresizingMaskLayoutConstraint</code> constraint, and we no longer have a conflict. On the other hand, since the contentView is not set up with auto layout to begin with, it's as though no matter how you change its frame, its superview (the cell) is never going to update its size because there is nothing "pushing" back against it.</p>
  
  <p>Nevertheless, this solution somehow magically works. I assume that at some point the cell looks at the contentView's frame and decides "hey you set me to this size, that probably means you want the cell to be this size as well" and takes care of resizing the cell for you.</p>
  
  <h3>Which solution should we use?</h3>
  
  <p>Are there better solutions to this problem? Which of the above should be used? Are there any downsides to the two solutions mentioned above, or are they essentially the same and it doesn't matter which one you use?</p>
  
  <hr>
  
  <p>Notes:</p>
  
  <ul>
  <li>The reason it is harder to see in examples such as <a href="https://github.com/danielgalasko/DGSelfSizingCollectionViewCells/tree/master" rel="noreferrer">DGSelfSizingCollectionViewCells</a> is because they are relying on intrinsicContentSize + contentCompressionResistancePriority. If you get rid of my width+height constraints, replace them with 1000 setContentCompressionResistancePriority calls (horizontal+vertical), and use something with an intrinsic size (e.g. a label with text), you will no longer see the auto layout errors. This implies that <code>width@1000</code> behaves <strong>differently</strong> than an intrinsicWidth + <code>contentCompressionResistance@1000</code>. Perhaps the time a view gets its intrinsic width is after it's okay to modify the the frame of the content view.</li>
  </ul>
  
  <p>Things that didn't work:</p>
  
  <ul>
  <li>I noticed that when I create cells via a storyboard, I usually never run in to this problem. When I examined the differences in the <code>view</code> of a cell created via a storyboard and one created programmatically, I noticed that the <code>autoresizingMask</code> was RM+BM (36) in the storyboard, but 0 when created via code. I tried manually setting the <code>autoresizingMask</code> of my blue view to 36, but that didn't work. The real reason that the storyboard solution works is that usually the constraints you create are already perfectly set in the storyboard (otherwise you would have storyboard errors that need to be fixing). As part of fixing these errors, you may change the bounds of the cell. Since it calls <code>init?(coder:)</code>, the bounds of the cell are already configured correctly. So even though the <code>contentView.autoresizingMask = true</code>, there are no conflicts since it's already defined at the correct size.</li>
  <li>In the linked guide, it links to <a href="https://stackoverflow.com/a/18746930/35690">this post</a> when talking about creating constraints. It mentions that constraints should be created in <code>updateConstraints</code>. However, it sounds like this was Apple's original recommendations and that they are <a href="http://oleb.net/blog/2015/08/how-to-use-updateconstraints/" rel="noreferrer">no longer recommending</a> this convention for most of your constraints. Nevertheless, since that article says to create them in <code>updateConstraints</code> I tried to no avail. I got the same results. This is because the frame wasn't updated by the time updateConstraints was called (it was still 10x10).</li>
  <li>I've noticed similar problems when you choose a estimated size that is too small. I've fixed it in the past by increasing the estimated size. In this case I tried 100x100, but it still caused the same errors. This makes sense... a view can't be both 100 wide and 75 wide at the same time. (Note that I consider setting it to 75x75 a non-solution. See below for more info.)</li>
  </ul>
  
  <p>Non-solutions:</p>
  
  <ul>
  <li>Setting the estimated size to 75x75. Although this will resolve the errors for this simple example, it won't resolve the problem for cells that truly are dynamically sized. I want a solution that'll work everywhere.</li>
  <li>Returning the exact dimensions of the cell in <code>collectionView(_:layout:sizeForItemAtIndexPath:)</code> (e.g. by creating a sizing cell). I want a solution that works with my cell directly without needing any bookkeeping or extra calculation.</li>
  </ul>