The panelists talk to Oliver Guests about the internals of Reveal.

 

Hey everybody and welcome to episode 66 of the iPhreaks Show. This week on our panel we have Alondo Brewington.

Hello, from North Carolina.

Pete Hodgson.

Hello, from Alamo Square.

I’m Jaim Zuber from DevChat – wait, no, that’s not me. [Laughter] Our guest today is Oliver Jones. Oliver, can you tell us something about yourself?

I’m a Kiwi and I'm based in Melbourne and I’m the technical director of Itty Bitty Apps. We make iOS development tool called Reveal, amongst other things.

That is very cool. This is our second week in a row we’ve had an Aussie guest. So next week, we’re going to go for the Aussie turkey, if we can pull it off.

You can’t call a Kiwi an Aussie. You get – [Crosstalk]

Oh. He’s living in Australia. Ok, I think we will – [Crosstalk]

I’m almost an Aussie. I’ve been here for ten years, or maybe ten years, so I’m considering becoming a citizen, so I’ll be an adopted Aussie at some point.

He’s on defense. Ok.

But I’ll never give up my support for the All Blacks.

I know what you’re talking about.

Well, we brought you on the show today to talk about Reveal. Can you tell us a little bit more about that?

Yeah, sure. Reveal, for anyone who hasn’t spotted it yet, is a development tool for iOS devs. It’s a view introspection and debugging tool. I kind of explain it to people as the iOS equivalent of Chrome Inspector or Firebug. You can drop a library in your application, or throw some extra wizardry in XCode, set up breakpoints to inject the library dynamically, and then you can connect your app using Macintosh desktop app and see the insides of your view hierarchy and expand your app and view all the attributes and tweak them and change things and see how your app reacts to those changes.

This is a very different approach from how I’ve done this in the past. Usually, we hire a shaman. They come in and burn incense and things, so we all do a dance, and that tells us what we need to know. But this seems like a more reasonable approach. [Chuckles]

Yeah, yeah. Reveal is kind of a self-service shaman. It’s called Reveal to reveal the insides of your app, so it’s like a – we can look deep inside your app and give it a good poke around and potentially, hopefully, find the bug or problem that you are trying to discover and eradicate.

It’s very addictive watching this video. So, I’m on the Reveal app homepage and you can see the little video on the homepage. If you’re kind of cruising through an application, then it’s very addictive. It just looks really cool. It looks like super fine. I can imagine getting lost in my application for a while.

Oliver, I’m really curious because I’ve used Reveal and I really like it. And I was curious of the history behind the development of the tool. At what point did you hit some sort of frustration and decide, ‘well, this will be a great thing to do’, either in-house, and then subsequently deciding to release it to other people.

Right. Reveal was first postulated between myself and the director of Itty Bitty Apps, Sean Woodhouse. When we were on United Flights WW in 2011 - was it 2011? Or 2010 – I forget exactly when. We were just talking about problems and iOS development and tooling and prior to us doing iOS development. I was involved in the video game industry on the tool side, so I worked in an Australian studio developing content creation tools for level designers. I was just potentially discussing this sort of tools with Sean and how in some respects, games aren’t made by games programmers; games programmers are definitely involved, particularly engine programmers and games programmers, but most of the video games you see in the world today in general, are predominantly created by designers and artists. However, on the iOS side of things, it’s very heavy on programming. The designers hand over your screens and with screen designs, and then your code makes it look like the screen design in the PSD or whatever they’ve been given. And that's quite entirely backwards to other content-heavy industries or design-heavy industries from movies to games development where it’s predominantly content creators. I guess Reveal started off as a much broader and bigger idea and more designed-focused idea and sort of got NVP down to the bare minimum of what we thought would be useful, which is more introspection and real-time twiddling to see changes in real-time, and give the developer feedback so that they can walk quickly address on solving problems or tweaking the visual layout. That was really the genesis of it. We just kind of put up – like Itty Bitty Apps is not just an app development company, we do consulting as I was showing you guys earlier. I was working with your last week’s guest, I worked with your last week's guest, Stu Gleadow, on a consultant contractor. Our business is sort of half and half product development and consulting. For a long time, Reveal kind of gotten backed up because there wasn’t enough resources to develop it as all of them were consulting, but as resources became available, we started developing Reveal as a product. That really happened last, not last WW, but the WW before. We sort of started in earnest about 6 months or 9 months before that to prototype and start the development of Reveal, and then it was announced and put it into beta. So just before WW 2013, and then put on sale for the 1.0 release in October of that year.

If definitely looks like a lot of love have gone into Reveal. A lot of hours have been put into the way that all of the layout starts from the right hand side is –. You haven’t just got a list of things that you can edit, it’s all – it feels like a design tool that you could use to do design. I think you were saying that’s kind of in the NVP that got squeezed out a little bit. But do you see people – Are there Reveal uses today that designers are using it to tweak designs and collaborate with devs or is it mainly devs using it to debug things, or a bit of both maybe?

