Another iOS Blaaahg

A blaaahg dedicated to explaining moderate to complex iOS concepts in a way more approachable by even the most beginner iOS developer.

Auto Layout: A Helpful Introduction to Visual Format and How Awesome Constraints Can Be.

Auto Layout is a feature that in many ways felt almost un-approachable in its complexity when first introduced in iOS 6. With the release of Auto Layout 2.0 in Xcode 5 and subsequent update in Xcode 6, there were many improvements that made Auto Layout seem much more approachable. More specifically, changes were brought to Auto Layout that gave more freedom in the way you express your layout through constraints with the addition of the visual format language (henceforth described with ‘VFL’).

This post is quite extensive and will be followed by several posts to cover the vastness that is VFL, and will likely extend into the various combinations that can be utilized in dealing with constraints.

VFL is an easier and convenient way of describing your objects using an expressive string to describe your layout in a relative format that can avoid the tediousness of individually creating NSLayoutConstrains programmatically.

The intent for this post is to describe the general pieces of the VFL string in a way that allows newer developers the chance at understanding the various combinations of constraints describable in a non-storyboard driven fashion. Storyboards have come a long way in the describing power of AutoLayout and are still the primary way I prefer to layout my applications, but there are many times where you would prefer to instantiate a view programmatically for various reasons and in these times VFL is your best tool in your toolkit.

Basic building blocks of VFL syntax can be found and referenced in Apple’s documentation

For our first example, we are going to start out with a simple VFL constraint description.

UIView *viewOne =;
[viewOne setTranslatesAutoresizingMaskIntoConstraints:NO];
viewOne.backgroundColor = [UIColor redColor];
NSDictionary *viewsDictionary = @{@"viewOne" : viewOne};
NSDictionary *metricsDictionary = @{@"horizontalSpacing" : @15};

[self.view addSubview:viewOne];

NSArray *horizontalConstraints = [NSLayoutConstraint constraintsWithVisualFormat:@"H:|-horizontalSpacing-[viewOne]-horizontalSpacing-|"

NSArray *verticleConstraints = [NSLayoutConstraint constraintsWithVisualFormat:@"V:|-horizontalSpacing-[viewOne]-horizontalSpacing-|"

[self.view addConstraints:[horizontalConstraints arrayByAddingObjectsFromArray:verticleConstraints]];

In the above example, we are going to for now ignore the last 3 parameters taken and focus on the string.


This string will create an array of constraints that describes a relationship between viewOne and it’s superview. In VFL, this string reads “Horizontally constrain viewOne to have 15 pixels of space between the leading edge of the superview and the leading edge of viewOne and constrain viewOne to have 15 pixels of space between the trailing edge of viewOne and the trailing edge of the super view”, which is needless to say a mouthful.

Let’s take the above and break it into it’s parts.

As you may have guessed, you can discern the difference between horizontal and vertical constraints based off the leading character in the VFL string, “H:” defining horizontal constraints and “V:” defining vertical constraints, which is pretty straight forward.

In the context of VFL you can utilize pipes, or |, as symbolic representations of your superView, which is quite handy and removes the necessity of passing your superview into your views argument.

The next part of VFL to learn about is -horizontalSpacing-. This symbolizes the space between your left argument and your right argument, in this case your superview and viewOne. This value can be set to any valid integer that is capable of describing this relationship.

[viewOne] as you can guess is the way we represent views that are passed into our convenience method as arguments in the views dictionary parameter. The name between brackets will always be the key from your dictionary that you describe.

All of these pieces form together to describe a list of constraints to make your string describe the relationship between your view, and it’s superview.

Now is a great time to quickly go over the final parameters in this method.

The rest of the parameters for this method:

  • Options: Allows you to change the flow of your VFL, leading to trailing, left to right, right to left, and trailing to leading. (trailing to leading/leading to trailing allows for flexibility when supporting right to left languages!)
  • Metrics: Allows you to define custom parameters that you may pass in to your convenience method and assign meaningful descriptors as keys.
  • Views: Allows you to define the views you want to interact with in your visual format string and assign meaningful descriptors as keys.

Another important line when describing a view with AutoLayout programmatically is:

[viewOne setTranslatesAutoresizingMaskIntoConstraints:NO];

This line is important because it tells iOS to not attempt to add automatic resizing constraints, which are what allows Storyboards to layout basic views and not require any constraints to be defined by the programmer.

Stay tuned for the next extension to VFL where we will go over more advanced layouts where we will define the same layout in the 3 ways we have available in our AutoLayout toolkit.

Attending CocoaConf Chicago: 2014

CocoaConf is a 3 track, 2 daylong conference that makes its way through several cities across the United States, and is the first conference I attended while attempting to become a software professional. Since that time back in 2012 I have attended every CocoaConf to come to the Chicago area, this being the 3rd iteration I have attended.

Every year I have attended CocoaConf I have walked away with an amazing sense of awe and amazement surrounding the experience I just had, this year being no exception. The conference speakers, Dave Klein, and his incredible family round up for their conference are insanely intelligent, very enthusiastic, and most importantly very approachable by anyone. In my experiences with CocoaConf, that is my favorite part of attending. This year I had an amazing time discussing collections and game development with Josh Smith, enjoyed getting my mind blown by Jeff Biggus and his OpenCL talk, and all of the other amazing discussions that I attended. The variety of talks is very impressive, everything from Table Views, to OpenCL, to Core Animation, Text Kit and even Reactive Cocoa.

If you ever have a chance to attend a CocoaConf near you, you should without hesitation do so, doubly so if you are like me 3 years ago and looking for inspiration on what you want your career to become.

The Beginning

I want to start this blog with something similar to a declaration of intent. I want to use this blog, which I will refer to as “blaaahg”, as an attempt to take moderate to complex concepts and features of iOS development and make them more approachable for the common developer.

My motivation for this blaaahg was instilled by Eric Knapp. Eric is currently a teacher at Madison College who is responsible for guiding many students towards the understanding that learning is a developer’s greatest tool, including myself.

This is my first attempt at sharing what I know; please let me know if there are things I can improve upon (writing style, simplification of a subject, or anything else to help fulfill my intent for this blaaahg). Also, suggestions for subjects that anyone who is reading this blaaahg are interested in are more than welcome.

In the future this blaaahg will likely expand to encompass other aspects of life I find interesting, but will remain always focused on the goal I have set for myself above. More to come..