It would be good for Paralayout to be consumable as a Swift package:

https://swift.org/package-manager/

• roundToPixel -> roundedToPixel
• floorToPixel -> flooredToPixel
• expandToPixel -> expandedToPixel
• etc.

cc @efirestone

Working with angles is a fairly common scenario when building UI, especially around things like animations and gesture-based interactions. We should add some utilities that make working with angles easier.

i get some errors like

/Volumes/Swap/dev/_examples/Paralayout/Paralayout/Label.swift:448:34: Cannot subscript a value of type '[NSAttributedStringKey : Any]' with an index of type 'String'

Hairline and its associated utilities (e.g. hairlineWidth) don't really belong in Paralayout. The hairline concept is specific to a certain style of UI and therefore doesn't classify as a generic layout utility, which is what Paralayout is meant to be.

I propose that we remove it from Paralayout entirely, without replacement.

Building with Xcode 12 currently fails because the switches in UIDevice.isPhone and UIDevice.isPad are not exhaustive, since the introduction of UIUserInterfaceIdiom.mac in iOS 14.

Paralayout currently supports custom positioning via conformance to the AlignmentPositionAdjusting protocol. This can lead to some less-than-obvious behavior for consumers, which goes against the core principles behind Paralayout. As far as I know, this feature has very little usage outside of Label, which we have already proposed removing (#19), while adding complexity to our alignment logic. I propose that we remove the concept of custom positioning from the framework entirely.

If my assumption is wrong and you are using custom positioning, please speak up. I am happy to discuss leaving it in there, either in its current form or with some changes, if it's still providing significant value.

Paralayout's alignment methods use a UIView extension property named untransformedFrame that sets the size and origin of views using CALayer's bounds and position properties. UIView.safeAreaInsets do not get recalculated appropriately when doing this. This feels like a bug in CoreAnimation, but it causes unfortunate layout issues when using this framework.

I'm trying to work through this in https://github.com/squareup/cash-ios/pull/29720 . I'm not sure what the right approach is here. In cases where we could set frame safely because layer.transform.isIdentity == true, doing so corrects the problem. But it still exists in the scenario where the layer is transformed.

The view distribution code still sets the frame.origin.{x,y} for orthogonal alignment.

This should be updated to use the untransformed frame as we've done elsewhere throughout the framework.

We introduced a TargetAlignmentBehavior enum in #72 to control how views are aligned, in order to address the issues raised around aligning to scroll views in #54. The case names right now are a bit confusing, and I think we can do better, but I'm not sure what would be the clearest naming.

Now that we've removed the concept of custom positioning (#20) in 1.0, it's become more difficult to distribute labels via their font bounds. We should introduce a verticalDistributionItemUsingFontBounds convenience for this that includes the appropriate top/bottom insets from the font bounds.

Specifically, we should convert the following operator overloads into methods to improve clarity around what their function is and what type they will return:

• -(CGPoint, CGPoint) should be converted to CGPoint.offset(to:)
• +(CGPoint, UIOffset) should be converted to CGPoint.offset(by:)
• +(CGRect, UIOffset) should be converted to CGRect.offset(by:)

I can create instances of the Label class programmatically, and they will work fine. However, when I try to use a Label in Storyboard by changing a UILabel's class to Label, it gives me the "fatal error: init(coder:) has not been implemented" error. Can they only be used programmatically?

We currently use a mix of "with" and "to" when talking about alignment.

The base method and most parameterized usages use "with:"

• align(.center, with: view, .center)
• align(.center, withSuperviewPosition: .center)

But the superview methods use "to:"

• alignToSuperview(.center, offset: .zero)
• alignToSuperview(.center, inset: 42)

I feel strongly that we should converge on a single preposition to use in all of these cases, but I could be convinced to go with either one. I'm leaning towards "with," but curious is anyone else feels strongly.

Currently using methods like applyVerticalSubviewDistribution specifying an orthogonalAlignment requires callers to specify an inset. This could be simplified if the cases of types like HorizontalDistributionAlignment defaulted to zero.

Paralayout defines methods around view sizing that build on UIKit's sizeThatFits(_:) and sizeToFit() methods by adding constraints. These are currently named frameSize and resize to differentiate them from the UIKit methods and increase clarity between the two. While this is successful, it's also confusing how they interact with the UIKit versions given that they serve the same functionality. We should rename them to match the UIKit methods to make it clear that they serve the same function with the addition of constraints.

• frameSize(thatFits:constraints:) -> sizeThatFits(_:constraints:)
• resize(toFit:constraints:) -> sizeToFit(_:constraints:)
• resize(toFitWidth:height:constraints:) -> sizeToFit(width:height:constraints:)

We currently have a Position.point(in:) method to get the point at that position in the rect. This works well when you have the position already (e.g. as a parameter), but is a bit cumbersome when you don't, since it requires the full type.

let _ = Position.center.point(in: rect)

We should add a CGRect.point(at:) convenience method that calls through to this same logic, matching the existing UIView.point(at:) method.

rect.point(at: .center)

The extensions on UIDevice (found in UIDeviceAdditions.swift) are not up-to-date with the current set of available devices, do not include any iPad sizes, and only work for portrait orientations (as tracked by #3).

As Apple introduces increasingly variable screen sizes, for example with iPad multitasking and Catalyst apps, this extensions become less useful. I propose that we remove them from the framework completely.

The UIView sizing additions (frameSize(thatFits:constraints:) and associated methods) do not currently respect the constraints specified in the method call.

To illustrate:

// Given a view that returns a size of (300, 200) for its size that fits.
view.frameSize(thatFitsWidth: 100, height: 100, constraints: .maxSize) // returns (300, 200)

Since the width and height are both smaller than the view's size that fits, that method should return (100, 100) instead.

The core of this bug is inside SizingConstraints.apply(_:). It sets the constrainedSize to the size, then takes the appropriate min/max of these two. It should instead be comparing the size provided in the outer method call with the view's sizeThatFits(_:) size.

@frozendevil recently pointed out an issue with the way alignment works when using scroll views. Specifically, imagine you have a content view inside a scroll view, with a layout like this:

scrollView.alignToSuperview(.topCenter)
contentView.align(.topCenter, with: scrollView, .topCenter)

This will only work correctly when the scroll view has a content offset of zero.

I think we can fix this as part of the move to aligning via bounds and center (#49). Specifically, the alignment methods should treat the receiver view and the other view (the parameter) differently. The view being aligned (the receiver) should be aligned by the rect made from its bounds.size, center, and layer.anchorPoint to the rect of the target view (the parameter) by the rect made from its bounds.size, bounds.origin, center, and layer.anchorPoint.

Currently most of the layout utilities assume an LTR layout direction. We should extend the APIs to better handle RTL layout. Specifically, I think we need the following changes:

• Add cases to the Position enum with leading/trailing variants for each left/right case
• Support these new positions in the alignment methods
• Support these new positions in AspectRatio utilities for finding a rect to fit/fill
• Change the distribution options for orthogonal alignment to actually select the leading/trailing edge rather than always using left/right (and potentially add options for explicitly specifying left/right alignment)

Label doesn't really belong in Paralayout anymore. It was originally very helpful in working around some quirks in UILabel that made it difficult to align text properly to match the output of design tools. Many of those original issues have been resolved over the years, however, and so it is no longer providing much value in terms of layout. While it still provides additional functionality on top of UILabel, Paralayout is a layout framework and the functionality included should be scoped to only layout tools when possible.

If the Label functionality is still useful to external consumers, we can consider moving it to its own micro-framework. If you use it and would be interested in this, please speak up. For now I propose that we remove it from the Paralayout entirely.

Currently we perform layout by setting views' frames. Using frame for layout has some significant disadvantages. You can read about some of the complexity behind frames here. The most notable comes from this warning on the documentation for UIView.frame:

Instead of using frame to perform layout, we should instead set our views' bounds and center. This should have almost the same behavior as setting the frame, except in cases where the view has a non-identity transform (in which case the frame is undefined anyway). This also matches how Auto Layout behaves around transforms.

When calling spreadOutSubviews(...) with a non-zero margin, instead of applying the margin in between subviews as expected, all but the last subview are condensed by the correct amount, but are positioned with no margin between them; then the final subview is expanded to fill the remaining space (its expected size plus the combined missing margins).

Love the library, but it would be even more awesome and discoverable if the description and and topics were filled out!

The current name is kind of confusing, and this is a weird place for it. Some ideas:

ViewDistributionItem.compacting(:)
ViewDistributionItem.compactingHidden(:)
Array.compacted()

When calling spreadOutSubviews(...), the value for sizeToBounds is ignored and always resizes subviews along their orthogonal axis to match their superview.

We currently have support for interpolating CGFloat, CGPoint, and CGSize. We should add a method for CGRect as well.

Interpolation can currently be initialized as an interpolation of a CGFloat, NSDate, or another Interpolation. We should add conveniences for initializing it with the interpolation of a Float or Double as well.

Paralayout's applyVerticalSubviewDistribution and applyHorizontalSubviewDistribution methods are incredibly powerful. Adding a result builder could make the code that creates these distributions more expressive.

In the simplest of cases, utilizing a distribution builder would enable removing the need to declare an array. Taking us from:

containerView.applyVerticalSubviewDistribution(
    [
        1.flexible,
        titleLabel,
        16.fixed,
        bodyLabel,
        16.fixed,
        actionButton,
        1.flexible,
    ]
)

to:

containerView.applyVerticalSubviewDistribution {
    1.flexible
    titleLabel
    16.fixed
    bodyLabel
    16.fixed
    actionButton
    1.flexible
}

But that's just the beginning. Since result builders allow for inline if statements, they'd enable writing distribution like:

containerView.applyVerticalSubviewDistribution {
    1.flexible
    titleLabel
    if bodyLabel.hasText {
        16.fixed
        bodyLabel
    }
    16.fixed
    actionButton
    1.flexible
}

Result builders also enable inlining for loop and if-else statements, enabling consumers to inline complex distributions. The benefits here purely syntactic – there'd be zero changes required to the underlying Paralayout library. The only additions would be:

1. A @resultbuilder public struct ViewDistributionBuilder type.
2. A applyVerticalSubviewDistribution method that takes a @ViewDistributionBuilder _ distribution: () -> [ViewDistributionSpecifying] closure rather than a _ distribution: [ViewDistributionSpecifying] argument. This new method would call through to the existing applyVerticalSubviewDistribution method.
3. A applyHorizontalSubviewDistribution method that takes a @ViewDistributionBuilder _ distribution: () -> [ViewDistributionSpecifying] closure rather than a _ distribution: [ViewDistributionSpecifying] argument. This new method would call through to the existing applyVerticalSubviewDistribution method.

Result builders were introduced in Swift 5.4, so this functionality would only be added for consumers using Swift 5.4 and above. I'd be happy to put up a PR that accomplishes this – I recently did something similar in another view layout library.