I think probably our main user base is developers. I don’t know of too many designers. We're certainly put in front of designers and designers have contributed to the app. It’s funny you say that we’ve kind of designed the inspection panels and stuff. I think that’s probably one area where we’re improving the app the most in the next upcoming edition, sort of a 1.1 release coming soon, because the current one is a little bit un-designed.  It’s more of the alphabetical list of properties, but there’s definitely a lot of blood, sweat and tears that got into Reveal and a whole lot of swearing, as well. It’s the swearing product development, mainly because App Kit is –. We were predominantly iOS developers and this is kind of our first app for the Mac, so our first App Kit application and App Kit is not UI Kit and customizing it is a real bitch. So we specifically put a lot of effort into trying to make the app attractive one and look professional and not just something we throw over the fence. There’s definitely a lot of pain and effort going into that. And also just trying to figure out what the best experience was. We do a lot of prototyping internally and testing and trying to figure out how to user interactions for zooming in on particular components and being able to navigate around your view hierarchy, and so on; how it all works. There’s definitely a lot of sort of trial and error in that area.

What are some other common used cases that people are using Reveal for?

Well, a lot of the time it’s like ‘where’s my view? Why can’t I see my view that’s – I put a button in the app and I can’t see it’. Like ‘why is it not there?’ If your app is built to include Reveal bug builds or something, or you have some of the scripts and things we’ve posted on our blog about how to integrate it with XCode without linking it to your app. If you could just fire up Reveal, connect it to your app, hit refresh or whatever, and navigate to that part of the view hierarchy, spot the view that’s zero pixel size or whatever, and then you’re like, ‘ah, that’s right. I’ve got a size to fit my custom UI view inside my UI tab before it’ll show up or something’. It’s solving those little head scratches you have on a daily basis. Or maybe you’re trying to figure out, ‘why is my app slow?’ and then you load up Reveal and you are like, ‘ah, shit I’ve got over these hidden views and my –’, or probably just views off-screen or accidentally adding a view over and over and over and over again to the view hierarchy and just staying on top from ‘I can’t see it because in 2D, it just looks like it would normally’. Those sorts of things, we constantly see in the people who tweak that sorts of thing. We constantly see you know people who tweet that sort of thing, you know? More or less, Reveal saved me an hour today just instantly or trying to figure out what some little bug was. So that’s definitely the sort of predominant used case. I think there are other people, I mean myself included, who just want to just tweak something or go and say, ‘ok, what do the content insets of this particular button need to be to align the image and the label together. Your button has a whole bunch of sets and insets and you just want to be able to twiddle with them a little bit to just line something up and write down the numbers and then go back to your code and type the numbers into some part of code or something like that – that sort of things. Probably the biggest feature we’re introducing in 1.1, which is coming soon, is layouts inspection. We’ve got visualization of all constrains and what-have-you. So people who are on the beta there are happily discovering all sorts of craziness with the UI layout constraints and so on.

Is that going to have full editing capability, as well, for the app?

Not full editing. You’ll be able to tweak a constant, because that’s the only variable that you can tweak on an NS layer constraint. Unfortunately, layout constraints in order layout on Mac and iOS are pretty much immutable; once they’re constructed, you can’t do anything else with them. You can additional constraints, you can remove constraints, but we don’t expose it solely in Reveal. You can just explore your existing constraints and you can tweak constants to move things around. If your constraints are set up in a way that change the constant value, moves things around, then your views moving around every layout, so it’s definitely tweak-able but it’s not a full editing, like IB style editing. [Crosstalk]

Go ahead, Jaim.

It talks a little bit how to layout. I’m just trying to imagine the classic way of debugging your views. A lot times, you’re into your LLDB console printing out list of some views, trying to cache your CGRect to make sure you see the frames – things like that. It’s a real pain, but it sounds like Reveal is a much improved way of going through that that, trying to figure out what’s actually happening, especially if you’re building up your view hierarchy and encode or doing it dynamically. You got a bunch of things happening that you don’t know. It’s hard to trace through what’s happened if it doesn’t come out right. Is that sound about right?

Yeah. If you’re not using IB – a bit of history that some of the projects that Itty Bitty Apps has worked on are pretty old code bases. Like some of the companies that we worked with or has apps in the App Store pretty much almost since day one or close to. So we’ve been working on code that’s involved from iOS 3. Back then, a lot of people went to – to this day even, a lot of developers code first, right? They prefer to use code to create the hierarchies and so on. When you do that, often you create a lot of subclasses, a lot of UI view subclasses, and then a very complicated app where an code based often  it’s kind of difficult to know where this particular piece of UI come from, and if you say, for example, your product manager comes to you and says, ‘hey, we need to tweak this thing or whatever’, you can load up Reveal and inspect your view hierarchy with that piece of UI on screen; look at it, click on it, see it on outline view, all that’s my custom layout view something, or rather, it gives you the class name to go looking and change it. So it’s definitely sort of code-oriented inspection could be helpful in that way and in some respects discovering a code base or discovering a user interface that you’re not familiar with, like how the code is putting it together.

