Get your Ruby Remote Conf tickets and check out the @rubyremoteconf Twitter feed for exciting updates about the conference.

 

02:05 - Dustin Bruzenak Introduction

02:29 - Dylan Bruzenak Introduction

02:54 - The Iconfactory 

08:54 - Design and User Experience

18:24 - Lessons Learned From AppViz

27:56 - Positioning Your App Properly

34:19 - The Developer Market

37:09 - Niche Market Focus

45:41 - The App Store

Picks

FastSpring (Andrew)
DevMate (Andrew)
Apple API Diffs (Andrew)
GOG (Andrew)
Sample Code from WWDC Sessions (Mike)
Wits (Mike)
Listen to other people’s views (Chuck)
Ruby Remote Conf (Chuck)
World Time Buddy (Dylan)
Complice (Dylan)
Transmit (Dylan)
xScope (Dustin)
Slack (Dustin)

 

There are no technical people in California.

Hey everybody and welcome to episode 110 of the iPhreaks show. This week on our panel we have Andrew Madsen.

Hello from Salt Lake City.

Mike Ash.

Hi from Fairfax Virginia.

I'm Charles Max Wood from Devchat.tv. Real quick. I know this isn't a Ruby show but if you're interested in Ruby and you want to go to an online conference that I'm putting on. Go to rubyremoteconf.com. It’s going to be at the end of June. Go check it out. It'll be awesome.

We have two special guests this week. We have Dylan Bruzenak.

Oh, I'm supposed to say hi now. Hi.

Yeah. And Dustin Bruzenak.

Hello from Minnesota.

Do you, gentleman, want to introduce yourselves very quickly?

Yeah, I'll start. I'm Dustin Bruzenak. I'm from IconFactory North. We are the development branch for IconFactory and we build apps for clients, primarily, although we have some of our own inhouse apps. We do some work for IconFactory apps like Twitterific. One of the main things that we've done recently that you may have used is the watch app for that.

Cool.

I like the Twitterific watch app.

And for my part, I'm the do-everything-else-that-needs-to-be-done. Technically, I mostly work for API design, cloud services, working on the server side of the app equation. I also wrote AppViz and Mac apps and iPhone apps as well. Lately I've spent more time in the in-between mapping layers and the backend than the frontend also at IconFactory North obviously.

IconFactory has been around for a while, what is IconFactory North?

I think IconFactory has been around almost 20 years now. IconFactory North really was born out of AppViz. When we were doing AppViz 3, we'd decided that one of the main things we wanted to do with AppViz is get a designer. We're all – the three us – it's me, Dylan and Troy Gaul, that you may have heard of is the lead on Lightroom so he has his own app development shop called Infinitapps. We're all working on AppViz 3 and we’re all from Adobe. We're used to working with really talented designers. Because if there's one thing that Adobe has, regardless of how many Photoshop palettes there are, I mean, they have some very top notch opinionated designers. We had this great experience working with them.

When we all left and worked on AppViz, one of the things we were missing was that designer. So we tried to do our own UI and I'm sure you’ve all – lots of you have seen the result of that and also, just in general, the result of what happens when developers try to do their own UI. It was something that was functional that looked okay but we weren't proud of it like we've been proud of Lightroom.

What we did is we went to IconFactory and we said, “Okay, we need a design partner.” because it's time AppViz wasn't making enough money to pay hundreds of thousands of dollars for design but we wanted something that looked really good. So we approached IconFactory with a partnership proposal. We said, “Look, we know you guys are sort of the top dog for design or one of the top dogs for design in the iOS and the Mac space. You've been around forever. Can we work something out?”

It duck tailed nicely because Craig Hockenberry was a large part of our success with App Viz. He was one of our early beta testers. He was the first person to tweet about it. He's endorsement of us, basically, is what really launched the AppViz business. Through Craig, we had heard that simultaneously to us needing this design, IconFactory was looking at doing something called BeanCounter which was an internal app for doing financial reconciliation which was one of the major features that we wanted to do in AppViz 3. So we approached them and said “Hey, can we partner on this instead of competing? We'll do the financial stuff that you guys really want for yourself and you guys can do the design for the app.” It's how AppViz 3 was born.

We launched AppViz 3. The problem with AppViz, in general, was that it was always a small market. It was Mac users who didn't want to have their data stored in the Cloud using a Mac product to track their financials and primarily iOS developers. We had underestimated the position of our market. Primarily, we had underestimated how badly people wanted to keep things on their desktop and not from the Cloud. That was our fundamental mistake. We needed to move to a recurring revenue model because the market was so small. So we moved to the Cloud with a recurring revenue model and it did not go awesome.

From that, it did okay but it wasn't what we wanted it to be. It was obvious that that wasn't going to become [crosstalk]

That's the meandering way that we get to.

Right. [Chuckles] This is all – it's a journey, right. I'm trying to explain the journey. Anyway, we're deciding what to do next and one of the things that we looked at is we looked at the mobile space and then we said, “Okay, there's a lot of mobile developers out there who are good who need help building their apps or bringing their apps to market. There are a lot of people out there who have really great ideas who don't have the mobile expertise and the Objective-C expertise that we have. Can we package that and sell it?”

One of things we were looking at is we're looking around and we're like “Okay, this guys also need designers.” So, we went to IconFactory and we said “Hey guys. Do you ever get people asking you to do development work?” Their answer was, “Yeah?” And we're like, “So what do you do?” And they're like “Ah, we usually say we don't do that.” [Chuckles] And so we said, “Hey, how about you start saying yes? And we'll build a development consultancy here that partners with you.” That's how North was born. We've been doing that for about a year and a quarter, something along that line. It's just been skyrocketing.

It's been pretty crazy.

It's been pretty crazy. It turns out there was a lot of demand for people who can merge the skill set of design with development. That's how North was born. Now we're five people here in Minnesota. We primarily work with four designers: one in Sweden and three in North Carolina, and then a person in Georgia, person in Iowa. They're all over the place.

IconFactory is a pretty distributed group.

Are those designers you work with people who are part of IconFactory or are already part of IconFactory? Or they're just working with you? Because IconFactory is traditionally designing their own apps.

It's all IconFactory. One of the designers we work with – the two major designers we work with are Dave Brasgalla and Ged Maheux who was one of the main founders of IconFactory. But we do work with Anthony Piraino and pretty much their whole staple of designers.

Most of the development still done for their apps like Twitterific is still done by people on their side of the boat. Sean and Monroe helped if they asked for help but they’ve got some of couple sharp – Sean and Craig are pretty sharp technically very smart so they [crosstalk]

Don't forget Tyler. Tyler Anderson is also very good.

And Tyler.

But yeah, we wanted to come on and not take [crosstalk]

