An Introduction to WWLayout
There are multiple options for building the layout of an iOS app, and everyone has their own preference. The two most popular choices: Use Interface Builder or write out your views programmatically. Each has their own way of creating view elements and specifying their constraints, one by using Storyboards and the other by writing everything in code. At WW, we write our views programmatically and specify constraints using a Swift DSL called WWLayout, which was written in house by one of our iOS engineers, Steven Grosmark.
Anyone who has built an iOS app using programmatic layouts understands the pains that come with it. Forgetting to add translatesAutoresizingMaskIntoConstraints = falseor neglecting to activate the constraints can cause headaches when your view doesn’t behave as you expect. This comes with a great deal of boilerplate code that can end up making your views and view controllers difficult to read. A complicated view with multiple elements scattered around the screen can add hundreds of lines of code to your project.
Background
To provide some background on the development process and reasoning behind creating the library, I reached out to Grosmark. Here’s what he shared:
“About a year and a half ago, WW was considering how to standardize our layout code. The options at the time were native constraints, visual layout (not an option, but we still had code using this), PureLayout, and SnapKit. Native constraints were overly verbose, visual format was too string-y, PureLayout wasn’t well maintained, and I wasn’t crazy about SnapKit adding associated objects to every view that was laid out. So I started exploring different kinds of syntax, from the perspective of “what kind of code do I want to be able to write?” After a few experiments, the method of having a lightweight
layoutproperty available to all UIViews felt right. With that figured out, it was just a matter of adding access to all the possible combinations of edges, constants, and priorities.” — Grosmark
When using packages in my projects in the past, I’ve always preferred lightweight solutions, which is why I’ve enjoyed working with WWLayout since I started at WW. As you can see from the quote above, WWLayout was designed around being as lightweight as possible.
Quickstart
WWLayout solves the issue of syntax by allowing users to write constraints in a readable fashion. WWLayout also takes care of all the boilerplate code that is needed to create views programmatically. You no longer have to toggle the translatesAutoresizingMaskIntoConstraintsflag or set isActive = truefor every new element added to your view, as WWLayout handles both of these.
Installation
1. Add pod ‘WWLayout’to your Podfile.
2. Run pod installto install the new pod.
3. Add import WWLayoutto your file you want to layout views.
Usage
WWLayout adds a layoutproperty on UIView, which is the main point of entry for the library. All constraints will be added using this property:
myView.layout.center(in: .superview)
The layout property holds a reference to the view element, allowing constraints to be chained one after another. Chaining constraints is as simple as:
myView.layout.width(300).height(400)
An example of centering a view element within a parent view is as easy as:
A slightly more complicated view with two labels and a button:
Let’s break this view down. There are three view elements, a button, and two labels. As you can see, some of the constraints above contain .superviewas an argument. WWLayout provides a .superviewconvenience instead of typing out the name of whatever the parent view is.
For titleLabel, I’m only constraining the top edge to be 50 points off of the top edge of the view and centered horizontally.
The leading edge of subtitleLabelis then constrained to titleLabel’s trailing edge with optional parameters for relation set to .greaterOrEqualand priority set to .low. The trailing edge of subtitleLabelis then constrained to the trailing edge of the .superview. We mark this priority as .highin order to take precedence over the leading edge constraint, which means that the trailing edge constraint will be fulfilled before the leading edge constraint.
Finally, the button is simply constrained to be below titleLabelwith an offsetof 30 and it will fill the width of the .superviewwith a maximum width of 315.
Every function has a number of optional parameters such as priority, relation, edge, inset, and offset. These optional parameters allow you to fully customize your constraints to create your desired layout.
.safeArea
Currently when adding constraints against the Safe Area you will need to do a check to see if the phone’s operating system supports it. This can cause the codebase to be littered with checks such as:
if #available(iOS 11.0, *)
WWLayout provides a convenience that removes this check by using .safeArea. .safeAreawill add constraints to the phone’s safe area layout guide and fall back to .superviewif they are not available.
fill()
One function that is incredibly powerful is fill(). fillcomes with a couple optional parameters — axis:and except:. axisallows you to specify that you want your view to fill all available space in either the horizontal .xor vertical .yplane. exceptallows you to specify that you want the view to fill all available edges except for a specified one on the view. I routinely use fillto build the views that I work on and it always proves to be useful.
Evolution
Just like any other open source project, WWLayout is constantly evolving to support new use cases. The next big update for the roadmap is tagging constraints, which will allow clients to easily switch between various layouts dynamically. This will open up the ability to specify constraints per size class so that your layout can automatically change when a device is rotated, for example. Both of these features are expected to be added soon (they are currently going through testing). I’ll include a GitHub link at the end if anyone has any features they would like to see added.
WWLayout is an incredibly powerful, lightweight, and readable way to write constraints for your views. It provides a boost in productivity by reducing the amount of boilerplate code you need to write in order to construct a view and allows for other maintainers to quickly understand the constraints later on.
WWLayout is open source and you can contribute or find the full reference at the GitHub repository.
— Grady Jenkins, Software Engineer on the iOS team
Interested in joining the WW team? Check out the careers page to view technology job listings as well as open positions on other teams.
