roberthein/tinyconstraints

Nothing but sugar.

TinyConstraints is the syntactic sugar that makes Auto Layout sweeter for human use.

Features

• Pure Swift 5 sweetness.
• Everything you can do with Auto Layout, but shorter.
• Constraints are active by default.
• 100% compatible with other Auto Layout code.
• Optionally store your constraints.
• Set constraint priorities upon creation.
• Constrain directly to the superview.
• Stack views together with one line of code.
• No need to set translatesAutoresizingMaskIntoConstraints because TinyConstraints does it for you.

Examples

Edges

Attaching a view to its superview with NSLayoutConstraint:

NSLayoutConstraint.activate([
    view.topAnchor.constraint(equalTo: superview.topAnchor, constant: 0),
    view.leadingAnchor.constraint(equalTo: superview.leadingAnchor, constant: 0),
    view.bottomAnchor.constraint(equalTo: superview.bottomAnchor, constant: 0),
    view.trailingAnchor.constraint(equalTo: superview.trailingAnchor, constant: 0)
])

with TinyConstraints:

view.edgesToSuperview()

or:

view.edgesToSuperview(insets: .top(10) + .left(10))

Center

Constraining the center of a view to its superview with NSLayoutConstraint:

NSLayoutConstraint.activate([
    view.centerXAnchor.constraint(equalTo: superview.centerXAnchor, constant: 0)
    view.centerYAnchor.constraint(equalTo: superview.centerYAnchor, constant: 0)
])

with TinyConstraints:

view.center(in: superview)

or:

view.center(in: superview, offset: CGPoint(x: 10, y: 10))

Basic Use

Typealiases

TinyConstraints gives you convenient and tiny typealiases for handling constraints.

• Constraint = NSLayoutConstraint
• Constraints = [NSLayoutConstraint]

Equal and Unequal Anchors

This constraints the top-anchor of the view to the top-anchor of the superview:

view.top(to: superview)

This constraints the top-anchor of firstView to the bottom-anchor of secondView:

firstView.topToBottom(of: secondView)

Constrain to Superview

Often you need to constrain a view to it's superview, with TinyConstraints you can do this super easy:

view.edgesToSuperview()

Or only one edge:

view.topToSuperview()

Or you can attach all edges except one, like this:

view.edgesToSuperview(excluding: .bottom)

Relation and Priority

For almost all constraints you can set the relation and priority properties. The default relation is .equal and the default priority is .required:

container.width(150, relation: .equalOrLess, priority: .high)

Storing Constraints

Here we create a set of inactive constraints and store these to our property:

let constraints = view.size(CGSize(width: 100, height: 100), isActive: false)

Activation and Deactivation

Besides the default NSLayoutConstraint activation, TinyConstraints also provides a way to activate a set of constraints:

constraints.activate()

You can also do this in an animation:

oldConstraints.deActivate()

constraints.activate()
UIViewPropertyAnimator(duration: 1, dampingRatio: 0.4) {
    self.layoutIfNeeded()
}.startAnimation()

Animating Constraint Constants

Here we add a height constraint to a view, store it and animate it later:

let height = view.height(100)

height.constant = 200
UIViewPropertyAnimator(duration: 1, dampingRatio: 0.4) {
    self.layoutIfNeeded()
}.startAnimation()

Stack

Stack provides a way of constraining views together in a superview:

let views = [logo, title, description]
superview.stack(views, axis: .vertical, spacing: 10)

Find these examples and more in the Example Project.

Installation

CocoaPods

TinyConstraints is available through CocoaPods. To install it, simply add the following line to your Podfile:

pod "TinyConstraints"

Carthage

TinyConstraints is available through Carthage. To install it, simply add the following line to your Cartfile:

github "roberthein/TinyConstraints"

Swift Package Manager

TinyConstraints is available through Swift Package Manager. To install it, in Xcode 11.0 or later select File > Swift Packages > Add Package Dependency... and add TinyConstraints repository URL:

https://github.com/roberthein/TinyConstraints.git

Tutorials

Here are some video tutorials made by Alex Nagy.

Suggestions or feedback?

Feel free to create a pull request, open an issue or find me on Twitter.

tinyconstraints's Issues

Not compatible with app extensions

Thanks for a great library!