But they were in interest in working on outside app. That’s why if someone comes to them with an idea and be like, “I need this awesome icon. You guys did an awesome UI. Now I have this awesome UI in Photoshop; it's all broken up in the layers I need, how do I turn that into an app? I don't really know what I'm doing. I have to pay someone else.” They'd have to go and find people and then they'd have to take their chances on whether they were good or not.

Now, we can provide that entire experience and say “Hey, we got this design; we can work iteratively with the developers.” I mean the designers and the developers working together to get it done and then working with the customers. That works a lot better. It depends on the size of the app, what the target is, whether it's worth hiring a premium design firm. Dustin will yell at me for saying that later. [Chuckles]

One thing that I'm wondering though is that it seems like a lot of folks out there when they're building an app especially if it's munging or organizing data in any way, they just use the default look and feel from Apple. How much design really goes into it other than the app icon?

If you're going to do a real app – if you're doing something for a business, a lot of those things are I guess bastardized piles of hell code and UI that uses Apple's bare minimum viable product. That's fine because you're trying to get a basic business task done for your enterprise. But if you're going to do something that sells to consumers and the consumers want to keep installed on their phone, it either better be completely indispensable or it better look good and more importantly work well enough that it doesn't frustrate them constantly.

I mean, we all have a bunch of apps on our phone that we don't use and there's a reason we don't use them. Half the time it's because they just weren't that useful. But the other half the time is that the user experience was frustrating. The big part of design isn't just making it look pretty, it's making it work well. And that's where we bring in the workflow, organizing the information, making sure it's presented to the user in a way that makes sense because a lot of users for most of these apps, they're not us.

They're not the technical guys who are going to dig or going to spend an hour working on figuring out how to get the data. It's not important to them. They're just trying to get their problem solved and their domain. They want the app to say, “Hey, this is what I do for you. Hit this button, get it done.” Then they want to return to their daily life.

That is a great answer, I think, to the question. I think the other answer is – look at the apps you use on your phone on a day to day basis and how many of them are default UI table views and UI navigation views without customization, without animation. There's a few but the ones that we really fall in love with – I can say Twitterific, it seems self-serving but before I was at IconFactory, I just love Twitterific. The reason for that is because I have this emotional response to the way the UI is built; particularly the new UI. That kind of emotional response is not delivered by a simple table view app.

If you want your customers to really engage and more importantly for your business re-engage with your product, you need to create this emotional experience for them when they're using it. The best way to do that is delightful animations and design. Without that kind of fundamental interaction, your app is going to fall by the wayside as soon as someone else produces something that has a different feature that someone wants.

That sounds like marketing speak but it's also very, very true in that if you look at the falloff rates at graphs for how often people return to your app like a month later, you can see the punishing realities with the App Store. You can see that you need to scrabble for every little thing that you can and the way your app looks, that's the primary experience that the user is going to have. It's not the data that's in it. If they can't get to what they're looking for in just a couple of taps, they're going to delete your app. They're going to uninstall it.

I'm not saying that that is necessarily true of all apps and for all people. Different levels of design, obviously, you need to take your market into account. You need to know who your users are going to be and what they need. But if you’re making a game or even a social app or whatever, you want an experience that’s good from end to end. If you can do that design yourself, that's great. But so many people can't.

Given a specific design then as a developer, how do you begin to approach that?

First of all, it depends on the designer, right? All designers work differently. Designers are, if any of you had the pleasure of working with designers, they're unique people. Individuals just like developers can be unique individuals. It starts with a communication with the designer because the first thing you'll notice when you start dealing with a designer – even a really great designer – is that they don't think of all default scenarios that you do as a developer.

So our initial process is we meet with the customer; we wireframe everything out so we know what the flow is going to be. We decide, basically, are we using UI navigation? Where are we using the table views? What's going to be modal versus non-modal? We hand that off to the designer and they do some initial sketches and renders. They come back to us and we look at them and then we say, “Alright, this thing is perfectly positioned if the text is 30 characters but what happens if the text is 50 characters?”

I'm sure we've all encountered that kind of scenario where something looks beautiful on the screen but then you actually start pumping real data into it and you realize “Oh, this totally isn't going to work.” because it doesn't take into account different layouts. It doesn't take into account localization sizes. It doesn't take into account all these various things that feed into making a final app.

Because we've worked with the designers for so long, we can go back and say, “These are the thing we need from a design perspective to change.” That's usually a pretty minimal list because most of the time we can take their intention around their design and adapt it to the actual implementation. Then we break it down into sprints. We practice Agile but if you came from Scrum, it's not Scrum anymore.

As black as the word as that is of these days. [Chuckles]

We start implementing the designs –

It's pseudo Agile. We're totally Agile. We're not sloth-like in our development.

Yes, we move quick like hares or whatever. Anyway, then it's a big feedback loop. Once you do the first design, you get it out on test flight. It used to be Hockey app. You get it in front of the customer; you get it in front of the designer and you start iterating. The real key is when you look at a design, making it pixel perfect is not the ultimate goal. It's getting the intentions of the designer conveyed using the technology. In that space, that's where Troy's expertise of building UIs for millions and millions of people comes in because he's essentially channeling the designer and making the technologies work for the design. There's a set of – it's a nice responsive feedback loop but you have to go back [crosstalk]

Pulling out xScope, another IconFactory product, and making which app to mention. It's awesome. You should use it. If you're not, it's great. I'm using it to analyze the terrible HipChat logo right now. Getting that out and making sure it's going to work on all the different phone sizes and all of – even on the iPhone space, it's starting to expand. You want to make sure it works on Retina screen if it's something that's a Mac. You want to make sure it works on the 5K and all of the different resolutions and all of that. That's a lot of work. [Chuckles]

I think there might have been an answer to your question in there.

Yeah, I think there was.

We tend to wander –

There's a lot there but I think, ultimately, its communication and understanding what the purpose of the app is and then understanding how to work with the person that's doing the design.

Oh, it’s even — to use a specific example, often times the designer will break something out into sections on the app. A person who hasn't done a lot of UI development will take out a measuring tool and say, “Okay, this label is 30 pixels from the left of the screen or 30 points and 100 points from the bottom of the screen.” Then, they'll go and implement it and they'll measure it and then they'll spend forever getting the 2 points that it's off because for whatever reason, there's a margin that was introduced that no one expected. Whereas, if you have some experience at this, you'll look at it and say, “The designer intended for this to be a third of the way up from the screen with default padding.”

You got to – at this point, you have to talk about the layers problem that you had with AppViz. Remember that? You had some –

No, I don't even want to get into that. That's speaking hell. [Chuckles] I had a bug in and where the CALayers on the Mac wouldn't even draw – you had two-layer back views and one-layer back view existing would make the other layer back view not draw at all. But if you went into it with Pixie or xScope, it would show that it thought it had drawn. The zoomed-in view would show what you expected to be there but the actual screen was not showing that. It was amazing.