It’s interesting you say you could see the end result of what happened after kind of all the initializations, because I ran into a lot of older apps that definitely were designed to develop during – using the code first thing. So you’re building up all these different views and it’s nice to be able to see the end result and trace backwards to see what the actual method calls and subclasses are doing. That’s very cool. That could save me some time.

Yeah, it’s definitely useful for doing that sort of stuff. It’s not quite as useful when you’re, I mean, using custom UI view subclasses that can be really useful to identify like where something comes from. It’s a little bit more difficult when you’re just using a stack of standard controls, but it is definitely like a – especially if you’re not using IB or you are using a mix of IB in code to see the final result. Like, ‘okay, that’s what happens after I load a view and this is the structure of the user interface’. It’s definitely a good sort of discovery tool when you’re using code base so you see like some of the consultants, they both come on and off a project, and project will change so that will – as a sort of learning process when I go on to a particular card or something to implement feature that will load up Reveal, have a look at the state of the user interface. and sort of say, ‘okay, that sub-view’. It’s kind of like a cool user interface discovery tool.

I want to ask a little bit about this feature of Reveal that was announced I guess fairly recently, but I think is really neat, is the app code integration, I guess. Well, first tell us about the app code integration.

Well, the guys at JetBrains know me in some respects, because I’m a pretty vocal advocate of AppCode and I’ve done CodeHeads talks on those subjects and repeatedly ranted about XCode and provided an AppCode on Twitter. So they approached us, basically, with an interest in integrating with Reveal. They did all the hard work, really, because we’re not Java coders, they have a Java-based idea, and so they implemented the plugin side of things and figured out how to get it working on the other end, and all we had to do is kind of make their job easier. That’s what I did actually. The way it works is, I mean the plugin is open-source so you can have a look at it on Github repository. So basically, it’s just a residue. The first thing it does is it basically launches your app and it finds out if you install Reveal and you’ve turned on the integration and your projects settings. When you launch your application, it will automatically inject our dynamic library. We ship a dialog, which is sort of fat binary that works on both iOS and on certain devices and on the simulator. They just automatically inject that, and it’s very easy on the simulator. You can just do it with some environment variables, sort of just load the library, and found that devices are a little bit more difficult. The dialogue has to be code-signed. And it also has to then be injected using debugger commands but echoed basically sort of scripts that process of uploading the binary on the device or injecting in simulator, and so on, and doing the code-sign based on your credentials that are configured in the project. And then the final step of the process is basically to tell Reveal, ‘hey, you should go looking for an application with this bundle identifier on the network or on the Loopback for simulator. All we did for Reveal to support that was – in the last release of Reveal 1.0.4, we added some simple AppleScript support. Using AppleScript command, you can just essentially say, ‘hey Reveal, go refresh this host name’. We’ve been looking for this Apple, sorry, this bundle identifier, and it tries to use Bonjour. Reveal uses Bonjour to advertise applications that are running on devices or on simulator. It essentially just sort waits for the Bonjour to resolve what the particular application and then initiates a refresh immediately. It’s kind of a simple process; it’s not perfect, it’s not completely fault tolerant, but there’s a few issues of like time-outs and things that can happen, but in the ninety percent case, it works pretty well.

When I first saw this, what I thought was really impressive is – and I think you’re being very modest in saying it’s kind of pretty simple stuff, but maybe for some developers, this isn’t the stuff that they know about day to day, but I think the thing that really surprised me that you can even do it is injecting code dynamically into a running application on the device, because there’s supposed to be all of the security things and various other things, but I guess the secret is in the code signing, it sounds like.

Yeah, the code signing is important for the device sort of thing. I’m pretty sure, yeah, it only works when your app is attached to the debugger. I don’t think you can do it, at least on iOS 7 anyway and below, I don’t think you can deal load or deal open a dialogue if you’re not connected to the debugger. I’m not hundred percent sure on that, although I point out that Reveal is not the product of a single man’s brain; it’s been a real team effort. And what I certainly was sort of leading development for the majority 1.0, my main focus was on the user interface, in particular, the sub AppKit, sort of all of the widgets and UI controls and the theming and everything, and on the actual library side of the catching of information, another major contributor we wouldn’t be able to do Reveal without him is Chris Miles. He did a lot of work on the 3D of visualization which is a WOW Feature. He also did quite a little bit of the low-level experimentation and prototyping for things like dynamic loading of your library and also image capturing text. Yeah, it’s been real collaboration, and now even more so, if you go check out the About screen in the app, it’s got quite a list of developers and designers. We’ve had a lot of help in small and large ways from over a hundred different people, our employees and other third parties.