I can't use TinyConstraints in my Today Widget. Can you please enable Allow app extension API only? I tried this and the target still compiled successfully.

Weird temp error in Xcode 9 b5

If you are getting this:

TinyConstraints/Classes/Constraints.swift:40:33: 
Raw type 'LayoutPriority' (aka 'UILayoutPriority') is not expressible by any literal

on

public enum ConstraintPriority: LayoutPriority

then make sure your TinyConstraints CocoaPods target is marked to use Swift 3.2 and not Swift 4 which is default (SWIFT_VERSION in build settings).

I want my hour back. 😒

Allow setting `isActive` default value.

TinyConstraints sets isActive default value for all functions to true. So as result all constraints are activated as soon as they created. But this's not efficient according apple documentation, see https://developer.apple.com/documentation/uikit/nslayoutconstraint/1526955-activate

Typically, using this method is more efficient than activating each constraint individually.

So I propose extending the library with something like

public enum TinyConstraintsConfiguration {
  public static var isActiveDefault: Bool = true
}

func anyTinyconstraintsFunction(..., isActive: Bool = TinyConstraintsConfiguration. isActiveDefault) -> Constraint

This should not be source breaking change.

Aspect Ratio Constraint for UIImageView?

how do you set an aspect ratio constraint with TinyConstraints?

Enhancement Request: Add ability to exclude edges when pinning to any constrainable

Right now, you can do this:

someView.edgesToSuperview(excluding: .bottom)

And you can do

someView.edges(to: anotherView.safeAreaLayoutGuide)

But you can't do what I'd like to be able to do, which is:

someView.edges(to: anotherView.safeAreaLayoutGuide, excluding: .bottom)