response that I got was, “CALayers are shit. Don’t use them yet.” This was back in – it was a 10-5 or 10-6. It’s just that don’t use them with collection views; don’t –

I don’t think that – he’s paraphrasing me actually.

I’m paraphrasing. It was more couching terms. The people in charge of that code at Apple were like, “Ehh, don’t. You shouldn’t be trying to take this shit.”

Yeah, I really hate it when that happens. They put up something, talk it up. You go use it. Nope, not ready yet.

So many other things, too, are things that work awesome on the iPhone. And you go to use them in some of your Mac development and you find the analog like CALayers and you go to use it. It’s not that it doesn’t work for basic things. It’s when you get to the advanced stuff – the nitty-gritty of implementation. It’s just like, “Nope, this is just not going to work and there’s really no explanation for what the hell is going on.” You’re just lost in this wilderness with a little knife trying to hack your way out.

Yeah, in this case, it was because the two CALayers weren’t anchored in the same parent super view. They were but the super view wasn’t layer-backed itself or something along those line and they were interfering with each other in the draw. That’s basically what I figured out. I was able to fix it by crawling up the stack and making sure everything in between was also layer-backed. That magically fixed it. It didn’t make me feel real awesome about the fix but how many have you Bandaided something and gone, “Oh, It looks like it works. Okay, were shipping it.” That’s part of the fun of being an indie.

We’ve minimize, perform after delay use in our code by 99.99%.

Yeah.

With AppViz, you said that it didn’t work out. I’m curious, what lessons did you learn from that?

Oh, just a ton of lessons. That is an entire podcast in of itself.

To be clear, if anyone doesn’t know what AppViz is, it was an analytics tool for App Store developers like an App Annie and AppFigures. AppFigures is the one that we encourage people to use because it actually takes your data seriously. iTunes Connect now provides a bunch of graphs and stuff. When we started, they didn’t do that. I guess one of the big lessons is: Never actually integrate with a website that doesn’t have an API if you don’t want to spend a lot of 2 AM mornings fixing things for you customers. [Chuckles] That’s one that I pull. And that we did 50 some releases every single year for AppViz. [Chuckles]

Wow. Yeah.

AppViz, basically, since we were scraping iTunes Connect, we were always under Apple’s shadow. That wasn’t a comfortable place to be. They weren’t malevolent.

That’s like living on the back of any other giant. Sometimes it goes to sleep and you’re crushed. [Chuckles]

Yeah, yeah, exactly. They were indifferent. And when Dylan started the company, he was spending so much of his time doing maintenance releases due to iTunes Connect changes. And also just -it’s not just iTunes Connect changing but the data feeds for – I don’t know if you guys have seen – you probably all looked at the csv or at least are aware of the csv from iTunes Connect. Occasionally it’s just wrong and then they fix it the next day and people don’t notice because they don’t have an automated tool to pull stuff down. But we found people – when we started pulling these things in daily and merging them into the database, Dylan found that Apple was making decent number mistakes. There were bugs in the data. We would have to go and find out. Is this a bug in the data? Is this a bug in our code? Is this a bug in the graph?

Right. Where is the bug? So a typical day for Dylan was booting up support. Digging through the five or six things we knew how to answer, getting the support for Question Number 7. Then, eight hours later, he has an answer that is effectively, “Oh, Apple just got the report wrong. It’ll be fixed tomorrow.”

Or something happened [chuckles] that was specific to your choice to sell in Cruzakistan. I’m not even joking. I mean that’s a real bug if there was something to do with – or maybe it was Russian currency translation that day. I don’t know. But I’d spend four hours finding a problem for one customer and that does not scale. You cannot do that. People love that level of support and that’s why I love providing it. You’re dealing with developers. When you engage with them, it’s an awesome experience, for the most part. It’s way different than dealing with the rest of the market on the App Store where you just see terrible reviews.

Someone might get angry one day and be frustrated with your tool but they’re just expressing passion about it, right? If they’re willing to have a conversation with you about it, you can learn a lot from developers. They’ll pull out their own tools and find the stack trace and tell you what the hell is going on. It was awesome.

Make mock ups for you.

Make mock ups for you how they thought it should work, right? On the one sense, it’s like you want to decide the things but that feedback is invaluable.

AppViz, at that time, it always ran between 30 and 100 support emails a day. Some of those support emails – some days we would get 10-20 support emails that would take four hours each [crosstalk].

When we release AppViz 2, it took us three weeks to just label all the email that we got from that release.

We had to hire someone –

The two of us. One of the major take is this: When you’re thinking about your business and you’re going into it, I would highly recommend you think about a way to minimize the support burden because, especially as an indie, support can kill you. It can destroy your ability to function and not just from a volume perspective but also from emotional perspective. So it’s really important that you have an insulation layer there because between the two of them, for AppViz, we probably spent a year and a half doing just straight support off AppViz 2 without getting any new features written, without thinking about our market, without doing anything. We were just paralyzed –

[Crosstalk 22:29] Given this tendency to solve to their problem in front of you because you feel the customers pain very acutely and you know that it’s a bug. But you’re not solving the problems at all if you’re helping. Ultimately, that would kill your product. You have to step back and see a higher level view. That’s something that I just did not realize at that time. It was just I felt so inundated with it that I felt like I couldn’t step back and do that higher level thinking. Or figure out – we did eventually figured out the basics for extracting.

The real reason to move to servers was not so we could charge amount to the revenue stream, it was so that I could do the changes in one place and not after release after release and deal with customers across 20 different releases of the app complaining about bugs that may or may not exist in various versions. To fix that problem –

When you’re doing, basically, a version a week or every two weeks, the first thing you want to know from a customer is “How old is the version you have? Did you run update?”

It’s terrible. A lot of the customers aren’t technical that you would think. They’re business managers. They don’t even necessarily knowhow to check for that kind of thing. So they don’t understand – they don’t read the release notes. They don’t understand what that’s stuff’s about. They just want to see their one graph so they can produce their report for their vice president or whatever. I get stuck in this position. It’s like –

Are you guys familiar with Matt Romney or Matt Ronge? I can’t remember his name. He did AstroPad I think is the name of the app.

I think we’re going to have him on an episode soon.

He’s a good guy. He’s local here in Minnesota. I believe he just did a blog post about how a huge chunk of running an indie business is managing your emotions. Effectively staying productive and keeping yourself energized and engaged with all the incoming onslaught of all the stuff that you don’t really get into this business to do which ends up being 95% of what you do in this business.

Everyone has this dream when they leave Big Co. that they’re going to create this awesome rockstar product that they’re going to function well while they’re building it with no feedback from anyone else. That’s it’s going to come out and that it’s going to make them tons of money and they’re going to spend the rest of their life on their yacht. I think that’s a great dream to have but nothing like the reality of running a business which is that it’s work.