You mentioned the screen caching tech. Do you want to go into a little bit of the detail of how that magic works? Or I guess maybe not – obviously it’s not – I’m assuming it’s not actual magic, but how do you get all of these little bits of UI out of the application? Actually, I mean actually, to start with how does the running application even talk to Reveal? Is it running a little HTTP server in there, or is it some other...?

Yeah. We went with the simplest and dumbest thing that works and that was –. Yeah, we set up a little HTTP server, and we’re just using CocoaHTTPServer, and GCDAsyncSocket under the hood. It’s just kind of a little RESTful APIs  that splits JSON over the wire, and that was truly the dumbest thing that would work – well, the simplest thing that would work at a time. We’ve probably outgrown it. It’s becoming a bottleneck as applications are growing complex, particular iPad apps. The fact that we’re serializing JSON or very large trunks of JSON, that is becoming a problem. So I imagine for 2.0 that we’d move away from that style of networking. But it does make debugging and figuring out the command line pretty easy. It's sort of moving away from that would be – that’s going to make solving some of the network support issues maybe, but harder.

So would you go to proto buffers or something like that?

We haven’t decided yet. We’ve done some experimentation, but it’s sort of a thing to happen in the future, but yeah proto buffers definitely high up on the list of considerations. We may end up just being a custom binary serialization, but I doubt very much that it will remain a request response, sort of HTTP-style API.

Okay. So conceptually, you’re linking in your iOS app kind of a HTTP client that is speeding up data to the server, which is running in Reveal. Does that sound about right?

Yeah. It’s actually the other way around. The device runs the server and Reveal is the client. So basically, it starts as your app starts a little server, advertises it by Bonjour, and then Reveal discovers that, and then can connect to and request data.

And so when Reveal – the client, as the client here, will the Reveal application wants to display the view hierarchy? Is it just downloading? Is that all in JSON? Or I guess the images can’t be in

JSON?

Yes. It hits a particular REST URL, and makes it to get request for the application state, and we serialize – we walk the starting a UI application. We walk down the object graph serializing all of the attributes that we were interested in into a data structure. And then convert - use NS gestures to basically to turn that into JSON and spit it out over the socket. For optimization, we do a little bit of compression and a few other things, but that’s essentially the main blob of data that Reveal consumes, and then the given information in the JSON as we decode it, we’ve then go back to the Reveal server running on the device simulator, and ask it for images corresponding to view some layers. It’s sort of a two-stage process. It can lead to sliding consistencies, which is a little bit –. It annoys me and probably no one notices, but if you capture like mid-animation or something, your view state will differ from maybe the view image – stuff like that. We’re capturing multiple images for review, because we need a composited view and also a un-composited view to do the 3D visualization properly. We’re grabbing a whole swag of data on iPad apps over WIFI can get really slow sometimes, which is, again, one of the things we want to correct in the 2.0; to make it faster, make it more consistent, make it – just make it better. 2.0 is always to make it better.

That’s cool. Maybe, can you talk to us a little bit about the process for putting this in you app. You talked a little bit of linking in for a debug-only. Is that how you recommend doing this?

Yeah. Well that’s a kind of when load up Reveal for the first time, we kind of have a Getting Started window and we link to or encourage people to Getting Started Guide. The Getting Started Guide basically talks about going to the Help Menu and showing the framework’s directory from inside the app bundle, and you can drag and drop the framework, we sort of static library framework that we package up with Reveal. You just drag and drop that into your application, and you can then tweak a couple of link variables or link options and the way you go. And that’s kind of, we thought, the simplest way to get people up and running, but ironically people still have problems with just getting it to work with that particular set of dependencies or what-have-you, sometimes adding the link corruptions, we suggest people add Reveal’s problems in their project, their own linker problems like they are double linking to a Facebook API or something. It’s been a support problem. So as we ourselves become more adept at figuring out ways of linking or getting our library into applications, we've published blog posts and details about how to do it in different ways. So we always shipped a dialog, as well as a static library framework, mainly because Chris Miles, who I mentioned earlier, he started doing it in debug. He started injecting the library to help him speed up his own testing process, and we thought that was pretty cool, but we never really published it as kind of –. Initially, anyway, we never made it an official way of doing it, but since then, we published some articles in our blog that kind of describes how to do it. Maybe in 1.1, we’ll be making it more of the official way of integrating and in the documentation. We’re certainly calling it out as being a sort of better technique, because you just do it with like a – you can just add some debugger commands to a debug breakpoint in XCode, and just it will load up your library pretty much. Even simpler, you can now just add a scheme environment variable. If you just chuck in deal load or doyd_insert_libraries or something – I don’t know. I wrote a blog post about how to do it. It becomes trivial then. It’s just like change schemes, like you can make it – you could duplicate a scheme, add that environment variable to that scheme and then just switch your schemes and hit run and the libraries are autoloaded into your app via the dynamic loader, if you’re running in simulator. It does restrict you to just using the simulator. It’s a little more complicated to do the dynamic link loading on device, but that requires you to –. In XCode, if you’re not using AppCode, that does it all automatically for you. In XCode, you have to basically add the dialog as a resource. It copies the dialog into your resource bundle or into the resources of your app, and then you can trigger a breakpoint command to execute the deal open on a system call to open it up, then it will be injected at run time. If you’re just using a simulator, I mean personally, I run the simulator like 90% of the time when I’m doing app developments. So that’s only on these rare occasions that I need to actually see something on device, especially in a view code. Obviously, devices are really important if you’re doing devicespecific things like motion and stuff. But for UI inspection, it’s simulator all the way most of the time.