Would it be possible to add an optional excluding parameter for any Constrainable.edges(to: call?

top()/bottom()/left()/right() lacks multiplier on offset amount

CSS has the ability to allow proportional margin and padding:
https://webplatform.github.io/docs/guides/the_css_layout_model/#Proportional-margins-and-padding-in-the-W3C-box-model

I was wondering if it is possible to implement a similar concept with edges. For example, if I wanted my top margin of a subview to its superview to be 20% of the superview height (i.e. subview.top = superview.top + 0.2*superview.height), how would I accomplish that?

Currently, using the multiplierparameters in width()/height() and centerX()/centerY() works, but there has to be support for the alternate form.

Weird effect when Right to left

I was trying to support Right to left languages in my app after studying a localisation session from WWDC 18. I had troubles on Trailing Constraints with TinyConstraints. I thought it was an error caused by iOS 12, But it turns out I was wrong.

After switching back to UIKit's TrailingAnchor instead of TinyConstraints's related API. It's work out fine. I noticed that TinyConstraints helped my inverts some math of AutoLayout by default. But it looks like it doesn't work with Right to left languages.

Any thoughts on this issue? Thanks.

Subtle difference in priorities compared to manual creation

I've been trying to work out a layout issue I'm running into related to NSWindow and its top-level views. It turns out it is being caused by the ConstraintPriority default value of .high.

// works
self.view.heightAnchor.constraint(equalToConstant: 100).isActive = true

// works
view.height(100, priority: .required, isActive: true)

// doesn't work
view.height(100)

This is because a system-created constraint, by default, has the required priority. TinyConstraints creates all with the .high default, which is < required. This creates very subtly different behavior.

I recognize that changing this has some serious compatibility implications. What do you think?

Podspec is missing macOS target

It looks like macOS is supported with #39, but the podspec only has iOS/tvOS targets

Improving view.edgesToSuperview(excluding:)

A very common case is when a view is stretched horizontally in superview, but top and bottom are tied to sibling views. E.g.

        // stretching horizontally
        myView.leadingToSuperview()
        myView.trailingToSuperview()
        myView.topToBottom(of: sibling1)
        myView.bottomToTop(of: sibling2)
        
        // stretching vertically
        myView.topToSuperview()
        myView.bottomToSuperview()
        myView.leadingToTrailing(of: sibling1)
        myView.trailingToLeading(of: sibling2)

It would be very cool to have a method like stretchHorizontallyInSuperview() and stretchVerticallyInSuperview because this operation is very frequent.

But while these methods are desirable, one of the side ways we can implement it is by improving edgesToSuperview(excluding:) by making LayoutEdge conform to OptionSetType, so that we could do something like this

        // stretching horizontally
        myView.edgesToSuperview(excluding: [.top, .bottom])
        myView.topToBottom(of: sibling1)
        myView.bottomToTop(of: sibling2)
        
        // stretching vertically
        myView.edgesToSuperview(excluding: [.leading, .trailing])
        myView.leadingToTrailing(of: sibling1)
        myView.trailingToLeading(of: sibling2)

While this is a very tiny improvement, I feel like it would still be needed for this great library.

Arbitrary ConstraintPriority?

What is the purpose of ConstraintPriority, meaning why it exists?
It's used in all the methods but is limited to a handful of values which is really limiting. I often need to use values like 999 to resolve issues when container is temporary smaller than content (but will be fine at the end of the animation).

For example, this is impossible:

v.edges(to: pv, priority: ConstraintPriority(rawValue: UILayoutPriority(999))!)

Carthage Incompatibility (v3.0.0) to Project using Swift 3.2

Just a note: If you are using the module with v3.0.0 (Swift 4) in a project that is Swift 3.2, a lot of extensions are not found.
Upgrading the project to Swift4 or going back to 2.1.3 solves the problem.

Only checked it with carthage

Unexpected layouting problem once using with UICollectionViewCell

When I used NSLayoutAnchor to fit any view(named, myview) to contentView of UICollectionViewCell by using edges method like the following, myview is not resized but contentView is actually resized to fit to myview.

cell.contentView.addSubview(myview)
myview.edges(to: cell.contentView)

As I mention above, I expected that myview has same size of contentView. On the contrary, a size of contentView is affected by a size of myview.

On the other hand, using NSLayoutConstraint with Visual Format works well.

Is there anything what I don't know about NSLayoutAnchor?

Why is trailingToSuperview offset inverted?

Why is offset value being manually inverted in trailingToSuperView and leadingToSuperview functions basing on effectiveUserInterfaceLayoutDirection? I believe trailing/leading constraints are made precisely so that developers don't have to handle layout direction manually.

Center Multiplier

I cant find any method to add center multiplier , is this possible?

Support Swift 4

Hello~
Is there a plan to support Swift 4?

Carthage support

Could you add carthage support, please?

Stack function changes translatesAutoresizingMaskIntoConstraints of superview

Hi there, small problem I've found with this library:
When using the stack(_:axis:width:height:spacing:) function, it will set translatesAutoresizingMaskIntoConstraints = false on the superview.
Unless I'm missing something, this is unnecessary and unexpected, and not in line with how the rest of the library works.

Small example how this could go wrong:

let cell = UICollectionViewCell()
let image = UIImageView()
let label = UILabel()
cell.contentView.stack([image, label])

Here, the contentView is managed by UIKit, but will be changed by the stack function. This did in fact break the layout of my UICollectionView.

It's a small issue and the fix is removing one line of code. I get this would be a breaking change and I don't know if it's worth it, but I wanted to share anyway.

Documentation needs more examples.

The documentation is not covering all scenarios. It would be great if you can add more details with example codes

Merge Swift 4.2 in master

Hello!

Is it possible to merge the Swift 4.2 branch in master?

Thank you and kudos for the awesome project!

Distribution in stack

Is it possible to manage distribution using view.stack(...)?

M1 MacBook Air - Not able to locate the module

Any one having issues with TiknyConstraints on ARM chip M1 macbook air?

App runs fine on an intel chip machine but on the M1 machine, I keep getting the error No such module TinyConstraints
(pod install successfully)

Doesn't compile in Swift 4.2

I might find some time to implement the needed changes for this, but not sure yet.

Enable Travis

We could do at least a carthage build of all plattforms to ensure buildability of PRs

Feature request: stack views of different size

In my case I have 3 views placed in vertical order. The problem is it is enough hard to setup them because the are all different but must fill the whole space given to them with predefined height proportion.

`translatesAutoresizingMaskIntoConstraints = false` should be part of library

translatesAutoresizingMaskIntoConstraints = false should be part of library.
Currently we need to set this manually. Which sometimes most of the developers forget to do. Whenever a user wants to add constraint this should be set to false automatically.

Video Documentation: New YouTube Playlist

Hi, I have created a new video tutorial series for version 4.0.0
https://www.youtube.com/watch?v=ucbaEkEJKrc&list=PL_csAAO9PQ8ZHY2VzOi7LJ80CtfAgCgHP
It goes through ALL the features of TinyConstraints :)
Would appreciate it if you added it to the README.
Feel free to use this image