You hear this over and over again but you really don’t feel it till you’ve done it yourself. It’s not just work. It’s harder work than your doing for Big Co. It’s more grueling, it’s more demanding, it’s more rewarding when you’re done with it sometimes but emotionally, it’s going to be far more draining than just doing Cobalt. [Chuckles] Go back to Cobalt.

You’re trading one boss for however many customers you have – for 10,000.

That’s really what’s you’re doing.

We talk about a lot of this stuff from the Freelancer show.

Yeah. If you’re not the kind of guy that would saddle up a camel or whatever you do with camels and go across the Sahara with no water, you’re not going to be the kind of guy that can survive that kind of environment that you need to be in in an indie because it’s hard. Even if you’re successful – and most people are not – even if you’re successful, you can go a month without fresh water. Without positive feedback. You could go six months thinking that your app is either to be going to be completely successful or totally fail and you’re 50-50. You got to wake up every day, sit down in front of the keyboard and write a few hundred lines to a thousand lines of code every single day.

Yeah. If you could get a partner whose whole job it is to just be the armor between you and just give you the feedback, to distill the feedback or an employee that can just read stuff and tell you, “Hey, this is the important bugs and whatever and pull out the vitriol particularly in the app stores” still with their views – I can’t believe that’s still a problem but it is – just don’t read your reviews.

That’s the solution that I’ve seen a lot of people have. And that’s terrible [chuckles] because there’s a lot of good stuff in there. You need to know what your customers are saying. But a lot of those people on their app store, they’re not even your customer – not really.

At one point, we discussed a feature in AppViz. We thought it might be too on the nose that to have a way to submit a review to an anonymous service that would anonymize the review – take the user’s name out of it – and just display it for everyone to see. Like a text from App Store review and stuff like a text from Xcode. Some of these things are so terrible – either so mean and stupid or just so straight out weird – that they’re worth publishing in their own right. There’s got to be a Tumblr or something somewhere with this stuff up because I think everyone has had this experience. You release an app; you get this review that’s like. “But the feature is there?”

How to make balloon animals” so you know there’s nothing in this that says that it’s a game. I’m looking through the apps store reviews and there’s more than one that’s like “This game stinks.” That I think is the fault of marketing.

To be clear, if you wanted to make balloon animals, the app was very good at teaching how to do that.

Exactly. So I’m thinking the guy who made that app is looking at the reviews going, “What?”

Probably holding his head looking at his sales numbers and crying. [Chuckles]

Are there critical things that you should be doing to position your app properly?

That’s the other thing that I learned is that – and something we’re taking much more seriously with IconFactory this time around – and that is that you either really need to have a person that does marketing and management of your company full-time or you need to make a strong concerted team effort that makes it 50% or more of your business. You could rake the best app on the planet and if no one finds it, you are going to fail. And even if people do find it, your chances of success are still very limited even if it’s really, really good.

One of the tragedies of the App Store is that I think it’s made very visible how terrible that arc can

be for people and what the percentages really are in success. It’ll be interesting to go and look in the 90s at the web businesses and what the percentages of failure were there and correlate them. Is it higher? Is it actually higher? Is it just that we’re more [crosstalk]

In general or anywhere because the interesting thing about the app store is just now with all the rage about analytics and stuff and we can talk about privacy some other time but now we know what the adoption rates are, what the return rates are, how people are using the apps. I think this is historically has been the data that people – app developers didn’t have in the 80’s and the 90’s.

Even on websites that really only started ten years ago to start to get huge outside of big companies, to know what your customers are doing – whether they’re returning or not. So now we can say there’s a 2% return rate after a month or however low that shitty number is. It’s terrible. But that doesn’t mean that that’s just the App Store. If that could just be the success rate for independent software development, for all we know, right? If that’s the case – those are things people need to know about before they start making bets on this industry. [Chuckles]

Yes. One thing that you can say is that if you launch without marketing, you’re pretty much guaranteed to fail. If you launch with marketing in business, you’re much, much more likely to succeed. Marketing is very, very tough especially for us developers who aren’t really that savvy. I think a lot of developers and I certainly thought marketing was evil when I left Adobe.

I have this reaction to marketing people and sales people that is – I think not giving them the benefit of the doubt. I tend to look at them and say, “These are people who aren’t developers.” But they’re building something. I think that’s an important thing to understand is they’re building businesses. They’re not building apps. But a lot of these people are just as dedicated to that as we are for building code. It’s really important that you find a partner that can do that for you if you’re not willing to do it yourself.

If you’re out there and you’re writing code and you don’t have someone to do the marketing and you don’t have a marketing plan, stop writing code, spend two weeks figuring out what your strategy is because you will fail if you do not do that. It’s pretty much guaranteed. You’re betting on a lottery, otherwise. If you look at people like Michael Simmons at fantastic–

Flexibits.

Flexibits. This is a guy who is incredibly good at making the connections and remembering the connections he needs to make his apps’ launches successful. Every app launch he’s done, I’m pretty sure he’s made money or at least broken even. There’s a reason for that and that’s because he focuses on the business side while Kent does a lot of the hardcore coding. They’ve got that virtuous partnership. I think that in order to be successful in the store, you need to think about that early and you also need to think about it continually.

I saw another post that was –but I forgot who it was from – it was something along the lines of the web where doing right now, what we did in the late 90’s on the web which is that we’re spending 6 months, 9 months, a year building things that we have no idea if there’s a market for them. We’re putting them all in the app store then they fail. It’s like, “Okay, that’s not really surprising.” If you look historically at the lessons we’ve learned from web developers and from app developers that what you should be doing is building something smaller, simpler that finds your market – VC’s call it product/market fit. Ship faster, sooner, get that validation, get those Beta testers and then listen to your audience. More importantly, metrics the hell out of your app and take a look at how people are using it or when you’re losing people. Optimizing the [crosstalk]

To be clear, do not use your metrics as a way to invade your user’s privacy.

Yes. That is true.

You got to be respectful and get the respectful service.

If you have for instance a login barrier to your app, you should really pay attention and understand how many people you’re losing to that login barrier and start thinking. Is there a way we can remove that? Is there a way we can make more people go through that? I think a lot of developers start out of the gate and say, “Well, I’m just going to ship it and then I’m going to add metrics maybe in 1.5 and then maybe in 2.0, I’ll do something new with the login. But login is done so I’m checking it off the chart. I’m never thinking about it again.” But the reality of what you look at is if you look at a login system, you’re probably losing 80% of your users. They aren’t even creating an account. That’s probably a metric that pretty much every system with an up-front login has. With metrics like 2% a month out –

That’s even – by the way, that’s even if your login system is just go over and click a Facebook button, you’re losing many users.

Marketing is about getting your app name and stuff out there but it’s also about finding your market. That’s the part I think that people miss when they go out and read market blogs. The blogs about how to get yourself featured and how to get in good with Apple and how to get yourself on podcasts and this podcast not withstanding because I’m sure everyone on it makes a tons of money in everything mentioned here is doing well. Say you’re featured on Engadget – or ZenGadget even around anymore? I don’t know.

