On the iPad Pro and the Constraints of iOS

In their current incarnations, I believe that Windows 10 is better suited to the Surface than iOS is to the iPad Pro.

Now, with that quotable hot take out of the way, let me explain. I have every intention of dropping some serious coin on the highest end iPad Pro, keyboard, and a don’t-call-it-a-stylus Pencil this November. I use my iPad Air 2 every single day for reading my Pocket queue, Kindle books, and watching video from a variety of different source apps. Occasionally I will even do some “real” work on it too.

During the Apple event this week, the company brought on stage various partners to showcase apps they had built to take advantage of the hardware and accessories of the new iPad Pro. They showed someone annotating an email attachment and then sending it back (something I believe has never happened in the history of mankind outside of a technology demo). Microsoft came on stage to show how you can get business done with an iPad Pro and Office. Adobe showcased a few different apps for touching up photos.

What was not highlighted nearly enough, however, is how awkward iOS looks on such a seemingly large device.

This is a 13″ screen using the same grid of icons as its other iPad counterparts. On the Pro, however, there is so much space in between each icon that you could rush for a touchdown on every play.

Compare this with the Surface 3 and Windows 10. You can organize your apps on a full screen view that has its icons closer together and in grouped with a far better visual metaphor than a folder. Your most frequently used apps are surfaced (sorry) along the left edge of the screen as well. Is it more complex than iOS? Yeah, but I wouldn’t say it’s too complex to understand. Windows still has the same concept of press and hold to move icons around and swiping left and right to page between different parts of the screens.

And we haven’t even started talking about the third-party ecosystem for the iPad. I can count the number of apps on my left hand that are thoughtfully designed for the iPad screen size. Most are, for lack of a better phrase, blown-up iPhone apps. Just this week, Twitter updated their iPad app to be exactly like the iPhone version but with a bit more padding on the edges to make up for the larger screen size. That’s fine for the iPad mini and mostly tolerable for the Air. On the iPad Pro? That’s approaching clown shoes territory.

A lot of this thinking is thanks to Apple and the invention of size classes in iOS 8. With size classes, you are able to more easily adapt your interface to work with a variety of different screen sizes and orientations. This is a great thing. I’m currently in the middle of converting a rather large legacy project from having two different interfaces (iPhone and iPad) to using a single storyboard and size classes.

Most developers for whatever reason (time and/or money I presume) don’t bother thinking of the iPad beyond throwing their iPhone views into a split view and calling it a day. The majority of users are on the iPhone after all. The iPad has always been somewhat of an afterthought as a destination. Size classes help alleviate that since it’s so easy to now build universal apps, but that doesn’t mean you’re building an app that is going to feel at home on a 13″ tablet. It’ll feel bigger at least?

You will not see any defense by me of Windows software, especially modern Windows apps designed for 8 and 10. It’s also mostly hot garbage, and likely for all the same time and financial constraint reasons as the iPad. Software in this new app era is even harder than it used to be.

Side-by-side apps, a new feature of iOS 9 can help with some of the multitasking issues that have always plagued the iPad. For instance, try writing a paper on an iPad using Pages while looking up research in Safari. There is a lot of double-tapping of the Home button to jump between apps. Now you can at least pin both of them side-by-side, which helps. It’s still fairly rudimentary, especially compared to the types of Window management you can achieve on OS X or Windows. On the iPhone this sort of limitation makes sense. You don’t need to run multiple apps side-by-side on a phone. On the iPad though, the window management story is not that simple. There has to be something better between the bare minimum features of iOS and the window management hell you can theoretically get into on a desktop.

All of this so far and we aren’t even touching on the problems Apple and the iPad have as a software ecosystem. There’s been more than enough pixels spilt over how difficult it is to build a sustainable software business in today’s app economy where $4.99 is considered premium, trials are a thing of the past, and Apple keeps printing money off the back of Smurf Berries and other in-app purchases. The iPad Pro is a device that is begging for great third-party software from both large companies like Adobe and Apple, as well as the smaller guys like Gus at Flying Meat. A larger screen, keyboard case, and a Pencil aren’t going to solve those problems. You can’t have a Pro tablet without pro apps to go with it. There are a few great iPad apps out there, but most of them feel like minimum viable products at best.

