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

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

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.

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.

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

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.

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?

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

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.

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?

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. 😒

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

Installing TinyConstraints using SPM on an M1 Pro MacBook Pro, Xcode 13.4 - building for any iOS simulator will fail. It works fine on an Intel-based Mac.

Error:

Could not find module 'TinyConstraints' for target 'x86_64-apple-ios-simulator'; found: arm64-apple-ios-simulator, at: /Users/will/Library/Developer/Xcode/DerivedData/<APP>/Build/Products/Debug-iphonesimulator/TinyConstraints.swiftmodule

I used to use CocoaPods and having the following in my Podfile worked for TinyConstraints and other pods:

post_install do |installer|
  installer.pods_project.build_configurations.each do |config|
    config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = "arm64"
  end
end

I have tried modifying Universal-Target-Base.xcconfig to add

EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64

and/or removing the VALID_ARCHS settings, but to no avail.

With SPM the only fix I've found is to run Xcode in Rosetta, which really isn't ideal.

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.

I was unable to run in an x86_64 simulator until removing this build setting.

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)

Before

let constraint: Constraint? = view.leadingToSuperview()

...

if let c = constraint {
    Constraint.deactivate([c])
}

After

let constraint: Constraint? = view.leadingToSuperview()

...

constraint?.deactivate()

Hello!

I have a project with mulitple frameworks and many of the frameworks use TinyConstraints via Carthage. When trying to migrate to SPM, I bumped into an issue where it always embeds the library in every module, resulting in issues when trying to archive the app and sending to the App Store.

ERROR ITMS-90685: "CFBundleIdentifier Collision. There is more than one bundle with the CFBundleIdentifier value 'TinyConstraints' under the iOS application '<MyApp>.app'."
ERROR ITMS-90205: "Invalid Bundle. The bundle at '<MyApp>.app/Frameworks/<MyFramework>.framework' contains disallowed nested bundles."
ERROR ITMS-90206: "Invalid Bundle. The bundle at '<MyApp>.app/Frameworks/<MyFramework>.framework' contains disallowed file 'Frameworks'."

To solve that I added another product that forces the library to be dynamic. With a dynamic library I have the option to not embed the library in my modules, only in the app target, which solves my problem.

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)