That is only a very tiny part of what marketing really is. What marketing really is going out there and finding your customers; finding who’s going to do that word of mouth that gets you traction so that your new work’s growing instead of shrinking. Then from there, you build your marketing presence – as far as traditional marketing. But until you have a feature set that’s compelling to people, until you know that feature set is compelling, any money you spend on ads is going to be wasted. Any feature that you do 1.0 is going to be wasted if your 1.0 is targeting an audience that doesn’t exist.

This maybe goes back in time a little although you’ve circled back round to it but you talked earlier about with AppViz, you said something positive about how your users were developers and they were maybe not so horrible as the typical app store reviewer. I’m curious to know if you guys still like that market because I think that’s a pretty specific market.

You mean the developer market?

Yeah, making tools for developers.

I’d say I love the market. I’d get out and I meet these people every day and it’s nothing like knowing the WWDC. I got a hug one year. I mentioned that every year, every time I’m on a podcast. Some guy walked out to me. He’s like “I love your app.” And he hugged me. You know what? That actually meant a lot to me as weird as it was. I understand where he is coming from because he’s a developer. I understand his needs and he understands what I’m doing.

Developers understand that problems are frustratingly take time to fix. And they’ll actually help you work through it in fixing it. They’re really good at getting you logs but it’s not a great market to sell. Developers are very much “I will build it myself if it’s going to be too expensive.” They’re also in a situation where a lot of them are not making a ton of money. They can afford to buy a lot stuff. But even something that’s $10 a month that doesn’t seem like that much to you, but they’re doing the math in their head over two years – it’s $240. And they have to position that again to something like Photoshop. [Chuckles]

Right. Okay.

No, I would not try to sell tools into that market unless you’ve had VC or some sort of exit plan or tool that you are sure –

Or just a $20 tool. The problem with AppViz is it was – it pegged all the factors as enormously complicated tool that had to be expensive for a relatively small market. If you’re talking about something more like Photoshop or Xscope or Text Expander or some of the more tools that -- I think you can make money there. You’re never going to make the yacht money –

Okay, I’ll revise that. If you have something that isn’t going to take a large amount of on-going time, you can do the math based on the market size and figure out whether it’s going to make you enough money if you get 10% of the market. I think we had 20 or 30% with AppViz and it still didn’t quite make enough. Then, obviously, I have free competitors like App Annie. It sucks.

I’d say I love the market from a perspective of dealing with them. From the perspective of “Is it a good market for you to target?”Well, there are a lot of markets that are a lot bigger that have real problems that you can solve, too? Developers can solve their own problems. That’s a thing about developers.

Yes. Okay. Well, I appreciate that perspective. I see some – there are developer apps that I think are successful. One that came to mind was Dash – the documentation viewer.

Yeah.

It basically just does better way than Xcodes mostly.

I don’t mean to say you cannot have a developer tool that’s successful. It just needs to be something that doesn’t require ton of on-going time in maintenance and cost.

Yeah. So I think [crosstalk]

You got to keep in mind that it’s a small market.

You ran into, as we are hearing, a lot of trouble with AppViz. Moving that a little bit broader, I’m curious about focusing on niche market versus the whole market of iOS users or Mac users or whatever. There’s certainly the big hits are things like games that anybody can use or Instagram is something that everybody no matter what can get behind taking pictures but there are also these smaller markets. I’m coming at this personally because I have a Mac app that’s for ham radio operators which is obviously a very small market comparatively.

Unfortunately.

We beat you. We had an app that was made for podcasters that did what AppViz did for podcasters.

Oh, wow.

Yes. So it can tell what your rankings are globally who’s listening to you, that kind of thing.

Our market was 10 people. [Chuckles]

That’s literally have been resolved. Our market’s probably a hundred people but still.

It’s getting bigger but yeah.

But I think there is this – maybe it’s easier to differentiate yourself if you’re not competing with every gaming store or whatever.

Oh I agree. If you have a target market and you know how to reach them, if you know how to market them, if you know how to get them to see what you’re doing, and you can charge a real price for that market, -- part of the issue with developers is there’s going to be an open-source tool that does what you do. You can still sell something for them, if you do it really well but you know you’re going to only get so much of the market because the open-source tool does 80% of the work.

But if you’re going to sell something ham radio operators, you can charge 10 bucks, 20 bucks or whatever it is or some ad-supported revenue and you can get them to actually use it, I think that’s a legitimate strategy. I think trying to get everybody to use your app is a fool’s game, too. Everybody is trying to build the next social network. That’s too crowded unless you have a really good niche and a really good idea to target it.

If it’s something you do, something you’re passionate about, something you can understand and that’s what something that led me to do the developer tools in the first place. It’s like my own pain. I was solving my own problem with AppViz. The problem was that it didn’t remain my problem because I wrote a Mac app so the iPhone start problem weren’t my problems and I had trouble understanding. I had to rely more and more on people that tell me what the problems were. So you should definitely dog-food your own app. You should be doing your own thing.

But I’d say you’re probably better off doing that and targeting series of niches where each one generates a steady revenue stream that’s smaller than trying to make one giant dominant thing. Because I heard 5%, something like that of the startups that get funded or are successful and that’s after you get funded. Think about how many apply. You don’t want to be in that market. If you’re comfortable living, making comfortable living or doing some consulting on the side, do a bunch of small apps that you don’t have to – I have seen a lot of customer data over the years and the people who make money, besides the huge guys, are the ones that have 10 to 20 to 30 to a hundred apps. They make good money on that. They make a reasonable living. The can make low 7 figures even some of them. And it’s –

To be clear, that’s not the app mill. These are people who built useful products that didn’t require a huge amount of up-front investment but aren’t the guys who are auto packaging and just dumping stuff onto the App Store because that’s not --

If you’re going to write a dictionary app or something that can be easily repurposed with the basic technology that can be a good market to be in. But if you’re going to write a bunch of crap, you’re not going to probably make money on it unless you have tens of thousands. But if you’re in the 10 to 20 app range, I think it’s maybe a good target for niche markets and you can make good money there I think.

Our average iOS customer, I think, had something like between 10 and 20 apps. When we went to services, we could actually collect that data. The thing is you get done with your app, what are you going to do next? Couldn’t I just sit on your laurels? No, you’re going to write another app, right? The thing that I think people miss is they put too many of their eggs into the one app basket. Write a bunch of little apps, find one that’s successful. Then, invest a year or two in making it really awesome.

Don’t invest all of your mortgage and your credit cards into building that one thing and getting it out there before you know that it’s going to be successful. That’s just – that’s a fool game. I think it’s great that people are willing to take that risk but there’s a better strategy for doing that.

