Glassboard Shutting Down

I announced this over on the Glassboard blog, but we are shutting down. Why? I failed to turn it into a sustainable business.

I have a laundry list of things I think I got right, and things I screwed up on in this whole ordeal. I’ll write them up when I feel like I can get through it.

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.

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.

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.