Why use WeView 2?

Summary: iOS Auto-Layout is complex and unwieldy and yields ugly code.

• Conceptual Complexity When using iOS Auto Layout you need to manage considerations such as constraint priority, constraint sufficiency, constraint conflicts (ie. over-constrained layouts), ambiguous layout, nearest common ancestors, etc. These issues also complicate refactoring and redesign.
• Lack of locality iOS Auto Layout is based on a complex constraint-solving system. The final position and size of any view in the system can be affected by all of the constraints in the system. Those constraints don’t necessarily reside on the view’s parent. It can be difficult to resolve an issue that without understanding the entire view hierarchy.
• Code Complexity Here’s a simple code comparison, based on Apple’s sample code that centers a button at the bottom of it’s superview bounds with 20pt spacing.

Here’s the layout using iOS Auto Layout:

iOS Auto Layout also supports a Visual Format Language. Here’s the same layout using VFL:

Here’s the equivalent logic using a WeView:

iOS Auto Layout has the advantage of being integrated into Interface Builder, and the Inteface Builder support for iOS Auto Layout has dramatically improved in Xcode 5. However, as soon as you outgrow what can done in Interface Builder, you must work programmatically and iOS Auto Layout requires verbose, brittle code.

WeView 2 can only be used programmatically, and is designed to yield concise, expressive and maintainable code. The benefits of the syntax only become more clear as layouts become more complex.

Other Alternatives:

• ReactiveCocoaLayout is another alternative to iOS Auto Layout built on ReactiveCocoa.
• FLKAutoLayout. This popular project offers a UIView category that provides a variety of convenience methods for creating common constraints.

Next: Tutorial 1: Overview