I was – my first app was a really bad To-Do manager that let you manage one to-do task at a time. I put it out there and I was making $5 a day or something like that. If I kept down that route, eventually I would have something that or few things or making $100 a day. Then I would be in a much better situation. It doesn’t take that much but you have to be in it for the long game.

It’s a lifetime career. You want to build the tools; you want to build the skills; get [inaudible] some marketing. Don’t just approach it like the one app that you left your company to build is going to be this huge hit and you’re going to retire in a year because that’s unlikely to be true. It’s just is. I mean good luck to you if it is. If it is successful, hey, it’s like rolling the dice. The thing is you want to play as many games as you can. If you can play 10-20 hands, you’re better off than just playing that one and gambling on that one hand.

There’s an adage probably overused that venture capitalists don’t invest in ideas, they invest in people and industries – primarily industries. I think, as an indie, you have to wait till your time and say, “I’m kind of a venture capitalist and that I’m investing in this idea. I’m investing in this industry.” But what you can’t be so invested in the idea that you’re building that you close your eyes to everything else happening in the market that you’re targeting because often times, you don’t end up building the thing that you thought you’re building in the beginning. It’s hubristic to say that this idea you had is going to be perfect for your market. Release something –

Which again, I guess it’s counter to the idea that you should still be passionate about what you’re doing. You should still put your heart and soul into what you’re doing. It’s just don’t assume that thing that you put your heart and soul into is going to pay off and let you retire on it. Assume that there’s going to be more work down the road that you going to have to do. I know you’re passionate and developers are passionate about all kinds of things. Find a few more things. Do a few more things. Try a few more things.

Sorry if we seem pessimistic on the App Store. [Chuckles]

I’m not pessimistic. Apple – it can sound like that. Apple’s paid out, what they say, $15B and, sure, that pie is sliced disproportionately but there are a lot of indie people who are making it or have a hybrid indie consulting career and are doing good. I think we can focus too much on the negatives but I think that a lot of the negatives are solvable too. I think it’s not unsolved problem partially through Apple. Apple needs to get on some of the things that enable us to do but people have been harping on that forever – things like Beta testing your apps and stuff like that or free trials. There’s a lot of things that you can do as a developer to be successful.

One of the other things that I want to bring up is that the reason that all those dumb games – they’re not all dumb. Some of them are pretty fun but – all the free-to-play games are successful is because they have a low-point blow buried entry; get a lot of people on the door; take a percentage of them and them monetize them. Now I think a lot of them are aggressive and terrible at it but if you do it well, if you’re respectful something like – what was that [inaudible] like game – Crossy Road that sells stuff the people want to buy, you can do good at that.

The other thing is once you have a customer base, you have a customer base. It’s way easier to sell something to someone who has already given you money. I think that’s something that people don’t understand because I don’t see it happening a lot. You should have some sort of in-app purchase. Maybe a zero cost on your thing and some in-app purchase or maybe a cost in some inapp purchase, some people are going to want to give you more money. Give them a way to do that. Don’t make them do it. Don’t put a dumb artificial barrier. Give them the opportunity to pay you for your work. And they will because there are a lot of people out there who don’t suck; [chuckles] who care about what you’re doing or passionate about whatever your app is. Give them a way to help you out.

Actually, people write me in AppViz asking me to charge them more money which was really weird and extremely rare and I didn’t understand it but it’s the truth. There are people out there who have more money. You’re solving a problem for them. They want to give back to you or they want more of your work. Cross-app promotions so you can sell them other stuff; in-app stuff that really matters that actually provides functionality or that helps them express themselves like a different outfit for a little character. But not like this artificial dumb pay-to-play gateway crap where you have to pay every 10 minutes. Don’t do that. Please don’t do that. Turn off that in the market. But that doesn’t mean that the whole idea of in-app purchases is bad. Targon makes all of its money on the people who come back every week and buy their groceries there. I guarantee it.

I think one of the things the App Store – the iOS App Store in particular makes a little bit hard, it’s hard to get this – you don’t know who your customers are or, at least, unless you go out of your way to try.

I haven’t looked at the new analytics. Is it helping break any of that down? Or is it just –

Well, I mean specifically. You can’t email somebody and say “Hey.”

Well, yeah, there’s this huge barrier. You have to do a survey.

If someone leaves a review on your app, you can generally find that person but yeah [chuckles].

If they leave review. It actually brought up another question I wanted to ask you guys because I know I’m more a Mac developer than I’m an iOS developer. I think Mike is much the same way or at least right now he is working on a Mac app,

Yup.

And there’s this questions still on the Mac about selling outside the App Store versus inside the App Store. I don’t know if you sold AppViz on the App Store. I know my copy of it is –

Did not. They would not let us.

Okay. I know my copy of it is not from the App Store because I actually just fired it up.

To be clear, they would not let us because their API, the iTunes and whatever is considered a private API.

Oh, right. Okay.

We didn’t even try. They let us into the -- I think we had an app in the iPhone store. I don’t know. I think we [crosstalk]. We had AppViz trial. I never know if anything ever made it out of Beta or not. [chuckles] because when I use it, it’s always in Beta. They let us in that then talk into our own server which –

So leaving aside the question of apps that just can’t be on the app store because they don’t follow the rules that Apple has, what do you think about selling Mac apps outside the store?

I think that right now you should try to be in the store but if you can’t because of the Sandboxing restrictions you should file a bug with Apple, and then sell outside the store. That’s just the way it is. I think there’s enough flexibility, enough knowledge in the Mac community for how to get those apps. I think that eventually down the road, if you don’t have Sandbox problems now; you’re probably going to run into them. It’s pretty terrible. It be on developer side, all I hear is complaints about it. I hear that the sales are not great.

I’d say put a stick on the sand and try to be there if you can. You probably get some sales but don’t break your back doing it. It’ll get better I’m sure. It’s a great idea; it’s great to have a one place to update and everything. That’s nice for your customers so do that for your customers if you can. But –

As a customer experience, I love the Mac apps store. As a developer experience, if your app is in the Mac app store, I will buy it in Mac app store versus from your website just because it’s so much more convenient for me. But on the same side, I think the fact that we’re having this discussion how many years after the – How many years have been Mac app store’s been around? Four years?

Three years?

Yeah. Four going on five, four and a half, something like that.

Apple hasn’t made it an imperative to buy from the Mac app store for your average customer. I think that that is a huge problem. They are – in business-y terms that I get yelled at for using by my partners – they aren’t demonstrating a lot of traction.

Quit business-ing all over the conversation.

Yeah. Going to business sell over here. They aren’t demonstrating a lot of user growth inside the Mac app store versus outside the Mac app store. It’s been five years. If it’s going to go somewhere, it’s not going to be because it just magically happens. Apple’s going to have to make some significant changes. For now, I agree with Dylan, approach it with caution. Do it if you can and if it’s a huge pain in the ass, don’t do it.