Yeah. I can imagine if you’re debugging your UI, then you’re probably like flipping around between different sizes of iPhone or different iPad things and not plugging in and plugging out different devices, right? So it makes sense that you’d be doing most of that in a simulator anyway.

Yeah. And it’s definitely kind of the majority use case.

I can definitely empathize with the trying to figure out how to make it easy to get this stuff integrated into XCode. So I’m like the – I created this open-source library that does testautomation. And again, it needs to be linked into people’s applications. I’ve gone through multiple, multiple iterations of trying to make it easy for people to get started with it, because it’s also – it’s their first experience of the product, right? It’s trying to get it in their application, and if that first experience is less than friction-free, then the odds of them just giving up and deciding not to use it is pretty high. I’ve tried all sorts of things to try to make it easier.

Yeah. We have that same issue. Reveal’s a commercial product. We’re asking for people’s money, and if we don’t make it super simple for them to get up running their application, they’re less likely to pay for it.

Is it a CocoaPods integration?

Yeah. We do, actually. We provide CocoaPods integrations, as well. That makes it a bit simpler to do the static linking approach. You just add the CocoaPods to your pod file and it should just work, fingers crossed. Linking... Developments are never perfect, right? So even when you try and make it so simple or fool-proof, there’s always going to be that special case someone’s got something slightly different.

Yeah, I’m not surprised you have trouble onboarding people. I think the – just by experience, I think the typical way people get their XCode projects set up is to have their sales teams right on making bills settings all compiles. [Chuckles] Just by experience. I have no other explanation for how these bill settings come about.

Yeah, I'd give people more credit than that, but, yeah, it is a tricky thing. The other thing is that there’s so many developers have different experiences. I mean, I’ve been doing some C-oriented development for iOS for the last five years, or prior to that maybe ten years. You kind of learn these things. You're used to it. There’s a lot of people who have come to iOS as new programmers, or from web technology and stuff and not used to this sort of idiosyncrasies of old C style we know linking and all the rest of it. Something throws up a spinner in the works, and then, you know, the day's ruined because they don’t really know how to deal with it. Or it’s a furious amount of Googling and stack overflowing. It’s just such a broad array of developers out there that you have to try and make it as easy for everyone. The experienced developers appreciate that, as well, because you’re saving them time, because they can just throw it in and it works. If I do have a minor problem, they can probably solve it really quickly themselves, but other less experienced or less familiar developers can be a bit of a problem.

I learned a new phrase over the weekend. I am full stack overflow developer. [Laughter]

That’s really good.

That’s all of us, I think.

I think it’s the real full stack overflow developers that are just like – something doesn’t work in XCode, they keep following stack overflow answers until it works, and then rinse and repeat, and then eventually they’ve got one of those XCode configurations that you see, Jaim, where like it’s 14 different schemes and they all have different – I don’t know, whatever. It’s a big old mess and they try to add an extra thing it’s even worse, and it just goes downhill.

Beware of the stack overflow responses from ‘09.

Yeah. That’s the other thing as well, right? Something that was totally relevant with XCode 4.2 isn’t necessarily going to help you today.

Absolutely.

I cop to being a stack overflow developer. I mean I’ve been doing this for a long time, but even today, I was doing something with Core Data, and I’m like, ‘ahh, I’m not too familiar with this API’. I could read the documentation or I could just type some key words into Google, [chuckles] and probably have the answer in about 30 seconds, like Google’s indexing stack overflows treasure trove of solutions. It’s too tempting.