Naming suggestion

Hi thanks for a cool lib!
I just suggest that why don't we call the function like this: view.tiny.center(in: superview) or view.tiny.edgesToSuperView() instead of view.center(in: superview) or view.edgesToSuperView()? So that we dont need to remember the function name.
Thank you

TinyConstraints cannot run in x86_64 simulator on Xcode 12/13 due to VALID_ARCHS built setting

e.g. Source.swift:9:8: Could not find module 'TinyConstraints' for target 'arm64-apple-ios-simulator'; found: i386, x86_64-apple-ios-simulator, x86_64, i386-apple-ios-simulator, at: ~Library/Developer/Xcode/DerivedData/APP_BUILD_DIR/Build/Products/Debug-iphonesimulator/TinyConstraints.framework/Modules/TinyConstraints.swiftmodule

The solution is to remove VALID_ARCHS, which has been deprecated.

https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes

The Build Settings editor no longer includes the Valid Architectures build setting (VALID_ARCHS), and its use is discouraged. Instead, there is a new Excluded Architectures build setting (EXCLUDED_ARCHS). If a project includes VALID_ARCHS, the setting is displayed in the User-Defined section of the Build Settings editor. (15145028)

Patch in #101

You may also want to remove your custom ENABLE_BITCODE setting, in case it breaks something down the road.

Adding support to ignore the Ascender/Descender in views that display text

Not really sure how you would like to implement this in the main project, but I wrote an extension that allows you to easily align the top and bottom edges of UILabel and UITextView so that they line up visually with the top/bottom of the text instead of being off a little due to ascender/descender.

https://pastebin.com/hYum9uLf

Why is rightToSuperview offset the only value being inversed?

public func rightToSuperview( _ anchor: NSLayoutXAxisAnchor? = nil, offset: CGFloat = 0, relation: ConstraintRelation = .equal, priority: LayoutPriority = .required, isActive: Bool = true, usingSafeArea: Bool = false) -> Constraint {
    let constrainable = safeConstrainable(for: superview, usingSafeArea: usingSafeArea)
    return right(to: constrainable, anchor, offset: -offset, relation: relation, priority: priority, isActive: isActive)
}

When looking at all other methods, rightToSuperview is the only one that inverses the offset value with -offset

Nested Stack View

Hi, just wondering is there a way to use the stack() method for building nested stack views (i.e. stack of stack views)? Currently we can only put [UIView] as the parameter for the function so it won't work for [[UIView]] or more layers of nesting. Thanks!

constraint changes fail to animate -- SOLVED

I've struggled for several hours now trying to figure out why my constraint changes weren't animating.

There is no issue with TinyConstraints (which is great, thanks Robert) just user error. But I thought it was worth a footnote in the README or an archived issue to hopefully save someone else the same hair pulling.

If you are following the suggested method of animating a set of constraints, and they immediately take effect without any lovely animation, make sure you are calling setNeedsLayout() on the superview containing the views you want to animate

    constraints1 = subview.edges(to: superview)
     constraints2 = subview.edges(to: superview, insets: UIEdgeInsets(top: 10, left: 10, bottom: 0, right: 0))
    ...
     constraints1.deActivate()
     constraints2.activate()
     UIViewPropertyAnimator(duration: 1, dampingRatio: 0.4) {
          //self.subview.layoutIfNeeded()   // WRONG-- won't animate
          self.view.layoutIfNeeded()        // RIGHT-- will animate
        }.startAnimation()

Naming - Expectation Clashes

This looks like a very useful project!

However, the naming of some of the methods -- particularly those normally relating to dimensions -- will cause some confusion

For this reason, I suggest renaming to something like:

view.heightConstraint
view.widthConstraint 
view.sizeConstraint
view.centerConstraint
etc.

or

view.constrainWidth
view.constraintHeight
view.constrainSize
view.constrainCenter
etc.

The slight increase in verbosity would do a lot to help understanding and recall, without going all over-verbose overkill like the current Auto Layout API.

Cheers. And thank you for your contribution.

View declaration conflicts with SwiftUI's View