Or hire us to do the Mac apps version. Plug, plug. [Chuckles]

Yeah, Exactly.

It’s nothing.

Pay someone else to be terrible

They have to go through the pain of banging their head on in the Sandboxing crap. I understand the safety model. The other great thing about it and the reason you pretty much want to be on the App Store if you can is because of the user credit cards. That’s not, to say, from the mercenary standpoint, these credit cards are good and people don’t like to put them in but it’s also much safer for you not to handle that data. If anybody stored any credit card data, you get a payment processor in your Mac to do your shopping experience in your website and have them store it. But still Apple has the cards and they’re a lot more secured there than they’re going to be with random payment processor X. Except FastSpring – I have to plug – because they’re awesome. [Chuckles]

Yeah. I was just going to say just one of my picks now is going to be FastSpring.

FastSpring is

FastSpring is the payment provider for AppViz and they were awesome all the time. They were great.

Any company that’s still scrappy enough where you can get the people who own it on the phone and talk about your problem, it’s definitely where you want a payment provider. We originally used PayPal and they were just –

Oh my god.

Old and dead. Do not use PayPal if you’re an indie software dev.

Did you know if you have a business account or if you have an account with PayPal that they’ll withhold some percentage on a rolling basis of your money and don’t give it to you?

They do that if you accept credit cards.

And that’s like 10 or 15%

Yeah. It’s really obnoxious.

Not only that. They denied – they put us to fraud because we build software that they didn’t understand. They denied us access to new APIs so I had to, one day, rewrite the APIs twice. I called them, they said they gave me verbal – I’d written the API to talk to them. I needed new features so I went to write a new version of the API against their pro-API. I called them and they said it’s in provisional approval. I wrote that. The next day when we were going live, they called me and said, “Nope, we’re not going to give you approval.” They shut off our API and we couldn’t roll back to the old one. I had to rewrite it again because there were some setting – I forget the exact reasons. So I had to write three versions in 24 hours. It’s just the whole – I hate PayPal. I can go on forever about how I hate them. [Chuckles]

I used PayPal for payment processing for a Mac app for quite a while and then switched to FastSpring.

Plus it’s super slow. The site sucked.

Yeah. Right, it was bad.

It’s always trying to put in just additional add-in.

Square is awesome.

FastSpring is relatively cheap on the other side. Even compared to PayPal, FastSpring is cheap. You make more of your money, right? That’s – when you’re small – that’s a big deal.

Well, it looks like their rates are higher but because they don’t withhold that money from you; it ends up being a better deal.

Plus it’s just such a better experience even for it’s more money to use it.

It’s so much better. [Chuckles]

I’m partial to Stripe myself.

Stripe is per se PayPal, too, a lot of the time.

Oh, yeah. Well.

When they’re not randomly seizing accounts for charities. Okay, I’ll let that go. It was like 10 years ago, wasn’t it?

No, they still do that kind of stuff. I definitely heard recently that kind of thing.

Alright. We’re getting to the point where I know somebody has to take off. So let’s go and get to the picks. Let’s have Andrew start off with picks.

Okay. I started out thinking I don’t have any picks today and now I’ve got too many picks to pick from. But I’m going to pick – first, relevant to this discussion we’ve just have, I’m going to pick FastSpring but I’m also going to pick this new thing that I think it’s real Mac has done in partnership with FastSpring called DevMate. If you’re going to sell a Mac app outside the App Store, one of the things that’s not so great about that compared to the App Store is you’ve got to come up with a licensing scheme. You have to build that into your app and you’ve got to do payment processing on your website. It’s not really that fun and it’s something that you’ve never done before, it takes a lot to figure out how you’re going to do that. Anyway, they’ve put together this service/SDK called DevMate that does a lot of that for you. It has analytics and crash reporting and all that kind of thing. I haven’t used it yet but it looks really cool.

That sounds phenomenal. I have to check that out after.

Then, secondly, I’m going to pick the API Diffs. As we record, WWDC is still going on. By the time the episode comes out, it’ll be over. My favorite way to learn about new stuff that maybe I wouldn’t hear about otherwise is just read the API Diffs. It sounds boring and nerdy and I guess it is but you’ll find little tidbits that aren’t mentioned in a session or even if they are mentioned, you didn’t see that session or something like. I was reading through them yesterday and I found a new method on NSString which I think maybe a wrapper for some existing core foundation. Anyway, it can convert between romanized Japanese and hiragana and katakana which is just cool. I know I would not have found that otherwise so read the API Diffs. They’re a little hard to go through this year because there are a lot of just minor changes that are auded just where they’re auding APIs for Swift. It’s still good stuff in there.

Then, lastly, I’m going to pick GOG.com. It’s Good Old Games.com. This is just a site that sells old games. They’ve got a lot of old DOS games and a lot of them even –

Also the Witcher 3.

Oh, yeah?

Yup.

Yup.

King’s Quest and they’ve got the old Sierra stuff on there.

Right, definitely. They’re using DOSBox backslash. There’s actually in that called Boxer – a Mac app that they partnered with a developer on. A lot of these DOS games you can download them from GOG.com. There are Mac apps so you can run them on your Mac even if it’s a DOS game. There are just a lot of cool great old games and they’re not very expensive either. Those are my picks.

Yeah, it’s like $5 for all the King’s Quest or something when I looked at it.

34]

I’m thinking “Man, that was most of my childhood.”

Those are all non-DRM, too.

Yeah, right.

And they’ll patch the games. Some of them, they’ve updated themselves. There are big companies. CD Projekt Red -- they just released the Witcher 3. That’s why it’s there. It is an awesome service site. I’m right there with you on that pick.

I love it. Those are my picks.

Alright. Mike, do you have some picks for us?

Yeah, two. First, go for Apple’s WWDC sample code. It’s a pretty sick site this year. In particular, I really like their Swift standard libraries sample code. It’s actually a playground that takes advantage of their multiple pages support and discussions, a lot of stuff with nice examples and shows you not only how to use a lot of the new stuff but also how to build nice playgrounds.

Then the second one, which I promise is vaguely relevant even though it doesn’t sound like it but bear with me. It’s witsradio.org. It’s a public radio show. The reason I bring it up is because one of their bits that they do occasionally is they do readings by actors of 1-star Amazon reviews. It’s classic literature which sounded like the kind of thing you get with certain bad app reviews. I think a live reading of bad app reviews on good apps would be fun little segment for somebody to do also.

I’m going to have to check that out. That sounds good.

Oh, man. That’d be a great 10-minute podcast weekly. I’d subscribe to that not that we know anyone who does podcasts.

Yeah, I wish you did. Alright, I’ve got a couple of picks. I’m picking this on all my shows and it’s more of a short rant than a pick. The political situation in the United States is heating up as people are stepping up and announcing their candidacy to be president. I just want to get people to go out and talk to people who they don’t necessarily agree with. This applies not only to politics but religion to different ways of coding things, different language preferences, library preferences, coding practices.