And for the record, I don’t think OS X on these devices is the answer. I want a forward-thinking, touch-powered device this size. The iPad Pro is close, but iOS is going to hold it back. iOS could be a great operating system for professional computing, but right now the iPad remains to me a great device that is being held back by its OS being primarily for phones.

But, man. Imagine how fast the Kindle app is going to fly with 4GB of RAM!

Achieving Zen With Auto Layout (2nd Edition)

Last year I released a book based on all my speaking engagements around Auto Layout called Achieving Zen With Auto Layout. The book was very well received when it was announced and it made me realize I enjoyed writing about technical topics again (with the absence of a publisher, everything is wonderful!).

I’m pleased to announce that I’ve spent the last few months updating the book for a second edition. This new edition of the book contains a ton of new content and converted nearly every piece of code from Objective-C to Swift.

New topics covered include:

  • Working with size classes
  • Active and inactive constraints
  • Using layout guides effectively
  • Layout anchors
  • Debugging constraints using Swift (which is harder than it should be!)
  • Much, much more.

If you’re new to iOS and Auto Layout or just want to learn about what’s new with layout in iOS 9 and El Capitan, this is the book for you.

Purchase Achieving Zen With Auto Layout.

Auto Layout Debugging In Swift

I’ve been working with Swift primarily over the last month. Recently I started working on a new custom interface piece that was having some rendering issues with its layout constraints. I went into LLDB and quickly realized that using private methods such as _autolayoutTrace and recursiveDescription to print out a hierarchy of my views and see ambiguity wasn’t possible out of the box.

The reason for this is that when you’re in a Swift frame, LLDB is expecting you to call a Swift method it knows about. Since _autolayoutTrace and the like are private API, they don’t have any visibility to Swift. Safety!

There are a few different ways to get around this. The first is straight in LLDB. You can use the expr command to tell LLDB that you are passing it a snippet of Objective-C code like so:

expr -l objc++ -o -- [[UIWindow keyWindow] _autolayoutTrace]

What we’re doing here is printing out our entire view hierarchy to the debugger. Frequently typing that long of a statement is obviously a bit tedious, so I tend to put it in my .lldbinit file.

command alias alt expr -l objc++ -O --[[UIWindow keyWindow] _autolayoutTrace]

Now you can just type alt and get the same output from the debugger.

You’ll notice that I am throwing this out for the entire contents of the keyWindow. I haven’t been able to find a way to pinpoint it down a single property such as self.view, so if you have any feedback on that, please share!

If you’re mixing Objective-C and Swift, you likely already have a bridging header. You can bridge add a category on UIView that exposes the recursiveDescription and _autolayoutTrace methods to Swift.

#ifdef DEBUG

@interface UIView (LayoutDebugging)

#pragma clang push

#pragma clang diagnostic ignored “-Wincomplete-implementation”

- (id)recursiveDescription;

- (id)_autolayoutTrace;

#pragma clang pop



And the implementation file.

#import “UIView+LayoutDebugging.h”

#ifdef DEBUG

@implementation UIView (LayoutDebugging)

// Nothing to see here!



Let’s walk through this. You’ll notice that I have the entire thing wrapped in an #ifdef DEBUG statement because I am working with private APIs that I presume the App Store usage checker would flag and reject your app against. With the #ifdef, I am saying that it should only be included on development builds. Apple will have no idea what abuses we are committing since it will never make it to the release builds!

The other atrocity I am committing in this file is the use of #pragma clang diagnostic to tell the compiler to ignore any ‘uninmplemented method’ warnings that will pop-up from not being able to find an implementation for the two methods we defined in our category. Since they exist as private API, we don’t need to reimplement them.

Now if you break in a Swift frame with LLDB and try to call self.view._autolayoutTrace() you’ll get an output you expected.

Happy debugging!

If you’ve found this post useful, and want to learn more about how to best take advantage of Auto Layout in your OS X and iOS apps, be sure to purchase my new book Achieving Zen With Auto Layout

Repurposing the Titanic

My biggest mistake with Glassboard was having blinders to the fact that the design decisions Sepia Labs made when building Glassboard would likely clash with mine. That doesn’t have anything to do with visual design. Instead, I’m referring to the platform architecture decisions they made as a funded startup, or spin-off, or whatever they were.