I think it’s a quite depressing that now I’ve got to the point that I'm finally answering stack overflow totally - or I find the question, don’t even bother reading the question; just scroll down to the toprated answer; and don’t even bother reading the answer; just look for some code and just copy and paste it and see what will happen. I’m a professional.

I think the main value of experience in this industry is become – realizing when the stack overflow answer isn’t the right one – if you can say ‘this is the wrong way to do it’.

Yeah, definitely.

I have a random question about – I was being at this year’s WWDC and hearing the announcement of XCode 6 with the debugging being included, what that means for Reveal? Does that impact your plans for the product moving forward at all, or what?

It does a little bit, obviously. The worst five minutes of a Key Note for us. But after a while of this sort of frustration of like, 'Oh great! An element of our product has been sherlocked by Apple,' we sort of went, 'Wait, no, wait a minute, our vision for what Reveal is greater than this. It’s like it’s not – view debugging is just one aspect of things. And yes, that’s our MVP and that’s what we put in 1.0 and Apple was obviously validating that this is actually a useful thing to have. Unfortunately for us, Apple 1.0 – Apple’s general history with 1.0 products is kind of a bit rubbish. And to be honest, it’s the case in view debugging in XCode 6, at least the current beta, it’s a bit rubbish. Actually Apple will improve it, and it’s probably loads of radars being fired about it and now, it’s just a question for us like how good do they make the 1.0 that the view debugging that they shipped with XCode 6. At this current stage, for certain aspects of the process, Reveal is better for other things at the moment. XCode’s integration has some features that we don’t. At the moment, you can see constraints and so forth. You can also inspect [inaudible], which you can’t do with Reveal in terms of iOS only. So yeah, so it’s given us a bit of a shot at the bum saying get on with it. Make Reveal the kickass uber inspector that you have in your heads on the product backlog, you know? So it’s definitely given us a bit of an injection of, I don't know, urgency, maybe – I don’t know is urgency is the right word, but it’s definitely made us not complacent. We’ve got to show people why they need to spend their 80 bucks for personal lessons. People still are paying even with XScripts, people are still spending 80 bucks. That’s the least validation for us to know that we’re doing something worthwhile; that people are still interested in the product even with AppCode – sorry, with XCode coming along with essentially competing feature. But, no – Reveal is just really what we’re doing at the moment is really the tip of the iceberg for us in our product vision. So we can go on all sorts of different directions, and make this sort of one of the premier debugging tools for iOS devs.

Sean’s got a really good blog post on the Itty Bitty Apps blog. It says a lot about that stuff – it’s kind of game on post. I think it’s a good reaction to being Sherlocked. It’s the only positive reaction you can have to being Sherlocked, just like ‘thank you for validating that what we’re doing is good. We can be better than you’.

Yeah. At least, it’s like we know developers have been Sherlocked to the extent where Apple has made their products impossible by changing APIs or adding features or changing the nature of the Mac OS operating system. We’re not in that sort of situation, and we definitely think Reveal has many advantages over view debugging, that’s built into XCode. So yeah, Sean’s post is really great. It’s just like, ‘yeah, game on. Fair enough. Watch out for version 2’. [Crosstalk]

If you’re just trying to stay ahead of Apple’s developer tools, I think you can make  a reasonable business case out of that. That what JetBrains does.

Exactly, yeah. It’s not a – people will say, ‘Ah, it’s impossible to compete with free’. I’ve tried Wil Shipley actually was having a chat with Sean on Twitter about it saying I’ve tried that - I think it was a reference to Omniweb, but yeah, a company like JetBrains is sort of proof of the pudding right. They're essentially competing with a free product – XCode. XCode’s pretty good. It’s certainly all you need to do iOS dev, but there are some features in AppCode that I, personally, as a developer wouldn’t want to live without. I’m pretty happy to pay the hundred bucks or hundred plus fifty a year that it cost me to maintain a subscription to AppKit. And I get that for the benefit of – as a benefit of that, I enjoy getting awesome features of their product. I also get a direct line to their developers through their bug-reporting tool and features, so I can request features, I can really communicate. As a small, independent software developer, you can be – you’re much more attentive to your consumers or your customers. If you’re like you got almost personal relationship with them, like when you file a support request for AppCode, you’re getting the developer’s who work on the features responding to you. It’s the same as at Reveal when you file a bug or a support request through our support system; you’re talking to the guys who wrote the app. So any feedback you supply about how you use the app or what features you love or want; that all goes into the bucket of your potential future ideas and future work. We do our best to solve your problem as a developer using our product. It's a much, where as everyone knows, the only way to communicate with Apple seems to be through dev forums or Radar, and Radar is the hole where good ideas go to die [chuckle]. All you got to WW and you get some tricks and some directions, but it’s harder and harder to go to WW so the vast majority are stuck with the dev forums and Radar. There’s definitely space, I think, for really good third-party development tools, and that’s where we want to be with it.