In the grand scheme of things, I find that most people I talk to when I don’t agree with people, we do have some common ground. I mean there are certain things that we both want. There are certain areas that we both agree on. In most cases – I won’t say in all cases because it’s not true – but most cases I find that, at some level, there’s a value or principle that I believe that they don’t or they believe that I don’t. If you build your case from there, you can see how a reasonable person will get to where they are. In a lot of cases, they find the same thing with me.

Instead of people yelling at each other over this stuff, I think if we sat down and talked about it, I think we can then start to have conversations about the things that are really important both in professionally and in life. Just come to understand what we do agree on and what we want. Anyway, it’s kind of a short little speech. Anyway, I think that’s really important for people to expand their horizons that way. It’s a healthy thing to do. You’ll find that, in a lot of cases, you think about things differently after you have those conversations.

Yeah, that’s the one pick. I also want to remind people about Ruby RemoteConf if you’re interested in Ruby. I think that’s all I’ve got.

Dylan, do you have some picks for us?

I do. I chose a couple things that I tend to use. First would be World Time Buddy. In no hyphens, it’s worldtimebuddy.com. They also have an app. I have to mention it because of just it’s similar to something that was recommended on the meeting email about meet at this time but it shows you a timeline. You can add different timelines with different time zones and you can line up; you select one of the times that selects the others in the time zone so you can take a list of any time zones in the world.

I think you have to pay for unlimited. I think, up to five is free. On their website you can see what a

time relates to which, since I did a lot of time zone stuff, it’d actually – because you can see them on one line and it doesn’t just spit out the answer what time is this in a different thing, it gives you an actual feeling for how the times line up which is very useful if you’re doing anything with date, time or trying to figure out when a meeting is. Worldtimebuddy.com, I’m a huge fan. They do have an ad in site. You could use some cleaning up but it does what it does pretty well.

The second recommendation I have something called Complice.co. That is a daily ToDo manager that’s based on taking your list of goals and breaking it up into a very simple every day. You go in and you type in “This is what I’m going to do today and this is the goal that it’s related to 12345.” Makes a really simple day app. It’s not heavy. It doesn’t have ticks, categorization, search and any of that stuff. It’s just what I’m going to do today. Then it lets you focus. It’s got a built-in Pomodoro timer if you’re into doing 20 minutes sprints so Pomodoro is a technique where you work for 30 minutes; you take a break for 10 minutes.

I find that more like an hour works better for me. It helps you focus on just the things that you’re going to do, just the important stuff you’re going to do today. It uses color-coding to tie those back to your bigger goals, your life goals, your personal goals. It helps you balance those things and then it takes the results of that every day you type in “Did I do enough on this thing?” It’s really simple. It’s fast to use. It’s faster than I’m making it sound.

You can do it over email so every day you reset your goals. I find that it helps focus my days. Not everybody works that way. I also use OmniFocus to keep track all the long running stuff. Complice helps you purpose your day and it’s really great for that. It really helps you do one thing. You’ll see it as this is just a simple idea but while using it, I got so much more done. It also tracks what you do over time so you can say, “Hey, over the last month I haven’t contributed enough to my fitness goal.”, for example. I really like that. That’s a new – it’s run by one guy. If you do a chat, you can chat with him on the side bar and he’s very responsive. It’s written in no jazz. It’s pretty well done.

So that and then Transmit from Panic. I just have to put on a plug here. It’s another app I use almost every day. Just a beautiful ftp. If you need to transfer files to anywhere, I think I t supports S3 and a bunch other stuff. On a repeated basis, it will get your files there. It’s a great experience. If you need to transfer stuff as often as I am, if you have to command line with scp, you should get this tool instead. Transmit. I’m sure they don’t really need the help. Panic’s a pretty big – [chuckles] I’m sure everybody’s heard of Panic.

Everybody loves panic.

Man, it is awesome. [Chuckles] Yeah, everybody loves it. The good guys can follow him on Twitter. But man, I use that every day. Those are my three picks.

Alright. Dustin, do you have some picks for us?

Yeah. Okay. The first one I had is xScope [inaudible] IconFactory and I don’t get a penny every time we sell one. It would have been my pick before I was at IconFactory. It felt like I got to say it. It was related to the design implementation. You guys are ever familiar with trying to find something that’s a couple of pixels off or trying to see what’s happening with the drop shadow or measure some screen or some screen shot, xScope is the Swiss army knife for UI developers. It really is all the tools that you need to make a design a reality other than, of course, your IDE.

I’m so in-love with xScope. It’s one of my favorite apps ever that opening it for the first time really felt like Christmas day for me because it solves a series of problems that otherwise are incredibly hard problems, hard measurement problems to solve. If you’re an iOS developer and you’re doing UI or if you’re a web developer, there’s great tools for responsive design and it just really is and indispensable Swiss army knife that you’re going to want in your pocket. It’s very affordable and it’s just wonderful. I could not do UI development the way I do without xScope or it would take me half again as long. It’s just wonderful.

My other one is Slack. Slack is – we’re a distributed team. There are some people in Minnesota but we work from home at Omaha. Slack is – I’m sure people have mentioned it before on this podcast but it has replaced the water cooler for us. It has replaced the proper measurement side of things almost completely. It is integrated with everything that could possibly think of using. We integrate it with Troll; we integrate it with git; we create channels for different projects for communicating with customers, for random channels where people can post pictures of gifs of kittens and get that social experience that we were missing working at home in isolation. We’re used to get up; go to the coffee shop; and talk to your fellow developers. Slack really is the ultimate chat replacement for that experience.

I’ve used HipChat. Slack is way better. [Chuckles]

Yeah, it is just indispensable for anyone who is on a team that needs to communicate. It’s just – buy it; pay for it. It’s wonderful and you will not regret it. Those are my two picks.

I love Slack. Alright. Well, thanks for coming. Guys, it was fun to chat. Lots of good stuff in here. [Crosstalk 1:03:51]

Thanks for having us meander all of –

Sorry if we meander around. We take up all the space. That’s what we do.

That was all good. Alright, we will wrap up the show.

If you guys are ever in Minnesota, come down, have coffee with us. We’ll do the same thing only in person. And it’s stereo. It’ll be one of us on each side of you talking at the same time. [Chuckles]

If I’m ever in Minnesota. I’ve never been there.

You should come up. It’s great here right now.

Come for the malls. Stay for the mall.

We have a big mall right here. Come see that and then come see us.

We have a panelist. He’s at WWDC right now. I think maybe you guys know him. Jaim?

Jaim. Yeah.

Oh, yeah, Jaim.

We know Jaim pretty well.

He’s a cool guy.

Someday we’ll have to have an iPhreaks get-together.

There we go. Alright. We will wrap the show. We’ll catch you on next week.