The folks at Sepia had a parent company in Newsgator that was funding everything on Glassboard from the server costs, their salaries, and all the perks that go with that. More importantly, they were funding these things with the typical startup mentality in mind: get as many users as humanly possible and then worry about monetization later.

Glassboard under Second Gear had a completely different mindset: try to convert our most passionate existing users to paid users, and then grow from that. I sadly failed at doing that. There are a variety of different reasons for that failure, but one of them is how much time I spent undoing some architectural decisions from their previous owner.

That’s not a knock against Sepia or NewsGator. They built a great product. They just built it with a far different set of constraints than I had as the new owner funding this out of pocket.


One of the biggest was e-mail. Glassboard was sending over 150,000 emails a day when I took over. The SendGrid bill was $2400 in November of 2013, which is kind of crazy. I was able to cut that bill in half by negotiating a better rate to account for how much email we send, but it was still four figures a month.

Sepia didn’t need to worry about justifying that cost because it was another feature in the checkbox to try and acquire users. Don’t want to use an app and get push notifications? We’ll send you an email every single time someone comments on your board posts!

E-mail to Second Gear’s Glassboard is, however, a sunken cost because none of those costs were ever passed on to my customers. My thinking at the time was that I could convert enough users to premium accounts to fund the transactional email for everyone. In reality, that proved to not be the case.

I spent far too long in that mindset. When I finally wised up and made transactional email a premium user feature, my costs dropped down to under $100 a month. It also pissed off more users than it converted, but that was to be expected. The lesson I learned is that people wanted those emails, but they didn’t want to pay for them. It was a nice-to-have thing, but not a must have. I wish I had learned that lesson $15,000 ago.

Computing Costs

The biggest project I undertook during my time with Glassboard was converting the entire backend to use computing resources more efficiently. There were three different cloud services that powered Glassboard:

  • Notifications Role: this handled dispatching push notifications, emails, and archive processing. It ran on 2 medium-sized cloud service instances.
  • Attachment Processor Role: this would take the videos users uploaded, compress them, and make them more mobile friendly. This ran on a single Large cloud service instance. Why I didn’t kill video on day 1 is beyond me. What a poor job on my part.
  • Glassboard Platform: This was the kitchen sink project. It ran the API, the web app, web hook processors, and pretty much everything else. It was 4 medium sized instances when I took it over (I may have the number wrong, but it was quite a few).

I was able to get a few quick wins by enabling auto-scaling so that the instances would rise and fall based on usage patterns. It’s silly to pay for a ton of servers at 3AM on a Sunday when there’s not nearly enough users to justify the costs.

The biggest issue is that the only way to scale Glassboard in that incarnation was to throw more hardware at it. I spent an ungodly amount of time converting the entire backend platform to use C#’s async-await pattern. I am fairly confident I touched every single file in the project. One does not merely convert one portion of their code to be asynchronous. It’s a rabbit hole that you keep going down until you reach the bottom.

It was a lot of work, but once it was deployed I cut my server costs across the board in half.

Of course, by the time I got to that point, it was too late. I cut costs on a product that wasn’t commercially viable. Oops!

Lessons Learned

Building products with a bootstrapped mentality is completely different than a startup mentality. When bootstrapped, every decision you make affects the bottom line, and that is a bottom line you care about from day one. Trying to convert a platform that wasn’t designed with that in mind proved to be too great of a challenge for me as the sole proprietor of Glassboard. Rather than focusing on improving the core Glassboard product, I spent most of my time trying to cut costs where possible to curb our losses.

Would it have been more feasible if I had some help? Most likely, but I still don’t think that would have saved the platform.

If I had a do-over, I think my first decision would have been to shut down the Glassboard service as it was in November of 2013 and relaunch it without any of the legacy user accounts or data. If you wanted to continue using the service under Second Gear, subscribe now. That would have lowered costs up front and allowed me a lot more runway and likely time to delay a lot of cost-cutting projects that took up most of my 2014. Of course, there’s obvious tradeoffs in this decision too.

Hindsight is a bitch.

What Problem Are You Solving?

The worst day I had in my time with Glassboard came last month. It was becoming obvious that even with the latest round of changes to the business model and pricing schemes, things weren’t turning around as well as I had hoped. I had no beliefs that new pricing would be a magic bullet to solve all of the platform’s problems, but I did think it’d be more successful converting users than it was.