I want to take a little diversion and ask a little bit about accessibility. I haven’t personally used Reveal; I have watched the video, but that’s about it. Are there use cases where I could Reveal to validate the accessibility API? I mean, beyond – I guess you can mess with the accessibility properties.

I knew you’re going to ask this, Pete. Yeah. You’re not the only person who wants to have an accessibility on a hierarchy or inspector. Yeah, we haven’t got that at the moment. We can twiddle with the accessibility label and attributes and stuff like that on each view, but we don’t currently expose the accessibility element hierarchy. It’s something that’s again in that bucket and the backlog that may or may not get into version 2. We know it like you’re obviously interested in that from using Frank, because of info testing purposes, and so on, for Cucumber and what-have-you.

Yeah. It’s interesting I've eventually talked with people who didn’t use Frank for – they’re using something else like Kif or one of the other tools out there for writing the test, but they used to use Frank just for Symbiote, which is like a really crappy version of Reveal, like a 0.01 release of Reveal maybe. And nowadays, when I hear people saying, ‘oh, I’m using – I use Symbiote’, I just say, ‘use something better. Use Reveal instead’. I think maybe now because XCode the runtime view debugging is maybe enough for that purpose, but I guess that is definitely why I’m interested is because some people use this for, not just for debugging their UI, but also for figuring out the hierarchy of their UI, especially QAs. So someone who’s a test-automation engineer or whatever their job title is, they don’t actually work on the code directly, but they want to be able to see the view hierarchy so they can automate tests that manipulate that view hierarchy or access that view hierarchy. It’s a very useful thing to be able to mess with all the accessibility stuff.

Yeah, definitely. It is definitely one of those use cases that we would like to support better. It’s just a matter of – it’s been purely up to this point, it’s been a matter of prioritization. So, yeah – I would really like to start exposing a whole lot more data and the accessibility is just one of those additional sort of points of data. It’s definitely on the road map that we’re – when it comes to this kind of up to priorities and time available.

Sure. Makes sense if you guys got a lot of things on your plate.

If there are test-automation engineers who are using Reveal who would like this feature to be more prominent, then just voice – raise your voices. We need to know more about - I've met a couple of other developers in person who definitely want that and have asked personally for that, but two voices in a crowd doesn’t usually make enough of the case for it to raise the priority, but if there are more out there who are using it, or using Reveal, or who would want to use Reveal for that sort of purpose, then we need to hear about them.

Another random question. I’ve been writing down my list of questions. Class process UI. We’d like the XPC stuff that Apple added a couple of releases ago, I think, where if you open up the emails – the email compose thing or something, then it will actually be running in a separate process. Is that something that Reveal can somehow get into show the hierarchy, or is that kind of – does it just have to stop at the point that you’re into a UI that’s running in a different process?

Yeah. UI remote view controller – that would be a dark art to figure out how to do that.

Yeah.

That would be great. But that one is jumping through XPC and cross-process inspection. That would be very tricky to do or to pull off without some sort of multi-process injection or something. That would be awesome. [Chuckle] How easy that would be to pull off, I'm not sure. We obviously – because our library's in the wild, people have been using it in jailbreaking and stuff to throw it into other apps, because you can inject it dynamically using the dynamic loader – dynamic library loader, people have been doing that with jailbroken devices and inspecting Apple applications and so forth. So while we don’t officially support that sort of behavior, it’s certainly something that’s not impossible. That would be an interesting technical exercise. It is fun for someone to try.

Another random question. I’m a little curious on how you got your company on board in developing a product. A lot of consultancies or small shops get together with the idea, yeah we'll do consulting, build a product on the side, and in most cases it doesn’t work. They never actually get a thing done. They’re too busy with client work. Can you talk a little bit about how you got that to happen?

Well I guess, I mean Sean is probably the better person to ask those sort of questions. But from my perspective, I think I always just – we wanted to do it and we had the resource at the time. It was kind of like an opportunistic thing. We had our resource available. He wasn't on a consulting gig for a couple of months, and we started prototyping, and we had something running fairly quickly. It was then a kind of ‘oh, this is –how much further can we get if we push this?’ So, it then became a priority that we had enough available capacity and capital to invest in it. It was kind of something, as I said, we started thinking about it quite a while ago and started talking about discussing it but nothing really happened until we sort of serendipitously, we had an opportunity to prototype something. And then once we had a prototype running, we’re like, ‘oh, this needs to be a product’. It became useful almost immediately, basically, even without our own consulting.

Ok, so you had the owner with an employee that did the prototype? Something you kind of have on staff already?

Yeah, it was one of us. He is now a senior programmer at the company, but at the time, he was one of our mid-level engineers. He started the prototyping first. It was kind of luck and good fortune and [inaudible] and found use like within the company, we started using it to deal with client projects.

