The Chicken or the iPad Pro


The iPad Pro went on sale this week. I picked one up at my local store, though my Pencil and keyboard case won’t ship for another few weeks.

I haven’t been this fascinated by a new device since the original iPad was released back in 2010. That is the device that got me re-energized to build my own iOS products after frustrations with the original incarnations of the iPhone App Store. My mind has been racing for weeks about ideas for this thing. There’s just one problem: I don’t understand why the device exists.

I use my iPad mini 4 every single day in the morning and evening as my primary method for reading, watching TV in bed, and sniping at people on Twitter. I keep no work-related apps on it. It is my personal device that is designed to let me focus on things that don’t involve my day-to-day duties as a software developer.

According to interviews with Tim Cook over the last few days, Apple is positing the iPad Pro as a full-on replacement for a PC or Mac for “many, many people.”

“I think if you’re looking at a PC, why would you buy a PC anymore? No really, why would you buy one?”

“Yes, the iPad Pro is a replacement for a notebook or a desktop for many, many people. They will start using it and conclude they no longer need to use anything else, other than their phones.”

Apple wants to cast the larger iPad as where the puck is going when it comes to knowledge workers. The days of carrying around a laptop or having an iMac or Dell on your desk to do your job are a thing of the past with the powerful iPad Pro.

No doubt if you are someone at the executive level who spends most of his or her time in email or browsing the web, the iPad Pro will likely be a great product. With anyone outside of that email and browser bubble, I struggle with seeing how the device fits without a tanker ship of compromises.

The Legacy Problem

I went home a few weeks ago, and my brother showed me his new MacBook he purchased for his online classes. His day job is managing a retail store, so his computing needs aren’t that heavy. An iPad sounds like it could be a great fit for him, right? Sadly, it was a nonstarter when he found out that the course required Silverlight in the browser.

I’ve looked at this software. All of it could be rebuilt on iOS and likely offer a better experience for students. Apple has provided all the APIs you need. What’s the financial incentive, however? iPad sales have been sluggish the last few quarters, and the iPad Pro has a giant question mark over it as to whether or not the general public will embrace it.

This isn’t a new problem. Apple faced something similar with the transition from MacOS to OS X in the late ‘90s and early 2000s. The biggest difference between then and now is that OS X isn’t going anywhere. Convincing someone who is getting by building web apps in Silverlight they should scrap all their existing code and build something natively on the iPad is a much harder sell than telling Adobe they need to embrace Carbon to get Photoshop running on Mac OS X.

The Ecosystem Problem

The majority of productivity apps that I have on my iPad Pro fall into three camps: first-party tools from Apple, a productivity suite from Microsoft, or $5 apps from hobbyist developers.

This is likely where you expect to read the same excuses about app sustainability and the lack of trials and upgrade pricing on the App Store. I’ll spare you rehashing those arguments for the millionth time.

The overarching reality is that, like any business, selling software is hard. The mythical App Store — where just building something means you will be swimming in a pool of money — still hasn’t surfaced after seven years of people promising it was coming.

What has shown up, however, is a world where the top grossing apps on the store are free-to-play games from two or three major game publishers. Game of War and Candy Crush have dominated the top grossing chart of the App Store for years at this point. They are likely raking in six figures (or more) a day just from the App Store. Add Google Play on to that, and now you know who actually has the swimming pool of money.

Compare that to the podcast app market, which is now switching to the tip cup model — used by panhandlers around the world for decades. These are “premium” apps that used to sell for the outrageous price of $4.99 and now have now switched to the “pay if you can be bothered” model because getting people to pay for software today is an even more difficult proposition than it was a decade ago.

Trials and upgrades aren’t going to solve the problem of developers shooting themselves in the foot or continuing to refuse to understand fundamental business concepts like marketing.

As a thought exercise recommend your favorite paid app to someone that is not a nerd. I have friends who are allergic to exercise that will run for the first time ever to avoid paying even $.99 for something on their phone. You’re telling me those folks are going to spend $39.99, even if the app can make them more organized and likely help them do their job better?

Omni makes it work, though. They have dozens of employees and don’t sell their software at bargain basement prices. The sad reality is there aren’t enough Omnis in the ecosystem right now to make the iPad Pro a viable productivity platform for anyone but those executives, retired folks, and masochist bloggers who jump through more hoops than a circus elephant to use an iPad instead of a Mac.

The app ecosystem isn’t the only problem. As I mentioned previously, iOS looks somewhat out of place on the iPad Pro. Visual oddities like the amount of spacing between app icons on a 13” screen seem like something that has to be resolved in iOS 10 with a re-imagined home screen of some sort.

Split-screen support doesn’t solve any of the interconnectivity problems apps still have where it’s not a trivial task to move a chart or spreadsheet from one document and insert it in another. These are problems that a mouse and drag-and-drop solved decades ago but are still a chore to do on iOS.

New features like extensions, app groups, and enhanced URL scheme support have helped make iOS a better overall platform. Having links from Twitter open directly in the Twitter app versus Safari is a great experience.

A lot of those improvements to iOS are related to helping individual apps be more extensible versus enabling Vendor A’s app to talk to Vendor B’s in a sane way.