In reality what happened is that rather than paying a small monthly or annual fee to continue using Glassboard as they were, more people opted to find another free alternative to move their group or business whether it be Slack, Google+ (lol really), or any of the 85,000 other alternatives on the market.

Couple this with me having a pretty big crisis with a botched migration to a new push platform, and things weren’t going really well for me. This was the point I started to think about where to take Glassboard next. Rather than keep all those discussions internal to my brain, I emailed a variety of different people ranging from friends, colleagues, users, and other business owners. This is the email I sent them:

Have come to the realization that running Glassboard in its current state is not tenable financially, mentally, or physically.

A lot of different problems with it as a product and not sure how to solve that. Mostly it feels like a niche product without a well defined audience.

Any ideas on how to figure that stuff out or where to go with it? Trying to get a bunch of different opinions, because I’m honestly not sure what to do.

Most everyone responded back, and not much of the feedback was good in the “your platform is great! Keep going!” sense. Most people were scratching their heads just as much as I was about where to take this thing next.

The best response I got fairly direct: who is the audience for your Glassboard and what problem do you solve for them?

I didn’t have a good answer for either of those questions. Shit.

Finding An Audience

If the answer to “who is your product’s audience” is “anyone with an iPhone or Android device” you are likely screwed. One of the biggest things I have learned from the entire Glassboard experience is that ‘spray and pray’ audience targeting is something that isn’t likely to work. Glassboard’s marketing message has always been fairly generic from both its time as a Sepia Labs product and under my helm. The last marketing message was “Talk to your people”, with people being a pretty generic term meaning it could work for personal or corporate communications.

There are very few collaboration products on the market that work well for both of those markets.

I spent a good amount of time over the last few weeks looking at analytics data to try to understand who was currently paying for the service and trying to analyze each of the markets that was being served by Glassboard currently. I analyzed them by three different metrics:

  • Audience size: How many potential customers are there like this group?
  • Likelihood they will pay: Do they have money AND are they willing to
    part with it to solve the problem?
  • Access to market: How easy is it for you to market to these people and
    get them to pay you for it?

My potential markets based on analytics and user interviews were families, small businesses (think Q Branch), medium-sized businesses (think OmniGroup), conferences, consumer ad hoc groups (a book club), and professional ad hoc groups (a beta test board or a cocoaheads meetup).

Analysis said I should focus my efforts towards the professional ad hoc groups and medium sized businesses because they had a large audience, were likely to pay if Glassboard could solve an actual problem for them, and there weren’t too many gatekeepers preventing me access to marketing at them.

Solving A Painful Problem

The key to selling a product to a user (whether it be a consumer, business, or enterprise) is to offer a solution to a problem they are having. If you can make that problem less painful, people are willing to pay for it. For instance, an app like OmniOutliner is successful because it’s far easier to create complex outlines in it across platforms than it is using just plain text files. TextExpander makes good money because they help power users save keystrokes by automating repeatable strings of text.

Glassboard? Well, I realized that Glassboard wasn’t really targeted at any specific group and it didn’t really solve any real sort of problem.

Here are a few different ways I tried to explain the problems Glassboard solved:

  1. It allows anyone with an iPhone or Android to communicate securely and privately.
  2. It allows users to have threaded conversations rather than IRC-style chat lines.
  3. It allows conference attendees to communicate with each other from their mobile devices.

None of these are real painful problems. You can likely name a variety of different apps that can solve #1 and #3. Threaded communications is nice, but it’s also proven to be far too niche and not really something people are willing to pay for.

I realized that Glassboard in its current form is for all intents just yet another chat platform for iOS and Android. Yeah it had an audience, but not an audience that was willing to pay for it to stay around. It didn’t solve an actual problem better than any of the free alternatives out there, so people left rather than keeping the lights on.

What Did We Learn?

What lesson can you take from my failures? Take a look at your current product and ask yourself what problem it is solving that makes it stand out from the competition. Also, ask who has that problem and if you are reaching them as well as you could.

If you are in a situation like me where you don’t have a good answer for either of those questions, you need to sit down and start answering some hard questions about where you take things next.

In my case, the risks of shifting Glassboard towards where I thought it should go next were too high for me to take on. Every business and product is different. Hopefully you learn from my mistakes and can make an excellent (and successful) product.

The Gamble