It was good if you can dog food the product you’re building.

We definitely dog food it. Consultants here on site and at our clients are using it all the time.

That sounds cool. Anything else you want to say about Reveal before we get to the picks?

We’re beta-ing a 1.1 release, which will be a free upgrade to all existing customers. It will be bringing things like an improved user interface and UI auto-layout inspection, amongst other things.

Very cool. Alright, well let’s get to the picks. Pete.

I feel like I get picked first a lot. My first pick has nothing to do with iOS development. It’s a JavaScript development. I recently picked up a book called Effective JavaScript written by someone at Mozilla whose name I can’t remember. I kind of ended up consuming the whole thing in a weekend, and it was – it’s a really, really awesome read. It’s now going to be my required reading for anyone who wants to get good JavaScript development, moved past just the basics of kind of doing stuff and to turning it into official JavaScript developer. So, if you do other stuff other than iOS development and you do JavaScript, then I very, very highly recommend Effective JavaScript. I haven’t done a beer pick for a really long time, and I was racking my brain trying to think of new beers I’ve had recently, and I couldn’t think of anything that stands out. So I’m going to go for an olden, and oldie bit of goldie Damnation by Russian River. Russian River make really, really amazing Belgian-style beers. They make Pliny the Elder. They're very famous for this IPA that they make, but they also, I think are even better at making Belgian-style beers. Damnation is kind of a classic, like a golden ale or a triple or something like that. It’s really, really good, and it comes in a little bottle, so you can have it and not get drunk. That’s it.

Ok. Alondo.

I have my picks this week. My first pick is Mighty Mic, which I hope is noticeable. I picked up the Blue Snowball mic and I’m loving the improved sound quality. It’s a great mic; it’s not terribly expensive. I picked it up at a local music shop, and so far so great. My second pick is – like Pete, I haven’t picked a beer in a while. I went out and had a local beer from a brewery in Raleigh, North Carolina called Big Boss, and it’s the Big Boss Bad Penny, and it is an excellent brew. We’re celebrating converting one more relative away from using Windows; I got them a MacBook Air – I mean a MacAir, and so it’s one less machine that I have to support. So it’s a delicious ale, and I think if you can find it, you would really enjoy it. Those are my two picks.

Very nice. I’m using the Snowball too. Pete, do you ever use the Snowball?

I do. Although now I’m really scared because the USB thing at the back is starting to come lose, so I might not have a Snowball for much longer.

Watch out. I’ll just keep mine plugged in to my Thunderbolt display. So my USB is good. My picks. Ran across an NSHipster article from last week. He’s talking about kind of uni-testing. But one really cool take-away from that is he’s talking about how do we do mocks with Swift. We don’t have all the run-time trickiness that OC mock and all those different frameworks he used. But one cool feature of Swift, he mentioned in the article, is that it’s very lightweight to create a subclass for a class. So it’s easier to just create a new class on the fly, in line in the function, and override the method that you want to stub out. And that’s what a lot of purists are saying we should do anyway: subclass it and explicitly create your stubs versus the old mocking framework, which you don’t need. But that’s very cool; it’s very easy. And that’s my pick for today. Oliver, do you have any picks?

Yeah, I do. I have a couple. My first pick was actually a blog post by Ole Begemann around Swift and instance methods carried functions in Swift. And it's something that’s mentioned in the Swift book – they kind of crossed over and Ole discusses them in more detail and links to a bunch of other articles which are sort of very interesting. And then I totally, sort of on an iOS related note, I mentioned earlier in the podcast, I came from a game development background, and I still play games. I’ve been playing Destiny on my Playstation 4. The beta came out recently for a weekend or so, and that’s a lot of fun. It sort of scratches your MMO plus shooter plus loot sort of game, like Diablo. It’s certainly one to look out for in September when it comes out. And to follow up on your mocking and testing in Swift is a great article written by one of the senior engineers at REA Group in Australia here where I’m working at the moment. Not really into iOS, but more to do with Scala, and Java sort of things. But it’s sort of like don't use mocks in your uni-tests and he's discussing techniques to avoid mocking and stubbing. It sort of relates, I think, quite closely to Swift because Swift is quite similar to Scala. You are using techniques built in to the language to avoid having to mock anything. Maybe mocks and Swift not mixing together well are - maybe it's a good thing; we can just stop using mocking.

Yeah. That’s definitely a step in the right direction. I know Matt Thompson, NSHipster says, the built-in tools are going to be pretty good for a lot of the cases where we used to going forward.

Yeah, I think so.

Well, great. This has been a great episode. I’m looking forward to checking out Reveal. Thanks for being on the show Oliver, and we’ll talk to you guys next week.

Thank you for having me.

Thanks a lot.

Thanks a lot.