For now I am forced to replace all View occurrences with SwiftUI.View.

Invalid edgesToSuperview right inset

Hi,

When doing something like:

        let edge = UIEdgeInsets(top: 20, left: 20, bottom: 20, right: 20)
        content.edgesToSuperview(insets: edge)

the right inset ends up +20 on the right. Looks like the sign is changed twice for the right inset.
here:

                if !(excludedEdge.contains(.trailing) || excludedEdge.contains(.right)) {
                    constraints.append(rightToSuperview(offset: -insets.right))
                }

and inside the rightToSuperview function:

        return right(to: constrainable, anchor, offset: -offset, relation: relation, priority: priority, isActive: isActive)

This is opposite to the behaviour with the bottom inset which is changed only once.

Thanks,
H.

UIEdgeInsets sugar suggestion

Hi, I really like the look of this framework. I've been using PureLayout for a while, but it doesn't handle arbitrary layout guides and isn't very Swifty.

Anyway, I've found myself often having to write shorthand static initializers to replace the wordyUIEdgeInsets.init. Would you be open to a PR introducing something like this as part of the framework? This would enable beautifully concise expressions like:

view.edges(to: superview, insets: .uniform(15))

view.edges(to: superview, insets: .top(10) + .bottom(15) + .horizontal(15))

Possibility of Joining Forces

Hey all,

I have been working on a similar constraints library currently called Constraid your friendly constraints aid. We have the same ideals/goals as this project but are a little further along.

We are definitely early on so are willing shift and adjust the naming of the methods in the API as we come up with better terminology for representing these concepts. Anyways, we have evolved this library after using it in a number of apps.

Was wondering if you would be interested in possibly joining forces to reduce the noise in the constraints library space, and to focus efforts and energy to try and build an extremely valuable constraints framework?

https://github.com/uptech/Constraid

Naming suggestion...

I like TinyConstraints but the naming makes it a little awkward to discover the methods by stumbling through syntax completion... For an extension like this maybe consider having all of these methods start with a verb prefix like "constrain" or "anchor"? Just a suggestion. Thanks.

deactivating constraint

Implementations of `trailingToSuperview` and `leadingToSuperview` only work correct only for Left-to-Right languages / layout.

What layout do I expect?

I want my signupButton to have it's trailing edge 20 points before safeAreaLayoutGuide.centerXAnchor. Similarly, I want my loginButton to have its leading edge 20 points after safeAreaLayoutGuide.centerXAnchor. Below image displays the layout in desired state:

Left-to-Right Layout 👆🏾

Right-to-Left Layout 👆🏾

What does my code looks like?

let signupButton = UIButton(type: .system)
signupButton.setTitle("Signup", for: .normal)
view.addSubview(signupButton)
signupButton.bottomToSuperview(offset: -50)
signupButton.trailingToSuperview(view.safeAreaLayoutGuide.centerXAnchor, offset: 20)

let loginButton = UIButton(type: .system)
loginButton.setTitle("Login", for: .normal)
view.addSubview(loginButton)
loginButton.bottomToSuperview(offset: -50)
loginButton.leadingToSuperview(view.safeAreaLayoutGuide.centerXAnchor, offset: 20)

What output do I get with above code?

Below are the screenshots of my output:

Left-to-Right Layout 👆🏾

Right-to-Left Layout 👆🏾

The problem

It looks like the way superview methods are implemented, they work correct only for Left-to-Right language / layout direction.

Will TinyConstraints have livereload?

Will TinyConstraints have live reload like Stevia?

https://github.com/freshOS/Stevia

TinyConstraints cannot run on simulator

I am unable to run my app in the simulator, even though it works fine for a device with ARM architecture.

Xcode gives this error for simulators:

Could not find module 'TinyConstraints' for architecture 'x86_64'; found: arm64, arm, armv7

Improve code completion for constraints that need offsets and insets

TinyConstraints is using a lot of methods with default parameters, unfortunately Xcode's code completion follows an all or nothing approach; it either shows the method with all the default parameters, or the method without any defaults, not the in between ones.

Current behavior
Because of this, creating a constraint that needs an offset is a bit tedious:

Desired behavior
It would be nice and faster if there would be code completions available that include the offsets and insets:

