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
#endif

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 “_layoutDebuggingIdentifier” 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]
UIWindow:0x7fdb8511de90
|   •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.

CocoaRadio - Miguel de Icaza on Xamarin

This week Justin is joined by Miguel de Icaza of Xamarin to discuss building iOS apps using C# and the .Net frameworks. I’ve been intrigued by what the Xamarin folks have been doing for quite a while, especially when I learned one of my favorite apps (Rdio) was using the product to build their app.

Miguel and I discuss what Xamarin does, and of course how it does all of its magic. Being able to build mobile apps using Microsoft technology on the Mac is a pretty interesting project. We also cover some of the newer things Xamarin is working in related to enterprise apps, and Miguel’s thoughts on Swift.

CocoaRadio - Bryan Irace on CocoaPods

Bryan Irace of Tumblr joins Justin this week to discuss dependency management using CocoaPods, an open source library that makes it easy to add third-party code to your OS X and iOS projects.

Justin and Bryan discuss the basics of CocoaPods, how to use it as a developer, generating your own CocoaPods, and the holy wars that seem to surround the project.

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.

Listener Supported Podcasting

I hinted at this last week, but here goes nothing.

As of this week’s episode, CocoaRadio is doing away with selling sponsorships to advertisers and instead will be funded by memberships from our listeners. Sorry, Squarespace.

The Backstory

When I started the podcast, I knew I needed to find a way to monetize it to justify the time and cost invested in it. The obvious solution seemed to be selling advertising, because that’s what you do. I reached out to a few of the known ad vendors to inquire about their interest and was mostly blown off saying to come back when I had actual listener numbers.

OK, fine. I’ll do it on my own.

My goal with sponsors on CocoaRadio was to always make them targeted. It’s a very targeted audience of iOS and OS X developers, so developer tools, startups looking to hire, and web services seemed like a natural fit. Every ad we ran on CocoaRadio was a product I was proud to champion because they were all things I’ve used.

The problem is that selling ads is hard, and finding new sponsors is even harder. In fact, it’s the least fun aspect of doing a podcast. Talking to people is great. Interacting with listeners rocks. Trying to haggle on the price of a 3 week run with a large corporation? That sucks.

So, when I realized that CocoaRadio has over 25,000 listeners now, it became possible to start outsourcing the ads to someone else to deal with. But then I would likely lose control of which sponsors I ran because I’d be part of a package. That goes against my first rule of targeted advertising to the audience.

That’s when I remembered that NPR is wonderful.

The NPR Model

I got my start in doing radio and podcasting at our local NPR station in Evansville, Indiana. For two years I did a show and various segments around there to learn producting, editing, and hosting a show. The station was funded by donations from listeners, grants, and funding from public broadcasting.

I always liked the idea of having my show live or die by the support of the listeners who enjoyed it calling in and contributing to the station. It made everything feel more personal and like the listeners had a stake in the production.

So, that’s what I’m going to try with CocoaRadio. To start, I’m offering two levels of support: $5 and $10 a month respectively. Each one has its own set of benefits depending on the level of support you want to offer.

And just like supporting your local NPR station, I’m lining up some giveaways, discounts, and other benefits for people who financially support the show such as exclusive members only episodes, discounts on products, and a private Glassboard to interact with me and other listeners.

Support What You Love

With Glassboard NeXT, the book, and now CocoaRadio I’m practicing what I preach by trying to charge a fair price for my work. It seems unconvential in the landscape of computing in 2014, but I’m hoping there are enough people out there in the world like me that will make this a successful venture.

If you enjoy CocoaRadio and want to see it continue into the future, please consider becoming a paid supporter. Thanks for your continued support.