Last week I announced that Glassboard will be going out of business as of November 1, because I was unable to turn it into a profitable business. There are a lot of different things I want to cover eventually about the past year I’ve spent working on this thing. For one, it’s therapeutic to me to get it out of my head. Second, my hope is that people can learn something from my successes (yes, there were some) and failures (those too).

I knew going in that Glassboard was a moonshot. I was in essence taking over a platform that was run by six people with stable salaries from a parent company and doing it by myself, while trying to shift what turned out to be the titanic away from the iceberg.

Running any business, large or small, is mostly about managing risk. You want to invest in the things that will grow profits. Startup culture skews this in our industry, because venture capitalists are willing to assume near-term losses in favor of potential long-term riches, but for our purposes, let’s assume we are building a business like our parents made. The goal is to spend less than you are bringing in.

I am a terrible Blackjack player, but I know enough to be able to play on a few hundred bucks and have some fun. If you’re under 12, you want to take another card, because you’re really not going to hurt yourself. If you’re over 12, you’ve got to start figuring out what cards have been dealt already from the deck and determine if its worth the risk of possibly busting or not getting a high enough count to beat the dealer.

Despite being terrible at Blackjack, I play it fairly conservatively and don’t stray from those two rules too often. I try to run my businesses in the same way. Second Gear and Glassboard have always been small shops that are run with the intent of supporting me and if it grows beyond that, great.

I knew the risk of taking on Glassboard up front would be how much money it was losing each month in sunken hosting costs (not including development and design time). I projected a few different scenarios for good, great, and ‘make it rain’ levels of growth to get the business out of the red and towards profitability.

Despite cutting the monthly losses by 80% from the time I took over to today, I never fully got to that break even point and began to realize that getting there and beyond was going to require a lot more hard decisions and evaluation.

So, how do you know when you’re done and it’s time to fold? When you start thinking about shutting things down, you’re done. There may be a Hail Mary out there that could possibly save the sinking ship, but my guess is that it will only prolong the inevitable.

For me, I knew for sure last Thursday that I was done. I realized it was going to be another $60,000 or so to turn Glassboard into the product that I thought it could be eventually. There was no way I could do that emotionally, mentally, or financially. The risk was too big. I announced the next day I was cutting my losses and shutting the service down.

Glassboard was a gamble that didn’t really pay off financially (no, mom. I am not losing the house), but it was still rewarding in a lot of other ways. Hopefully those will become apparent over the next few weeks as I dump all this out of my head.

Auto Layout In iOS 8 – layoutDebuggingIdentifier

Another new identifier Apple added in iOS 8 is the private API property _layoutDebuggingIdentifier to UIView that you can use to clean up what is output in _autolayoutTrace. Since it is private API, you don’t want to ship with this code in because Apple will likely reject it, but for debugging purposes it can be mostly harmless. Mostly.

There’s no easy way to set the _layoutDebuggingIdentifier identifier in a Storyboard or Xib, so we will have to add a bit of code to take advantage of it.

To take advantage of this:

  1. Open one of your view controllers.
  2. Override - (void)viewDidLoad if you haven’t already.

There’s a few different spots you could likely define the _layoutDebuggingIdentifier, but for view controllers, I tend to just put them in viewDidLoad. Here’s a sample of the code I use:

#ifdef DEBUG
    SEL selectorName = NSSelectorFromString(@"_setLayoutDebuggingIdentifier:");
    NSString *identifier = @"Email Label";
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    [self.emailLabel performSelector:selectorName withObject:identifier];
#pragma clang diagnostic pop

Oh boy. This looks crazy. Let’s break down what’s going on line-by-line.

On the first and last lines, I’m again wrapping everything in an #ifdef DEBUG block because I don’t want to ship this bit of code with my product to the App Store.

The second line I am creating a SEL variable by calling the NSSelectorFromString function and passing in “_setLayoutDebuggingIdentifier:” as a string. The line below it is defining what I want the _layoutDebuggingIdentifier string to actually be.

From there, things start to get weird. I’ve got three different #pragma calls. The first one is saying that I am going to start adding some specific instructions for the compiler about things I want it to take into account in the following set of code. That’s what “push” is. The last #pragma says “pop”, which means I am done passing those bits of code specific diagnostics in.