How to approach this
To make sure, the right code completions become available, you'd have to add some convenience methods for the completions you'd like to support. I've been doing this extensively for the public api of Zoomy.

Not an issue but a question

Hello!

I could not find another way of contacting you so I had to create an issue... I just have a quick newbie question:

How do I, for example, set top and bottom alignment of a button to another button? It seems to be quite easy in IB, but whenever I say, for example button.top (to: anotherButton), Xcode crashes with finding nil while unwrapping an optional value.

I add those constraints to UIButton after I added it into my subview. I know I am missing something out but I cannot quite get what. Here is an example of my code:

    cancelButton = UIButton(frame: CGRect(x: 10.0, y: 10.0, width: 50.0, height: 50.0))
    cancelButton.layer.shadowOpacity = 0.7
    cancelButton.layer.shadowOffset = CGSize(width: 0.0, height: 0.0)
    cancelButton.layer.shadowRadius = 5.0
    cancelButton.showsTouchWhenHighlighted = true
    cancelButton.setImage(#imageLiteral(resourceName: "Close"), for: UIControlState())
    cancelButton.addTarget(self, action: #selector(cancel), for: .touchUpInside)
    view.addSubview(cancelButton)

    cancelButton.height(50)
    cancelButton.width(50)
    cancelButton.leading(to: saveButton)
    
    saveButton = UIButton (frame: CGRect(x: 10.0, y: 506.0, width: 50, height: 50))
    saveButton.layer.shadowOpacity = 0.7
    saveButton.layer.shadowOffset = CGSize(width: 0.0, height: 0.0)
    saveButton.layer.shadowRadius = 5.0
    saveButton.showsTouchWhenHighlighted = true
    saveButton.setImage(#imageLiteral(resourceName: "Save"), for: UIControlState())
    saveButton.addTarget(self, action: #selector(save), for: .touchUpInside)
    view.addSubview(saveButton)
    
    saveButton.height(50)
    saveButton.width(50)
    saveButton.edges(to: cancelButton)`

Please add support for margins

Please add support for edgesToSuperview(margins:true) that will attach to layoutMarginsGuide

Add widthToHeight(of:) and heightToWidth(of:)

Add widthToHeight(of:) and heightToWidth(of:)

YouTube video tutorials

Hi,

I am using TimyConstraints in several of my and my clients apps. I just absolutely love it.

So I decided to create two YouTube videos tutorials that take a hands on approach in explaining how to use TinyConstraints.

You can take a look at it here: https://www.youtube.com/playlist?list=PL_csAAO9PQ8ZDbGk57RlBRnNpxBGBAEOc

If you like it consider adding it to the README. And because an image can say a thousand words you could use this screenshot:

Thank you for your hard and continued work on TinyConstraints!

`widthToSuperview` and `heightToSuperview` are ignoring relation parameter

relation parameter in both widthToSuperview and heightToSuperview methods is not used. For example, widthToSuperview method calls width(to: constrainable, dimension, multiplier: multiplier, offset: offset, priority: priority, isActive: isActive) without relation specified (which would be equal by default)

edges(to:) works incorrectly

This UITableViewCellSubclass doesn't work properly, for some reason it just stretches the avatarContainer to cell's edges.

class BuggedCell: UITableViewCell {
    override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
        super.init(style: style, reuseIdentifier: reuseIdentifier)
        let guide = contentView.layoutMarginsGuide        
        let avatarContainer = UIView()
        contentView.addSubview(avatarContainer)
        avatarContainer.edges(to: guide, excluding: .trailing)
        avatarContainer.backgroundColor = .red
        avatarContainer.size(CGSize(width: 100, height: 100), priority: UILayoutPriority(999))
    }
    
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

But this subclass does everything correctly

class BugFreeCell: UITableViewCell {
    override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
        super.init(style: style, reuseIdentifier: reuseIdentifier)
        let guide = contentView.layoutMarginsGuide        
        let avatarContainer = UIView()
        contentView.addSubview(avatarContainer)
        avatarContainer.leading(to: guide)
        avatarContainer.top(to: guide)
        avatarContainer.bottom(to: guide)
        avatarContainer.backgroundColor = .red
        avatarContainer.size(CGSize(width: 100, height: 100), priority: UILayoutPriority(999))
    }
    
    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

The subclasses should display identical results, but they don't 😫.