Does the name Itty Bitty Apps ring a bell? No? What about Reveal? Itty Bitty Apps is the company behind Reveal. Reveal is a powerful view debugger for iOS and tvOS development. It's Xcode's built-in view debugger on steroids. It comes with a gorgeous user interface, powerful controls, and support of iOS, tvOS, and application extensions. It's a must-have for every Apple developer.
Earlier this year, I sat down with Sean Woodhouse, CEO of Itty Bitty Apps, to talk about software development, running a software business, and building developer tools for the Mac platform.
Mentioned in the Interview
Transcript
Bart I was not familiar with Itty Bitty Apps until I came across and started using Reveal. I'm curious to hear how the company got started.
Sean Yeah, sure. So, I guess going back many, many years, I actually started out, I left University in 1993. I happened to get a job with a company in Melbourne, that was doing NeXTSTEP development. I actually had a bit of a background in Objective-C, probably before most people knew what the language was.
I did that until about ’97, and then the company I was working for sort of moved over to Java and Enterprise Java products. That was around about the time that NeXT was acquired by Apple, and everything kind of went south there, for a while. Then, there were many years in between, of doing product development, product management, development management sort of roles.
I was working for a company in 2009, and had the opportunity, basically, to quit that company and basically come back and write an iPhone app for them. I had already sort of been talking to a friend about doing iPhone development on the side, and the guy I was working for at the time kind of got wind of that, and I thought maybe this was an opportunity for me to get some experience doing that commercially.
So, I did that. I quit my job, and basically contracted back to the company I had been a permanent employee of, and wrote their application, and basically, one job came after the next. Before I knew it, I was getting too many job inquiries, or work inquiries, and that allowed me to hire a few people. That kind of kept progressing to the point now, where I guess, almost eight years later, we’ve got around about eleven or twelve people in the company.
We’ve done a lot of iPhone app development consulting over those years. So yeah, very much so, Reveal is how we’re known internationally, quite often, but what a lot of people don’t know is actually Itty Bitty Apps is the company behind Reveal. We mainly do consulting, mostly in Melbourne, actually, in Australia.
Bart Do you focus exclusively on Apple platforms? Or do you also do, for example, Android and web development?
Sean We have really been known for doing iOS development and Mac development, in the past. We have just recently done our first Android project, I guess as a mobile consulting company, we really needed an Android story, partly because other consulting companies had capabilities in those areas, and if we didn’t sort of acquire them, then one could be cut, so to speak. Our clients typically would prefer to work with one vendor, to have both their Android and iOS apps developed.
While we’ve been able to get away with just doing iOS in the past, I think, moving forward, Android is definitely an important platform for the kind of clients that we do work for. So, we’ve started doing some Android development, and actually finding it very hard to find Android developers that have the same attention to detail that we’ve found iOS developers having, so that’s always a challenge.
Web development, not so much. We do sort of focus on native mobile development, but on Android and iOS.
Bart What I’m most interested in is Reveal, the developer tool Itty Bitty Apps creates and sells. That’s how I got to know Itty Bitty Apps. Like you mentioned, many people don’t know the company behind Reveal. Why and when did Reveal come into play? The first version was very polished, certainly not an MVP. And I'm curious to hear how Reveal got started and how you made sure that that first version was so polished.
Sean The origins of Reveal stem back to a conversation that I had with Oliver Jones, our Technical Director, back in 2011. In fact, I think we were on our way to WWDC, and for some reason, I forget why, but we were on the plane, and we were discussing, or lamenting the fact that games developers have quite a lot of tooling to help them.
Designers and developers kind of work together. Designers typically are able to modify things on the fly, and sort of see the impact of the changes dynamically. It kind of seemed to be silly that, with Objective-C, in this dynamic runtime, that we couldn’t do something similar for iOS developers, and also designers.
So, that kind of started the thinking around a product like Reveal. But also, around about that time, there were a couple of other tools sort of poking their heads out. There was a testing framework called Frank, and it had a web-based sort of hierarchy inspector. And there was another tool called DCIntrospect, which was actually developed by another Melbourne local.
DCIntrospect worked in app, so you could see the frame boundaries of your views, and you could kind of click on views and see their height and width, and things like that, and maybe even some properties. But what I found restrictive about those kinds of approaches was that there’s a lot of information in a view hierarchy, and just inspecting it within the constraints of an iPhone screen effectively, and also on top of the app, as it’s running, was a bit too restrictive, from my perspective. I felt like there was a lot of value to be had in a dedicated application, desktop application, that could inspect your running iOS application.
We started talking about those kind of ideas around June 2011, but it wasn’t until really early 2012 that we had an opportunity to have a first try at building something, like just a really rough start, just to sort of see whether the whole idea was even possible, to basically have a remote client connecting through and grabbing information from a view hierarchy. So, we tried that out, I think it was about January 2012, but we got really busy with consulting that year, so we didn’t really knuckle down until late 2012.
In fact, it wasn’t until June 2013 that we actually released the first public beta of Reveal. The initial idea was to go to WWDC and sort of show people a sneak peek of what we were going to come out with later in the year, but as it happened, and I’m not sure why this coincidence was going to happen in terms of timing, but there was another product that came out just before us, in fact, about a month and a half before, called Spark Inspector. That kind of shook us up a little bit, because we were working on this thing for well over a year and half, and all of a sudden something comes out that looked very similar.
Anything else that had come out before, we kind of dismissed, because it maybe wasn’t doing the 3D effect, and explosion of the view hierarchy, but Spark Inspector had some pretty neat tricks. Certainly, it looked like a potential threat to us. I think it was actually selling, as well, so they actually got it to market before us, but we felt like we had a better approach, and a better technology, and better team, basically, or a team behind it.
So, what we did was we made the public beta free, so that kind of basically sucked the oxygen out of the room for Spark Inspector, for a few months, until we were able to get the product commercially available, in October that year.
Bart You mentioned that you have a background in Mac development. What were some of the obstacles you and your team encountered to get the first version of Reveal out the door? You have a consulting business to run as well and I assume your team can’t work on full time on Reveal. Client projects are usually the top priority and, you know, side projects can suffer from that. What are some of the biggest obstacles that you needed to overcome to get that first version of Reveal in the hands of users?
Sean Yeah. I guess it was partly one of timing. As I said, we got quite busy in 2012, so we had to sort of shelve the idea for a while. And I should clarify that, although I have a NeXTSTEP development background, I did iOS development for a number of years, before starting to hire people. Reveal really is that kind of indie product, that I wanted to make myself, but in actual fact, started a consulting company in order to make a product like that.
I effectively got the team to build the app, so I actually don’t have, or haven’t had much of a hand in coding Reveal myself. I sort of have been product manager for quite a while, though, so I still sort of set direction and work with the team that’s still working on it. In terms of getting Reveal to market, there were a lot of challenges. One was that it took quite a while to even get the e-commerce support up, so that people could actually buy the product. I took us a couple of months to do that for version one.
I think it was a good thing that we actually got it to market, even as a free public beta, just to sort of drum up interest, and see how much people were actually willing to potentially buy the product, although we hadn’t announced pricing at that time, so it was always a bit of a question as to whether they would see the value in it, the same way that we did.
We were definitely sort of pitching Reveal as a premium product. I think, initially the price point was $89 U.S., for a personal license, and $179 for the commercial. So definitely, we were sort of pricing it that way. And that was partly why the initial version of Reveal was also sort of the pro, dark look. We wanted to give it a professional feeling, like Photoshop, or Adobe After Effects, or things like that. So, that very much sort of set the direction for the look and feel of the application.
In terms of getting it to market, also, I think one of the good things that we did was cut back the scope as much as we did. It’s always tempting to obviously throw in the next feature and the next feature, but inevitably, time and experience sort of keeps repeating this lesson to us. You know, every feature that you think is going to be a small addition tends to take three times as long as you think. So, any feature you can cut back, definitely increases your chances of shipping something. I think we did a pretty good job of that.
But also, we found those opportunities between client gigs, or in addition to client engagements, to actually give the team the time and the opportunity to work on the application. Without that, really, we wouldn’t have gotten anything to market. I think, as a business owner, as well, though, you’ve got to accept the fact that either you make that decision to focus on it, and effectively spend and invest money in it, or not, and focus on the consulting side of the business.
It’s interesting to see companies like Black Pixel and MartianCraft kind of take similar approaches. But I think it’s interesting to see, over the last few years, that even those companies have maybe found it difficult to keep updating their tools. Like Briefs, from MartianCraft, and Kaleidoscope and Versions, and those kind of tools. I haven’t seen as many updates to those tools as you might have expected from those kind of companies, and my hunch is that they’ve gotten busy with consulting.
Bart Hmmm. I’ve worked for a few agencies that also create products. But their primary business is consulting and it's indeed a trade-off you need to make, invest time in consulting or a product that may generate revenue in the future.
I'd like to shift gears for a moment and talk about the Mac, the Mac ecosystem in particular. From a business perspective, how do you feel about the current state of the Apple ecosystem?
I have the feeling Reveal is doing quite well. Is that your feeling as well in terms of sales? I’m not asking for any specifics, but do you see that Reveal is getting traction as a developer tool? You mentioned Reveal's price point earlier, for example. Is it hard to make a living selling applications for the Mac?
Sean That’s a really good question. Of course, it’s all relative, really, at the end of the day. Just to give a bit of context, I guess, when we first started selling Reveal, the price points were such that you pay your money, and you get all the updates until the next major version. Now, we didn’t actually release version 2 until September of last year, so that’s almost three years of free updates. When we went to version 2, we changed the pricing model to be what is becoming a lot more common now, which is you pay your money, and you get 12 months of updates. The product doesn’t stop working after that point, but you no longer get any feature updates. So, you still need to keep paying to get those updates.
But also, we adjusted the price a little bit, too, which I think I haven’t seen other companies do. Like Sketch, I think, kept their price the same. So, if you kind of factor in, let’s say for example, a 24-month upgrade cycle, typically, for the old model of pricing, then those products effectively doubled in price overnight. Which is, if you’re getting value out of those products, I think it’s well worth it, obviously. As professional software developers, we want to support those companies building those tools, and we understand the value proposition of spending a couple hundred dollars on a good tool, saving you time and making you more effective at what you do.
For us, as a consulting company, that directly affects our bottom line, in a positive sense. At the moment ... there's probably two, two and a half people working on Reveal, on and off. Sometimes there's been up to five. But really, Reveal could probably sustain one to two people commercially, by themselves. Now, if you’re a one or two-person sort of indie start-up, then I think that’s a very appealing proposition, really, to work on a product like Reveal, which is really well-known. We’ve got thousands of customers, and there’s a lot of credibility in that product.
But if you’re trying to run a 10-person team, or a 5-person team, then you’d really struggle. I think that’s the reality of the software business, particularly for the kind of market that we’re in. You can look at companies like JetBrains and say, obviously, they support a lot of people in that company, and they’re in development tools, as well, but they’re basing their product on over ten years’ worth of development of IDEs on other platforms, so they get a little leverage out of that.
I guess we always sort of felt that building a native Mac app, and making it as seamless as possible, for Mac developers, or people who are used to using Macs, was a way to differentiate ourselves from the market, in a market where, quite often, developer tools don’t get the polish and attention that they deserve. Somebody throws something together on the weekend, and they decide to use some godawful cross platform Java toolkit, or something like that, and we felt that, as professional developers, that we deserve something better, and something more native, and thought that other people would appreciate that, as well.
I think that’s kind of borne out, but at the end of the day, when you’re running a business, basically, you want to spend less than what you make, right? So, in any business like that, choose a product that isn’t going to require more investment of your time and money, than what you’re going to make out of it.
Bart Yeah. That makes a lot of sense. I'd like to talk about getting traction for a moment. How is Reveal doing in terms of getting traction as a developer tool? And do you invest in marketing to promote Reveal to the developer community? Or do you think it’s mainly word of mouth that is driving sales?
Sean That’s a really good question. We have sponsored a lot of conferences, developer conferences, in the past. We’ve sponsored CocoaConf around the U.S., we’ve sponsored a lot of different kind of developer-focused conferences, and also iOS Dev Weekly, we’ve advertised in there a couple of times. Dave's a good friend.
We go to a lot of conferences as well, so quite a lot of people might have met me at WWDC, or NSConference, when it was on. I went to try! Swift last year, in Japan, and we recently had a conference in Melbourne called Playgrounds, which had quite a lot of the circuit speakers there. So, we get around a little bit. Definitely, there’s a bit of word of mouth aspect to it.
We have been trying to do things, maybe not direct marketing, but sort of following up on people who download Reveal for trial. So, if you download Reveal, and you haven’t activated it, or you haven’t actually purchased the product, we’ll now send you an email to say “Hey, just wondering how your trial is going. If you have a minute, can you please give us some feedback by filling out this survey?” We never used to do that stuff, and if just takes a little while to set up, and get all that stuff up and running. But it’s invaluable, I think, to reach out to those people who are potentially customers. They have indicated that they have some interest there, so why not spend a bit more time to follow up with them, and try and close the deal, so to speak?
I think that’s where we’ve been spending a bit more time recently, trying to do that, rather than sort of sponsor conferences. We’ve basically sort of backed off a little bit from conference sponsorship, because we’ve done a lot of it, and I guess my feeling is you’re only going to reach 200 to 300 people at a conference. Even then, quite often, people just pass the banners and might have a cursory glance at the logos on the banner. I guess there’s a hope that they might see that logo and then come back to it and go “Oh! That’s what that was all about!”
But quite honestly, I guess, in the developer community, we do expect that there is some word of mouth between developers, as they go from gig to gig, or from company to company, and they sort of bring their toolset with them, and kind of pollinate that way. So, people go “Oh, that tool, that was awesome! Show me how to use it.” We find that images thing like Charles and Git Tower, and whatever tools people have in their tool belt, that tends to get around.
And inevitably, when a new tool comes out, quite often there will be a lot of buzz around, “Oh, there’s a new design tool!” It seems like there’s a new design tool every second week, these days, so that gets around pretty quickly, around the community.
Bart What are the challenges right now? I feel you have a pretty mature product. You're adding new features with every release. What are the challenges of a product that's already on the market. It's proven to be viable as a product to invest in. What are the challenges at this stage of the product's life cycle?
Sean Yeah, there’s no real shortage of ideas for features for Reveal. What you see in version 2 is probably what I wanted to ship in version 1. In version 1, we didn’t have constraint inspection, and we’ve only just added the ability to show errors and warnings for constraints in Reveal, and they're so useful, it’s not funny. We wanted that from day one, and that was just one of the things that was like “Yeah, we’ll get to it. We’ll get to it.”
But in terms of challenges going forward, obviously, when you have an existing code base, just refactoring things, just getting things cleaned up, and to a state where you can actually go ahead and build the next feature. That’s always a challenge, to carry that forward. Quite often, if you don’t keep paying down your technical debt, you can become sort of swamped with it, and you just can’t move forward.
We’ve seen that, not with our own products, but with clients that we consult to, that sometimes they just can’t get stuff out the door quick enough. Like you mentioned, for version 2, we really consciously made an effort to try and do releases more often, and we had, in the past, gotten stuck in that rut of “Oh, we’ve got to add that feature, and that means all these other things.” And before you know it, it’s a year before you’ve shipped another version of the product.
I think it should give people a little bit more confidence that we’re actively supporting Reveal, and we will continue to do so, when they see releases coming out every six weeks or so, and with some reasonably significant features. We’ve added filtering, as well, which lets you kind of filter the hierarchy, by all the different types of properties, and the canvas kind of shows you very clearly, what things have matched. So, there’s a lot of work that goes into all that stuff, but we are trying to do it on a more regular cadence.
The challenge going forward, I guess, is to do the big changes, as well as doing the small ones. So yes, we want to do some big feature additions to Reveal, but we don’t want to pause our releases for six months. So, that’s a challenge. Also, just as we get busy with consulting, just keeping the focus, keeping dedicated people on Reveal, is often a challenge as well.
We’ve kind of mitigated that a little bit by having one of our main developers working on Reveal, that works remotely, from Newcastle, which is the same time zone as us, but just remote from our office. So, Tony Arnold works on Reveal, and he’s pretty much dedicated to that full time, well, three days a week. And we have some other developers in Melbourne, also working on it, when they get a chance.
Bart The last question I have may be the most obvious one. Apple, as they say in Mac parlance, Sherlocked Reveal a few years ago. They didn't do a great job in my opinion. What I heard from other developers who got Sherlocked, sometimes it’s the end of the story, but sometimes it can be a real blessing. I remember Marco Arment talking about this. The introduction of Reading List resulted in a big boost of Instapaper sales, because people became aware of the need for such a tool. How did you experience the addition of the view debugger in, I think it was Xcode 7?
Sean Yeah. It was certainly a kick in the guts. I won’t [inaudible] that. But as you mentioned, I guess I’d be more worried if they did a good job of it. When we saw what they had done, and the approach that they had taken, we realized pretty quickly that we were a lot further along than they already were, and we had a focus on the UI and the UX, and just the whole experience that Apple will never apply to Xcode. They have enough trouble just keeping the basics working in Xcode, at the moment.
Also, Xcode has become this kitchen sink of tools and utilities. Like, it’s got a [inaudible] now, and all these other things in there. Reveal can actually be quite tailored to the task, just even in terms of menu shortcuts and those kinds of things, whereas Xcode, because it’s got so many features, the keyboard shortcut commands, there aren’t very many of them, if any at all, I think, for view debugging, because they’re all taken up by other features of the application.
So, Reveal can actually be quite a lot more streamlined. And, as I said, we’ve got a focus just on this area, whereas obviously, Apple have a lot of things to deal with in Xcode. So, I think it’s kind of proven out, over the years, that there still is a viable market to compete against Apple. We know that we need to stay sort of one step ahead, but when you think about this market, as well, we knew that there was always going to be free alternatives to Reveal. We didn’t quite know that Apple was going to get in the market, but understand from day one, that there was always going to be competition.
Whether it’s Apple or somebody else, you’ve got to know what your value proposition is going to be, compared to them. You look at things like Kaleidoscope and FileMerge. FileMerge is free, always has been, and Kaleidoscope is a commercial product. Git Tower and the graphical Git clients, or you could use the Git command line, or Xcode and AppCode. There’s a commercial product there, that competes with Apple’s free offering. So, yeah, you’ve just got to really understand why would people want to use your product.
I guess the frustrating thing is, when you see those people who look at two screen shots of Reveal and Xcode and they’re “Oh, well they’re the same,” when I know that if people sat down and used the tools actually [inaudible], they would realize very quickly that there’s a very big difference between the two. Just the attention to detail, simple things like being able to expand and collapse the view hierarchy, both in the outline and in the canvas. So, when you collapse nodes in the left hand outline view, they’ll collapse in the 3D canvas, as well, which lets you kind of see your view hierarchy at a level of detail that makes sense, rather than seeing everything exploded out.
I know Apple introduced the little sliders to kind of try and occlude views in the front and the back of the view that you’re looking at, but I don’t think that’s as nice an approach, to what we’ve done with Reveal. There’s like a million other features that I think Reveal does better, but really, it’s up to the end user. For a lot of people, maybe what Xcode provides is enough, and I’m not ashamed, and I’m quite happy to be a premium product, with premium features. I think that’s a good place to be, rather than competing on price and features.
Bart Absolutely. I couldn’t agree more. Sean, thanks so much for your time. I wish you all the best with Reveal and with Itty Bitty Apps, and, to be honest, I look forward to the next release of Reveal.
Sean Excellent! I hope we can surprise you.
Bart No doubt. Take care.
Sean Cheers!
Bart I hope you enjoyed my conversation with Sean Woodhouse of Itty Bitty Apps. If you're an Apple developer, then I encourage you to check out Reveal at revealapp.com and download the trial version of Reveal. You can follow Sean Woodhouse on Twitter at @seanwoodhouse and you can learn more about Itty Bitty Apps at ittybittyapps.com. Thank you for listening.