The specific diagnostic message I am calling is #pragma clang diagnostic ignored "-Warc-performSelector-leaks" which is telling the compiler to ignore the warning about my performSelector call possibly leaking, because it may not exist. Since _layoutDebuggingIdentifier is private API, the public framework headers don’t know what to do with it, so the compiler assumes it doesn’t exists. I assure you it exists as of iOS 8 though, so we can safely ignore that warning.

The one caveat of course is that since this is private API, Apple can either remove it or change it in a future release. Be aware.

Thus far we’ve set a single _layoutDebuggingIdentifier for our email label. Go ahead and set them for the rest of the controls that you care to have nicer output from.

After you do that, run the application again and print out the output of _autolayoutTrace.

(lldb) po [self.view _autolayoutTrace]
|   •UIView:0x7fdb83d3d470
|   |   *Email Label:0x7fdb83d3d780
|   |   *Password Label:0x7fdb83d3fae0'Password'
|   |   *Logo Image:0x7fdb83d3ff70
|   |   *Email Field:0x7fdb83d40980
|   |   |   _UITextFieldRoundedRectBackgroundViewNeue:0x7fdb83d4a240
|   |   *SignIn Button:0x7fdb83d4cfe0'Sign-In'
|   |   *Password Field:0x7fdb83d4e070
|   |   |   _UITextFieldRoundedRectBackgroundViewNeue:0x7fdb83d4f4b0
|   |   *_UILayoutGuide:0x7fdb83d4f9a0
|   |   *_UILayoutGuide:0x7fdb83d503b0

Ah…much nicer.

If you’ve found this post useful, and want to learn more about how to best take advantage of Auto Layout in your OS X and iOS apps, be sure to purchase my new book Achieving Zen With Auto Layout.

Ninety Days

Aside from a bit of snark, I’ve kept mostly quiet about this year’s indie developer snafus. It’s not really my place to tell you how to run your business, but I can share some things I have done that I have found to be successful.

When Jared told me last year he was going independent and planning to work on an RSS app for the iPhone, he asked me for some advice. I gave him the same advice I give anyone who is striking it out on their own.

Do not spend more than ninety days on your 1.0.

Jared spent approximately 365 days on his, so I apparently give crummy advice! But, there’s a reason I told him this (and anyone else that would listen). 3 months is a quarter of the year. When you are bootstrapping a company and don’t have much cushion to fall back on, every decision counts. You could argue its far more risky than playing with some venture capitalist’s funny money.

Ninety days is a good amount of time to get a semi-polished 1.0 out in the world, especially in mobile. It won’t have every feature that you wanted to ship, but it will be out there and either be validated or invalidated by the buying public.

Best case scenario, people find your product, start using it, and (most importantly) recommending it to others. Now you’re generating revenue and your customers are funding your work adding those missing features and putting those extra bits of polish in your UI.

Worst case scenario, people don’t find your product, you make a couple hundred bucks, and you’re in debt for the project. This is the most likely statistical outcome at this stage. Would you rather find this out after 3 months or 6 months (or a year)? Ninety days.

If the product bombs, you’ve burned 3 months of the year on the project, but there’s still 9 more months to try and find something that will stick with consumers. Kill the old product. Start a new one. Move on.

The notion that you have to build this perfectly polished 1.0 in 2014 is poor advice. I like to reduce the amount of risk I take on in business. Taking four swings at the fences a year to find a new business is way less risky than trying to take just one.

Don’t ship junk. Just don’t bother spending weeks or months polishing something that users may not even care enough to buy.

Auto Layout In iOS 8 – Layout Margins

Apple has added a few additions to both iOS 8 and OS X Yosemite that make working with Auto Layout even more of a no brainer than before. Over the next few weeks, I am going to take some time to write about each one of them to give fellow developers an idea of how to make use of these features in their products.

Up first is layout margins.

In iOS 8, Apple added the layoutMargins property on UIView. layoutMargins takes a UIEdgeInsets value that lets you explicitly define the whitespace that your views can use to guide where portions of the interface should be placed.

UILabel *label = [[UILabel alloc] initWithFrame:CGRectZero];
label.translatesAutoresizingMaskIntoConstraints = NO;
label.layoutMargins = UIEdgeInsetsMake(-20, -20, -20, -20);

