Duct Tape and Glue

Anyone that says software is ‘expertly crafted’ is lying to you. Eventually it is all duct tape and glue.

The Bubble Will Implode

Ariel Michaeli, friend and founder of AppFigures:

[F]ounders are flexible but also focused on their goal. Help them get there faster by throwing more money on the problem and they’ll take it, but give them less and they’ll still figure out a way to get it done.

Ariel’s list is a good one and aligns with a lot of my feelings on the state of technology investments today. $1 Billion for Instagram at the time seemed insane. The valuations of companies after that have gotten even worse. Just yesterday Reddit got injected with $50 million. Why does a web site need $50 million versus $10 million, or even less? Your guess is as good as mine.

CocoaRadio - Jay Graves on Provisioning Profiles

This week on the podcast, Jay Graves of POSSIBLE Mobile joins me for a deep-dive into provisioning profiles. Jay knows more about these things than anyone I know after spending the last few years wrangling builds at Possible (formerly Double Encore), and has always been my go-to person when I run into issues.

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 “_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]
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.