To improve this sharing, iOS 8 added the concept of document providers. The feature has been available for nearly a year, and I can count on my left hand the number of apps I’ve used that have implemented it in a meaningful way. Even my favorite Omni apps consider document providers “beta” in favor of their own OmniPresence sync solution.

The apps that I have used a document picker with haven’t exactly been easy to use either. Most have copied the file from the document picker into their own app sandbox, which now gives me two different versions of a document in two different places. The future!
Smart people have worked out ways around a lot of these issues using apps like Workflow or writing scripts in apps like Editorial. To argue that writing scripts is a viable solution for anyone but the hairiest of neckbeards is insane.

I have no doubt Apple is aware of iOS’s limitations, and presumably working on solutions for it. As of today, however, I can’t imagine doing more than the most basic things on iOS without feeling like I am paddling upstream.

Why Does the iPad Pro Exist?

Like the Apple Watch, I’m having a hard time understanding why the iPad Pro exists right now. In a lot of ways, it feels like they threw this out as a reactionary tactic to slumping sales to see what happens.

Each new platform or device Apple releases is met with the same “We can’t wait to see what you develop for this” message to developers. With the iPad Pro, that invitation is feeling more hollow than ever, given the state of everything I’ve outlined above.

It’s possible that I’m overanalyzing all of this and the target is really schools or enterprise deployments. Selling 50,000 iPad Pro tablets to someone like IBM so they can load their own in-house software on the device makes a lot of sense.

I’m fine with the fact that I will always be a “Mac person.” I build software for a living, so I am someone who will likely always need all that OS X affords me to do my job. It’s for people like my brother, who just dropped nearly $2,000 on that new MacBook just for his online coursework, that I want to see something like an iPad Pro succeed — and become what technology is for the majority of people.
With all the legacy software out there, the lack of financial incentive to rebuild it for a new platform, and iOS’s current limitations, I am hesitant to say that is going to happen anytime soon.

P.S. I wrote and published this on my 27” iMac with 32GB of RAM, a 1TB SSD, and a 4GB GPU.

“Despite Its Flaws . . .”


. . . I like Apple Music. It works for me.

. . . the Apple Watch is pretty neat. I wear it daily.

. . . the new Apple TV is pretty good.

This is how I’ve described Apple’s three new products released this year when asked. I like them, but I’m hesitant to recommend others buy them because of frustrating flaws or the absense of essential features.

If you ask me to describe my iPhone 6s Plus, iPad mini 4, or Retina 5K iMac, I have nothing but gushing praise. Admittedly, they are more mature products, but I’d also argue my review of the original iPhone and iPad was much more positive than my reviews of any “Version One” Apple has put out this year.

The original iPhone not only changed the industry, but it changed my life — from the first day. The original iPad showed me the future of computing. Even if I only use my iPad for watching video and reading, I use it for hours a day. And the iMac and OS X are so mature at this point, niggling bugs are really all I can complain about.

So what’s changed from those products to these new ones? I refuse to believe or use the “Steve Jobs” excuse. Apple is filled with brilliant people at all levels of the organizational chart. You don’t become the biggest corporation in the world being run by dummies.

I’d entertain the idea that Apple is stretching itself too thin. Despite being the biggest company in the world, they have gone from a single platform (OS X) to managing six (OS X, iOS, tvOS, watchOS, iCloud, and CarPlay). Apple has always struck me as a company that does more with less, but even this amount of annual innovation seems like an insane amount of work for one company to do without more than a few hiccups along the way.

My guess is our expectations for these products have grown exponentially from nearly a decade ago when Apple started really pressing the gas pedal on mobile and technology in general. The original iPhone was compared to a Blackberry or Nokia. The original iPad’s biggest competitor was a Windows PC Tablet. The only place I ever saw one of those was a university classroom.

Compare that to Apple Music, running up against Spotify, which is really damn good. The Apple TV is competing against Roku, TiVo, Xfinity X1, and a variety of other incumbents. I’m really not sure who or what the Apple Watch is competing against. FitBit? Android Wear? Omega?

When the bar is raised by existing competition, the flaws of a 1.0 product stick out far more than they did when you’re revolutionizing and changing a market that is either dormant or nonexistent. The piss-poor performance of apps on the Watch is hard to ignore. The clusterfuck of an interface that Apple Music has compared to Spotify is hard to justify. The lack of an update to the Remote app or Bluetooth Keyboard support on the Apple TV makes me curious how Apple prioritizes features; that truly seems like a glaring omission.

The Watch, Music, and TV products will continue to evolve over the next few years and see continued improvement, but I can’t deny I’m longing for the days of an original Apple product putting my jaw on the floor and giving me zero hesitation recommending it to others.

HTML5 Colorado — A Tribute to Alex King

In tribute to Alex King, this is a re-released version of his geeky & meta tee. The HTML5 canvas code on the shirt draws a Colorado state flag. We think of it as a celebration of an amazing person and one of his many great creations. See Alex model the original shirt himself.

I have the original blue shirt, and am wearing it today even. I’ve ordered a new one as well as a tribute to my friend. You might consider purchasing one too.

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.