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.
Another new identifier Apple added in iOS 8 is the private API property
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:
- Open one of your view controllers.
- (void)viewDidLoadif 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
(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
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.
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.
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.
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.