For anyone that has used the topLayoutGuide or bottomLayoutGuide properties on UIViewController in iOS 7, laying out along a margin shouldn’t be a foreign concept. Those predefined values made it so that the content of your view wouldn’t be sunk underneath a transparent tab or navigation bar. With iOS 8, Apple has extended that functionality so that you can apply custom margins to any UIView that you work with.

To go with the new layout margins functionality, there are new attributes added exclusively for iOS 8 for establishing relationships with Auto Layout.

  • NSLayoutAttributeLeftMargin – The left margin value of the view.
  • NSLayoutAttributeRightMargin – The right margin value of the view.
  • NSLayoutAttributeTopMargin – The top margin value of the view.
  • NSLayoutAttributeBottomMargin – The bottom margin value of the view.
  • NSLayoutAttributeLeadingMargin – Similar to NSLayoutAttributeLeftMargin, except the but the interface flips in a right-to-left environment like Hebrew or Arabic.
  • NSLayoutAttributeTrailingMargin – Similar to NSLayoutAttributeRightMargin, except the but the interface flips in a right-to-left environment like Hebrew or Arabic.
  • NSLayoutAttributeCenterXWithinMargins – This is similar to NSLayoutAttributeCenterX, but it takes into account the margin values that you have set.
  • NSLayoutAttributeCenterYWithinMargins – This is similar to NSLayoutAttributeCenterY, but it takes into account the margin values that you have set.

If these all look familiar, they should. They are pretty much equivalent to the old attributes you used such as NSLayoutAttributeLeft, NSLayoutAttributeRight, and NSLayoutAttributeCenterY. The only difference is that these new methods take into account the layoutMargin values that you set.

If you are targeting iOS 8, you should start adopting these new margin capabilities in your app, because it will lead to much cleaner code. Instead of having to use the constant value of your Auto Layout equation to insert padding, you can now just set the layoutMargins value specifically on the view, and let Auto Layout use those margins as part of its process.

If you’ve found this post useful, and want to learn more about how to best take advantage of Auto Layout in your OS X and iOS apps, be sure to purchase my new book Achieving Zen With Auto Layout

Achieving Zen With Auto Layout – The Book

tl;dr I am writing a book on Auto Layout. You can purchase it now.

Over the last year I have been criss-crossing the country giving a talk called Achieving Zen With Auto Layout to any conference or user group that would host me. Speaking is not my primary goal. I am not an ex-developer. I just enjoy doing it a few times a year, especially since I spend so much time sitting in front of a computer in a solitary room typing. Even the most antisocial developers need a bit of human interaction.

The talk has been well received far beyond my expectations. Everywhere I have presented has given it high marks and attributed it with helping them get over the hurdles of learning and using Auto Layout in their jobs.

I have had it in the back of my head that I wanted to turn the talk into a book for a while. Every time I have thought about it, however, I have pushed the thought away. Writing a book is hard. Dealing with publishers is a pain. You don’t make much money doing it. Why bother?

Despite all the reasons to not do the book, I kept coming back to the main reason I wanted to do it: I like helping people. I like when people tell me my talk has helped them learn a new technology. I enjoy having people say they learn new things from CocoaRadio.

So, I started writing. Not full-time. Not even part-time. I just started writing when I had time. Over the last few months, I have amassed enough content to generate what I consider to be the first 1/3 of the book.

Achieving Zen With Auto Layout is the eBook companion to my talk of the same name, but with the goal of being much more expanded than what I am able to do in a 45-60 minute on-stage presentation.

This is a beta book right now. There are no screenshots (iOS 8 does still have a tiny bit of NDA that prevents those), copy editing hasn’t been done, and I still need to hire an illustrator to do a cover and some other things in the book for me. Content-wise though, I’m proud of what is there so far, and I’m excited to finish the rest of the book in time for the iOS 8 launch later this fall.

You can purchase Achieving Zen With Auto Layout today and get access to a PDF of the current state of the book, as well as a private GitHub repository where I am writing and storing all the sample code as I go. So far this has proven to be a wonderful way to write, because buyers of the book are able to provide direct feedback to me about the book so I can iron out any confusion or missing things I may not have thought of during my first draft.

If you’ve struggled with Auto Layout in the past, I truly believe Achieving Zen With Auto Layout can help you get over those hurdles.

Purchase “Achieving Zen With Auto Layout”