Under the Radar

00:00:00 ◼   ► Welcome to Under the Radar, a show about independent iOS development.

00:00:03 ◼   ► I'm Marco Arment.

00:00:05 ◼   ► And I'm David Smith.

00:00:06 ◼   ► Under the Radar is never longer than 30 minutes, so let's get started.

00:00:10 ◼   ► So today what we wanted to kind of unpack is the process that we go through when we're

00:00:17 ◼   ► building a feature out in an app.

00:00:19 ◼   ► It's not like the whole app itself, like starting from, I have this vague idea for something

00:00:23 ◼   ► and now let's go to Xcode and start a new project.

00:00:26 ◼   ► But as a product, as an app develops and gets better over time, you're going to inevitably

00:00:33 ◼   ► have these little like, huh, here's this feature I have, here's this thing that I want to do,

00:00:38 ◼   ► and I want to add it in.

00:00:41 ◼   ► And the way in which you go about that is something that requires a different kind of

00:00:46 ◼   ► level of concern or planfulness than just starting from scratch.

00:00:49 ◼   ► Because obviously, A, you're smooshing it into an existing piece of code, and also just

00:00:54 ◼   ► the constraints around what you're doing are different.

00:00:58 ◼   ► And recently I ran into something where I thought it was an interesting kind of progression

00:01:00 ◼   ► that I found that I was going through.

00:01:02 ◼   ► When I was adding a feature to sleep++, which is my Apple Watch sleep tracker, basically

00:01:07 ◼   ► I wanted to be able to record your night's activity and you end up with a graph of how

00:01:12 ◼   ► well you slept.

00:01:13 ◼   ► And people asked, a feature I got many, many times was like, "I want to be able to trim

00:01:16 ◼   ► the night at the end of..."

00:01:17 ◼   ► It says, "If I wake up in the morning and I don't stop it right when I wake up," I wanted

00:01:21 ◼   ► to say, actually, I woke up at this time.

00:01:24 ◼   ► Seems a very reasonable feature.

00:01:26 ◼   ► The thing that I found as interesting

00:01:27 ◼   ► as I went through the process of building this out--

00:01:29 ◼   ► and so now it's basically a part of the app--

00:01:32 ◼   ► is I tend to go kind of--

00:01:34 ◼   ► I start off with, like, huh, that's an interesting idea.

00:01:37 ◼   ► How would I build that?

00:01:38 ◼   ► And then I tend to work a little--

00:01:41 ◼   ► it's like from the bottom up and the top

00:01:43 ◼   ► down when I'm working on a feature like this, which

00:01:45 ◼   ► it seemed kind of funny.

00:01:47 ◼   ► I started the data level and start being like,

00:01:48 ◼   ► what data would I need to record?

00:01:50 ◼   ► How would I record that?

00:01:51 ◼   ► what migrations do I need to do in my database, what changes will I have to make there?

00:01:54 ◼   ► And I start building the basic structure for that on the bottom.

00:01:58 ◼   ► And then I start on the top down in a really simplistic way.

00:02:01 ◼   ► I start off with what's the UI going to look like, but I don't actually build that UI.

00:02:05 ◼   ► I just take whatever stock control I can find, like I think in this case I took a UI slider,

00:02:10 ◼   ► threw it into Interface Builder, hooked it up to that, applied a transform to it because

00:02:15 ◼   ► I needed it to slide vertically, so I just rotated it by 90 degrees, and that was my

00:02:20 ◼   ► basic control. Eventually I ended up replacing that with a whole custom UI and all kinds

00:02:24 ◼   ► of things like that. But starting in that sort of top-down, as simple as I can on the

00:02:29 ◼   ► UI side, and then as robust as I can on the bottom side, is something that seems to work

00:02:34 ◼   ► for me. And it's an approach though that I found that if I can't end up with something

00:02:40 ◼   ► that I can use and can start playing with quickly, that's why sort of the top-down

00:02:43 ◼   ► is important from like just really basic simple UI, I really struggle with actually getting

00:02:48 ◼   ► anything's done.

00:02:50 ◼   ► Do you have a similar experience?

00:02:52 ◼   ► - For me, any feature that I want to build,

00:02:57 ◼   ► I always just build it as quickly as I can

00:03:00 ◼   ► and start using it myself.

00:03:01 ◼   ► My process, we talked a little bit about betas

00:03:04 ◼   ► in previous episodes and everything,

00:03:06 ◼   ► my process for testing out features is really,

00:03:10 ◼   ► I just test them out myself for as long as I can

00:03:12 ◼   ► before I show them to anybody else at all.

00:03:15 ◼   ► Before I even send them to beta testers usually.

00:03:17 ◼   ► Overcast, I mentioned last in last episode, I mentioned that that voice boost started

00:03:23 ◼   ► out as as having different levels. It was not just an on or an off switch. It actually

00:03:27 ◼   ► had multiple modes. And I lived with that for months before I showed anybody else before

00:03:34 ◼   ► the beta started and everything. And I really I did a similar thing. I mean, like, you know,

00:03:39 ◼   ► my UI for controlling these things is mostly just stock UI kit. I very rarely make custom

00:03:44 ◼   ► controls or when I do they're usually pretty lightweight subclasses of the built in buttons

00:03:50 ◼   ► and labels and slider and stuff like that. Or they might just be a slight wrapper with

00:03:57 ◼   ► one of those as a subview and a few other labels here and there. But for the most part

00:04:03 ◼   ► I'm using mostly stock stuff because you can get really really far with stock components

00:04:09 ◼   ► in UIKit especially with all the custom appearance stuff that they've added in the last few OS

00:04:13 ◼   ► Really, I have found very little reason to really build out tons of custom control stuff

00:04:20 ◼   ► and I've instead focused on just skinning UIKit well.

00:04:24 ◼   ► And so when I built these features, I mean, Voice Boost as I mentioned, it used to have

00:04:30 ◼   ► four levels.

00:04:31 ◼   ► It used to be off, reduce, enhance, and boost.

00:04:36 ◼   ► And I was about to launch with this.

00:04:38 ◼   ► I really thought this was going to be what I launched with.

00:04:40 ◼   ► And I had rationales for all of them.

00:04:43 ◼   ► So the reduce mode would actually cut off, it was actually a high pass and a low pass

00:04:48 ◼   ► filter, it would actually cut off big chunks of the top and bottom end for podcasts that

00:04:53 ◼   ► were produced with flaws, with either way too much bass or sometimes, sometimes podcasts

00:04:59 ◼   ► would have like very high pitched noise and so I thought a reduce mode would actually

00:05:05 ◼   ► be useful.

00:05:06 ◼   ► And then the volume boosting modes, I actually had two.

00:05:10 ◼   ► I had enhance and boost.

00:05:12 ◼   ► And it was just two different degrees of the same thing, really, of the EQ and the compression,

00:05:17 ◼   ► and with boost being a much more aggressive compression setting.

00:05:20 ◼   ► What I found in the beta was people were very confused by this because it just labeled dynamics.

00:05:25 ◼   ► Reduce off enhance boost.

00:05:26 ◼   ► It's like, okay, what does dynamics mean?

00:05:29 ◼   ► You know, it's just somebody who is not an audio engineer.

00:05:32 ◼   ► Is that referring to motion?

00:05:33 ◼   ► Like, it was a very confusing thing.

00:05:36 ◼   ► People were confused as to why they would ever want

00:05:38 ◼   ► to reduce the dynamics of something.

00:05:40 ◼   ► And between enhance and boost, well what does that mean?

00:05:43 ◼   ► Is this like enhance like CSI,

00:05:45 ◼   ► where you're uncovering detail

00:05:46 ◼   ► that is magically there somehow?

00:05:48 ◼   ► You know, and it doesn't really communicate

00:05:50 ◼   ► that enhance and boost are basically

00:05:51 ◼   ► two different dynamics of the same thing.

00:05:54 ◼   ► It was a very confusing feature.

00:05:57 ◼   ► And I didn't, you know, I mentioned last time,

00:05:59 ◼   ► I didn't see the confusing aspect of it because I made it.

00:06:02 ◼   ► And so I knew what it was.

00:06:04 ◼   ► I didn't have to explain to myself what it was.

00:06:07 ◼   ► My testers started seeing this and seeing

00:06:09 ◼   ► that it was probably not ideal.

00:06:12 ◼   ► One day during testing, I just mocked up

00:06:14 ◼   ► a quick little thing where I realized

00:06:16 ◼   ► that I was just leaving it in Boost most of the time

00:06:18 ◼   ► because after trying the other options here and there

00:06:20 ◼   ► during development, I discovered that Boost

00:06:23 ◼   ► was just the best one.

00:06:25 ◼   ► And that's the way I wanted to leave almost everything.

00:06:27 ◼   ► I almost never wanted any of the other options.

00:06:30 ◼   ► So that's when I decided, you know what,

00:06:31 ◼   ► I'll solve two problems.

00:06:32 ◼   ► I'll solve the intuitiveness problem

00:06:35 ◼   ► and the UI understandability problem

00:06:38 ◼   ► with what this feature actually is.

00:06:40 ◼   ► And I don't actually want these other modes.

00:06:44 ◼   ► In practice, I find out this isn't that important,

00:06:46 ◼   ► so I'll cut those features.

00:06:47 ◼   ► I'll make it one button.

00:06:48 ◼   ► It's either boost on or off,

00:06:50 ◼   ► and I call it voice boost,

00:06:51 ◼   ► mostly because it was being next to smart speed,

00:06:53 ◼   ► so it needed two words

00:06:55 ◼   ► 'cause it would look weird if it only had one.

00:06:57 ◼   ► This is how I make feature decisions.

00:06:59 ◼   ► - Important. - Yeah, yeah.

00:07:01 ◼   ► And that's how that feature came to be.

00:07:03 ◼   ► And I'll see if I can put a link in the show notes.

00:07:06 ◼   ► I always take screenshots along the way

00:07:09 ◼   ► of designing the app.

00:07:10 ◼   ► And so I have this whole history of how the app looked

00:07:13 ◼   ► in various stages of development

00:07:15 ◼   ► and while prototyping various features.

00:07:17 ◼   ► And so I actually have a screenshot of it

00:07:18 ◼   ► with these four features

00:07:19 ◼   ► and I'll show you the effects pane with this

00:07:21 ◼   ► and then you can see how the one I went with

00:07:24 ◼   ► with just the two big buttons was so much simpler.

00:07:27 ◼   ► That's a very long-winded way of saying

00:07:30 ◼   ► that I kind of evolve features as much as I can,

00:07:34 ◼   ► both using it myself and then showing beta testers

00:07:37 ◼   ► before they ever get to the public.

00:07:40 ◼   ► And I think it's very important,

00:07:42 ◼   ► not only to have that process when adding features,

00:07:46 ◼   ► but also to really consider, like,

00:07:49 ◼   ► you know, if I had released this

00:07:51 ◼   ► the way I originally had it

00:07:52 ◼   ► with these four different options,

00:07:54 ◼   ► and then later decided what I decided during the beta

00:07:56 ◼   ► that, you know, this actually should really

00:07:57 ◼   ► just be one thing,

00:07:59 ◼   ► then that's a feature removal to a lot of people

00:08:01 ◼   ► who use the other ones.

00:08:02 ◼   ► And you gotta go into that very carefully.

00:08:06 ◼   ► And I'm not one to avoid feature removals.

00:08:09 ◼   ► I have often angered people by removing features,

00:08:13 ◼   ► but it is a lot harder to remove features politically

00:08:17 ◼   ► after you've already shipped them to people.

00:08:18 ◼   ► So I think one thing to also consider is like,

00:08:21 ◼   ► how do you remove a feature from an app?

00:08:23 ◼   ► And how do you decide when to do that?

00:08:27 ◼   ► When is the right time to do that?

00:08:29 ◼   ► and how do you manage user expectations

00:08:32 ◼   ► and user feelings about that?

00:08:34 ◼   ► - Yeah, and I think it also speaks a little bit to

00:08:36 ◼   ► one of the, something that you have to get used to is

00:08:40 ◼   ► that you are inevitably going to build features

00:08:42 ◼   ► that won't ship, that you're gonna build stuff

00:08:46 ◼   ► that ultimately just doesn't work out,

00:08:49 ◼   ► and I think there's a certain amount of just like

00:08:52 ◼   ► distancing yourself from your work enough

00:08:54 ◼   ► that you can look at it, like I've really definitely

00:08:56 ◼   ► gone down this path where I'm thinking,

00:08:57 ◼   ► hey, this would be an awesome new feature.

00:08:59 ◼   ► And especially this is dangerous

00:09:01 ◼   ► when it's a really interesting technical problem.

00:09:04 ◼   ► It's like I think I have this really cool solution

00:09:05 ◼   ► to a problem.

00:09:07 ◼   ► I go down the path and I start adding all these features

00:09:10 ◼   ► and it's like building it all out.

00:09:11 ◼   ► And you get to the end and you're just like,

00:09:13 ◼   ► it's a really interesting solution to a problem

00:09:15 ◼   ► that people don't actually have.

00:09:17 ◼   ► Or it makes the gap really harder to understand

00:09:20 ◼   ► or more complicated or less intuitive.

00:09:23 ◼   ► And at the end being able to say like,

00:09:25 ◼   ► you know, I just need to throw this away.

00:09:27 ◼   ► like that's a dead end, that is just not gonna go anywhere.

00:09:32 ◼   ► And having done that now so many times

00:09:35 ◼   ► where I'll create this branch, go down it,

00:09:38 ◼   ► and then end up deciding that this is actually

00:09:39 ◼   ► not gonna work, I'm just gonna throw it away,

00:09:42 ◼   ► is definitely an encouragement and a reminder

00:09:44 ◼   ► to not spend too much time on things,

00:09:46 ◼   ► in terms of trying to quickly get to a point

00:09:49 ◼   ► that you can really evaluate how useful something is.

00:09:53 ◼   ► Because there's so many things that in my head

00:09:55 ◼   ► sounds like they'll be really cool and really fun, and when you implement them, they aren't

00:10:01 ◼   ► actually as useful as you think.

00:10:02 ◼   ► Or the more good and bad situation is when you'll show it to somebody, and you'll give

00:10:08 ◼   ► them something to react to, and their response is like, "Huh, that's interesting.

00:10:13 ◼   ► Why doesn't it just do this?"

00:10:15 ◼   ► And it's sort of like there's this clarifying simplification that you're just not seeing

00:10:20 ◼   ► because you're deep down in the weeds of the coolness of the feature or on this particular

00:10:27 ◼   ► track, and it turns out a much better solution is, in this case, with voice boost.

00:10:33 ◼   ► The dynamics and things, I think, these are really interesting options that you could

00:10:38 ◼   ► kind of go down, but at the end, really what people want is to make it louder so they can

00:10:43 ◼   ► hear voices clearer.

00:10:45 ◼   ► And so you just need on and off, and that's probably good enough.

00:10:49 ◼   ► and you have to be willing to say like,

00:10:50 ◼   ► you know all the other stuff that I was doing,

00:10:52 ◼   ► like the really sophisticated dynamic stuff,

00:10:55 ◼   ► it's like, okay, maybe I just don't ship that

00:10:57 ◼   ► because it's just gonna make it more confusing

00:10:59 ◼   ► rather than actually better for most people.

00:11:02 ◼   ► - Right, 'cause it was exactly the kind of thing

00:11:04 ◼   ► where it was technically interesting,

00:11:06 ◼   ► it was technically impressive,

00:11:08 ◼   ► not a lot of podcast apps have enhanced dynamics

00:11:11 ◼   ► and EQ controls and everything,

00:11:13 ◼   ► so it was like a cool thing to do

00:11:16 ◼   ► if I would have shipped that

00:11:17 ◼   ► because it was kind of like showing off my audio engine

00:11:20 ◼   ► and my audio manipulation skills, I guess.

00:11:23 ◼   ► But in reality, that was really just showing off

00:11:26 ◼   ► for my benefit and it was not like,

00:11:29 ◼   ► it was actually, it would be making the app worse

00:11:32 ◼   ► to ship it that way because it was more confusing,

00:11:34 ◼   ► because as you said, like not a lot of people

00:11:36 ◼   ► really had that problem very often.

00:11:38 ◼   ► Not even I had the problem often enough

00:11:40 ◼   ► to use my own feature very much.

00:11:42 ◼   ► So it really does take a lot of editing

00:11:45 ◼   ► And I feel like there's a good balance to be struck here

00:11:48 ◼   ► between, like the way I do it, I move pretty slowly.

00:11:52 ◼   ► And like, you know, with streaming, like I was,

00:11:55 ◼   ► I had streaming working to varying degrees of work,

00:11:59 ◼   ► probably three months before I shipped it,

00:12:02 ◼   ► but I wanted that very long testing period

00:12:04 ◼   ► because I wanted to be very conservative with it

00:12:05 ◼   ► and to have a lot of time just using it on my own phone

00:12:08 ◼   ► before I even gave it to testers, let alone to the public.

00:12:11 ◼   ► And on the other side, the other extreme of this,

00:12:15 ◼   ► of the feature deployment speed here,

00:12:18 ◼   ► is the continuous release paradigm,

00:12:22 ◼   ► where you just ship something out there

00:12:24 ◼   ► as quickly as you possibly can,

00:12:25 ◼   ► as soon as you have the idea for it,

00:12:27 ◼   ► and see if it takes, maybe do some A/B testing,

00:12:29 ◼   ► or see what people's reactions are.

00:12:31 ◼   ► I feel like the better balance

00:12:33 ◼   ► is somewhere in the middle of those things.

00:12:34 ◼   ► I feel like I move too slowly the way I do things,

00:12:37 ◼   ► but something like that,

00:12:38 ◼   ► where you're constantly adding or moving things,

00:12:41 ◼   ► First of all, it makes it harder to remove things.

00:12:43 ◼   ► And second of all, I think you increase

00:12:47 ◼   ► the annoyance rate of your users,

00:12:50 ◼   ► like when you do things, like when Twitter

00:12:52 ◼   ► rolls out a new feature and it goes out

00:12:53 ◼   ► to a random subset of people first.

00:12:55 ◼   ► And everyone else hears about it,

00:12:57 ◼   ► and like, wait, why don't I have this?

00:12:58 ◼   ► Or why is my timeline all of a sudden different?

00:13:00 ◼   ► Or why does this not work the way I expect it to

00:13:03 ◼   ► and everyone else's works fine?

00:13:04 ◼   ► These two extremes of how often you ship things,

00:13:07 ◼   ► how much testing you do internally

00:13:10 ◼   ► versus just shipping to the public

00:13:11 ◼   ► and seeing what they think first.

00:13:13 ◼   ► There is a healthy balance to be struck

00:13:14 ◼   ► between those two extremes.

00:13:16 ◼   ► I haven't struck it, but I think I would rather be,

00:13:19 ◼   ► if I'm gonna be unbalanced in that way,

00:13:22 ◼   ► I think I'd rather be unbalanced in the direction that I am,

00:13:24 ◼   ► which is on the side of being too conservative and too slow,

00:13:28 ◼   ► because ultimately I want my app to always have a reputation

00:13:31 ◼   ► of being carefully considered.

00:13:34 ◼   ► - Yeah, and I think, honestly, that the App Store itself

00:13:38 ◼   ► structured such that you can't do continuous release in a functional way, because your

00:13:45 ◼   ► app always has to go through app review, which can take a non-deterministic amount of time,

00:13:51 ◼   ► at least about a week. And you have to be able to—you can only ship things to the

00:13:55 ◼   ► store that you can live with for at least a week, probably, which, depending on the

00:14:02 ◼   ► kind of change that you're rolling out and the significance of it, or if there's a

00:14:06 ◼   ► problem with it.

00:14:08 ◼   ► You have to have a certain amount of conservatism to make sure that you're not putting something

00:14:11 ◼   ► out there that is going to be very problematic for your product that if for a week it's horribly

00:14:17 ◼   ► broken or really confusing, you can't just change that.

00:14:22 ◼   ► Continuous deployment and things works great for an app, like a web app or something that

00:14:25 ◼   ► you can change in real time.

00:14:28 ◼   ► Or if you're in the Google Play Store, for example, you can do something like that a

00:14:31 ◼   ► lot more there because you can roll out updates more quickly.

00:14:35 ◼   ► But in general, it's definitely something that you have to be thoughtful about and understand

00:14:39 ◼   ► that it's going to -- this is going to go out, and you have no control over necessarily

00:14:44 ◼   ► when someone's going to be able to change.

00:14:47 ◼   ► And so, I mean, you can certainly go down the crazy roads where you have AB testing

00:14:51 ◼   ► built into your app and it has multiple code paths and things, but that just seems like

00:14:55 ◼   ► a nightmare to me.

00:14:57 ◼   ► But it's definitely something that I think I'm more on the release things quicker approach.

00:15:03 ◼   ► I tend to bite off nice small things, focus on them, get them working, and then put it

00:15:11 ◼   ► out there.

00:15:13 ◼   ► In general, I think that seems to work for me, and I think mostly it's something that

00:15:16 ◼   ► even is just an attention span thing.

00:15:18 ◼   ► I really struggle to...

00:15:19 ◼   ► When I hear you talking about working on features for months, that is really intimidating to

00:15:25 ◼   ► me because I think I would lose interest.

00:15:29 ◼   ► I get something working, all the crazy edge cases are harder for me to have the discipline

00:15:34 ◼   ► to track down, and so I tend to just focus and simplify the problem down to a point that,

00:15:38 ◼   ► "Oh, look, all the edge cases seem to have sort of fallen off as best I can," which

00:15:43 ◼   ► is a different kind of approach, but I found kind of works for me.

00:15:47 ◼   ► Well, I mean, honestly, that's probably the more healthy approach, is to ship something

00:15:51 ◼   ► that is smaller but complete and ship that faster, rather than wait until you have something

00:15:59 ◼   ► that is complete but is big and sprawling,

00:16:02 ◼   ► and then that takes six months.

00:16:05 ◼   ► I think your approach there is probably the healthier one.

00:16:08 ◼   ► - Yeah, but it requires, I guess,

00:16:10 ◼   ► and some of it too, maybe,

00:16:12 ◼   ► it's the interesting thing of trying to decide,

00:16:15 ◼   ► I'm just interested in a direction

00:16:16 ◼   ► to shift the conversation to,

00:16:17 ◼   ► is how we decide what features to add,

00:16:21 ◼   ► I think is a really,

00:16:22 ◼   ► it's a very complicated set of variables

00:16:26 ◼   ► that I find that I'm balancing for these days,

00:16:28 ◼   ► where on the one hand you have the desire to make something good, to ship a good product,

00:16:34 ◼   ► to ship software that's useful, that people like, you have the constraint that you're

00:16:39 ◼   ► trying to optimize for around business model and business plan, like will adding this feature

00:16:45 ◼   ► increase the number of people who are using my app or paying for my app or in some way

00:16:51 ◼   ► contributing to the bottom line of my business, is this feature something that's going to

00:16:55 ◼   ► motivate me and make me interested. And trying to balance the tension between those is, I

00:17:01 ◼   ► think, definitely more art than science. Because at least I haven't found a good way to really

00:17:08 ◼   ► know that other than just like, "This feels right." Every now and then I'll get asked by people,

00:17:13 ◼   ► like, "How do I plan releases? Do I sit down?" It's not like I want to do some kind of waterfall

00:17:19 ◼   ► think, but do I have a big release plan like you probably need to have if you were trying

00:17:24 ◼   ► to apply a team of developers onto something? And it's like, I tend to just sit down and

00:17:29 ◼   ► look at my apps and be like, "What could be made better? What would I enjoy building?"

00:17:34 ◼   ► And then think about, "Huh, I suppose that might make people like the app more," and

00:17:37 ◼   ► then go with it. But then also, more often than not, I'll look at an app and be like,

00:17:42 ◼   ► "The app's kind of done. Maybe I should just leave it and move on to the next app." And

00:17:47 ◼   ► I guess that's why I end up with so many apps, but trying to decide what feature is worth

00:17:51 ◼   ► actually doing is really hard.

00:17:54 ◼   ► Deciding when an app is basically done or doesn't need massive attention for at least

00:17:59 ◼   ► a little while, that is a skill that I think iOS developers need.

00:18:04 ◼   ► And many of us, myself included, often don't do it right or don't have that skill, because

00:18:10 ◼   ► the economics of iOS are such that you really do have a much better chance of success if

00:18:16 ◼   ► if you have multiple apps and the additional value

00:18:20 ◼   ► that you will get, sales-wise or money-wise,

00:18:23 ◼   ► the additional value you will get out of doing

00:18:26 ◼   ► a big feature update to an existing app

00:18:29 ◼   ► might not be worth the effort that it will require

00:18:32 ◼   ► to be put into that to do.

00:18:34 ◼   ► And a lot of people want the model of just having one app

00:18:39 ◼   ► that they work on forever, well not forever,

00:18:42 ◼   ► but one app that they pour tons of time into

00:18:44 ◼   ► polishing everything up and being able to live off

00:18:47 ◼   ► just that one app.

00:18:48 ◼   ► And that is very rare to actually have that

00:18:52 ◼   ► in the app store and to be successful at that.

00:18:55 ◼   ► Not because Apple is keeping us all down or anything,

00:18:59 ◼   ► but because in most cases, most apps,

00:19:04 ◼   ► you hit a wall of diminishing returns where like,

00:19:07 ◼   ► most people's needs are satisfied by it,

00:19:11 ◼   ► who will find it and who will want it

00:19:13 ◼   ► and who will pay for it.

00:19:14 ◼   ► most people's need to get satisfied pretty early on

00:19:16 ◼   ► in development and then you're just kinda like

00:19:18 ◼   ► adding stuff just really for your benefit,

00:19:21 ◼   ► trying to make the app better to boost sales

00:19:24 ◼   ► or to get more press at some point

00:19:25 ◼   ► or to get upgrade revenue maybe.

00:19:28 ◼   ► Whereas the customers really aren't

00:19:31 ◼   ► in great need of those things.

00:19:32 ◼   ► And the best example of that kind of thing

00:19:33 ◼   ► is Microsoft Office.

00:19:34 ◼   ► And you see like over time,

00:19:36 ◼   ► all the challenges Microsoft faced over the last 20 years

00:19:40 ◼   ► of just trying to get people to buy Office upgrades.

00:19:44 ◼   ► And when everyone's sitting around saying,

00:19:46 ◼   ► you know what, Microsoft Word's been working fine for me,

00:19:48 ◼   ► I don't really need anything else,

00:19:50 ◼   ► please don't add anything else,

00:19:52 ◼   ► 'cause every time I upgrade,

00:19:53 ◼   ► I pay this large amount of money,

00:19:54 ◼   ► and then everything gets slower,

00:19:56 ◼   ► and some things are different,

00:19:57 ◼   ► and I have to retrain myself or my staff.

00:19:59 ◼   ► And so you have customers who are actually asking you,

00:20:01 ◼   ► please don't upgrade this.

00:20:03 ◼   ► So I feel like if you take lessons

00:20:05 ◼   ► from the industry in the past,

00:20:07 ◼   ► you can kind of see, a lot of times,

00:20:10 ◼   ► given limited resources and limited time that you have

00:20:12 ◼   ► as an individual or as a small company,

00:20:15 ◼   ► doing an upgrade to a product for the sake of upgrading it

00:20:19 ◼   ► is not necessarily the best use of your time.

00:20:20 ◼   ► And you, David, you have, I think,

00:20:23 ◼   ► a very good sense of that.

00:20:25 ◼   ► Possibly even an overly aggressive sense of that,

00:20:27 ◼   ► but I think it serves you very well in that

00:20:30 ◼   ► you don't seem to pour a lot of effort

00:20:32 ◼   ► into massive upgrades to apps

00:20:35 ◼   ► that don't necessarily warrant them,

00:20:36 ◼   ► and you are very happy to try new apps

00:20:38 ◼   ► way more often than most people I know.

00:20:41 ◼   ► - Yeah, and I think some of it is coming from understanding

00:20:44 ◼   ► that I remember a few years ago,

00:20:47 ◼   ► I had the realization that the way we version number

00:20:52 ◼   ► our apps is sort of, in some ways, somewhat,

00:20:57 ◼   ► it's kind of arbitrary that we tend to do this concept

00:21:01 ◼   ► of a major update, and then you have minor updates,

00:21:04 ◼   ► and then you have bug-fic updates,

00:21:05 ◼   ► like you have 2.1.6 or something, and it's coming from a world where you made your money

00:21:13 ◼   ► only on major updates.

00:21:16 ◼   ► And so you had to kind of create this sense of you put out a major update to get a bunch

00:21:22 ◼   ► of money, and then you do minor updates in many ways to build goodwill, and bug fix updates

00:21:28 ◼   ► just to fix things, but you do these minor updates to build goodwill with your customers.

00:21:33 ◼   ► They have this feeling of like, they bought this basic thing, and then hey, they got this

00:21:38 ◼   ► other stuff for free.

00:21:39 ◼   ► Like they got all these minor updates, these other improvements for free.

00:21:42 ◼   ► And then you come around and it's like, alright, now it's time to shake the money tree again,

00:21:47 ◼   ► and so here's version 2.

00:21:50 ◼   ► And now it's like, alright, now all that goodwill I had, I'm kind of cashing it in and saying,

00:21:55 ◼   ► please give me some money again.

00:21:57 ◼   ► And you have to have some kind of feature or some kind of thing that you're able to

00:22:01 ◼   ► to point to and say, "This is why you should pay me money now." But in the App Store, and

00:22:06 ◼   ► at least in the way the App Store economics work, that isn't actually the reality anymore.

00:22:11 ◼   ► That it isn't a situation where most of my apps don't make any substantial—like, when

00:22:17 ◼   ► I do a major update, I see a little bump, maybe, in revenue, but overall it's really

00:22:23 ◼   ► just about sustaining and maintaining a level of revenue in the long run. And that changes

00:22:29 ◼   ► a lot that mentality that like the version numbers of my apps are in some ways kind of

00:22:32 ◼   ► arbitrary like they're almost more just marketing things like if I'm trying to get the attention

00:22:36 ◼   ► of the press then I may call it a bigger number but I could also just call it version one

00:22:41 ◼   ► version two version three version four and it would be just as descriptive as far as

00:22:45 ◼   ► my customers are concerned.

00:22:48 ◼   ► Yeah I find the same thing with you know with paid apps especially where like you know if

00:22:52 ◼   ► If you, the massive version number change is really good for press but in sales, the

00:23:00 ◼   ► sales can result from that press, you get a little sales bump sometimes but I've always

00:23:04 ◼   ► found that whenever I've done major updates to apps, this is going all the way back to

00:23:09 ◼   ► Instapaper certainly Overcast, whenever I've done like significant feature updates or major

00:23:13 ◼   ► like X.0 updates, there is a bump but it's a pretty small bump in sales and every major

00:23:21 ◼   ► version bump is smaller than the one that came before it.

00:23:26 ◼   ► So I think you're right, it really is about maintenance.

00:23:29 ◼   ► You are keeping the app up to date, you are keeping it competitive in a competitive field,

00:23:35 ◼   ► you are keeping users interested, but I don't think any of those things require major X.O

00:23:42 ◼   ► updates really ever necessarily.

00:23:46 ◼   ► You can add moderate scale features over time as they come and achieve most of that same

00:23:51 ◼   ► We are sponsored this week by Imageix. Imageix.com/utr for under the radar. Imageix is basically

00:24:00 ◼   ► an image CDN that they serve your images but you can do operations on them. So you can

00:24:06 ◼   ► resize them, you can translate their formats, you can scale and crop and twist and change

00:24:13 ◼   ► the colors and do everything that you can add annotations to them. The number of operations

00:24:18 ◼   ► you can do on these images simply by adding URL parameters and signing the URLs is incredible.

00:24:26 ◼   ► I mean, you can resize them to any dimension of course, you can crop, you can letterbox,

00:24:31 ◼   ► any kind of resizing needs you have they can do it. But you can also, as I said, you can

00:24:34 ◼   ► do things like blur filters, you can do all sorts of special effects, you can adjust the

00:24:39 ◼   ► colors, the toning, you can really do quite a bit with ImageX. I use it myself for Overcast

00:24:46 ◼   ► and I've been very impressed with it.

00:24:48 ◼   ► It is very, very fast.

00:24:50 ◼   ► Overall, I would say ImageX is really worth looking at

00:24:54 ◼   ► if you need image manipulation either for your app

00:24:57 ◼   ► where you're pulling images off the web,

00:24:59 ◼   ► you need to do something with them into an app,

00:25:01 ◼   ► or for web pages, it's especially nice for web pages

00:25:05 ◼   ► because you can do things like serve responsive images,

00:25:07 ◼   ► serve different resolutions to different browsers.

00:25:09 ◼   ► There are lots of libraries,

00:25:11 ◼   ► if you want to use client libraries,

00:25:13 ◼   ► they have lots of those including one for Swift

00:25:15 ◼   ► called Iris, which is from the developers over at Hodinkee.

00:25:18 ◼   ► And if you look at, Hodinkee is a watch website,

00:25:21 ◼   ► like a watch enthusiast website,

00:25:23 ◼   ► and they have beautiful imagery all over the site,

00:25:27 ◼   ► and that's all powered by ImageX,

00:25:28 ◼   ► so you can see a great example

00:25:29 ◼   ► of all the things it can do there.

00:25:30 ◼   ► Anyway, check it out today.

00:25:32 ◼   ► ImageX.com, that's I-M-G-I-X.com/UTR.

00:25:36 ◼   ► Thanks a lot to ImageX for sponsoring our show.

00:25:39 ◼   ► - All right, and Hank, in closing down this,

00:25:42 ◼   ► one thing that I was trying to think through

00:25:44 ◼   ► is the concrete example of the best kind of features to add to an app.

00:25:51 ◼   ► And the thought that came to mind is something that they'll talk about in video gaming,

00:25:56 ◼   ► when you're doing, like, they'll be doing a patch or an update to an app, or to the

00:26:01 ◼   ► game, and they'll call them "quality of life improvements," which are changes that

00:26:05 ◼   ► don't change the fundamental nature of your app, or of the game in this case, but are

00:26:10 ◼   ► things that make using it better.

00:26:13 ◼   ► Like it's just a quality of life thing.

00:26:14 ◼   ► It makes doing this operation that used to be kind of annoying or complicated or awkward

00:26:20 ◼   ► simple or more straightforward.

00:26:22 ◼   ► And like that kind of quality of life update, when I'm looking at an app that I have and

00:26:26 ◼   ► I'm trying to think of what are features I need to add, the first thing that I always

00:26:30 ◼   ► try and think through and I think is a great place to start is like are there any quality

00:26:33 ◼   ► of life improvements I can do?

00:26:35 ◼   ► Is there some operation right now that is common and frequent but awkward and annoying?

00:26:40 ◼   ► And if I can find anything like that, that is by far the low-hanging fruit that I need

00:26:44 ◼   ► to make sure that I'm taking care of before I worry too much about inventing new problems

00:26:50 ◼   ► to solve.

00:26:51 ◼   ► Like, are there existing problems that I have that the app solves, but solves in a way that

00:26:56 ◼   ► I can make better?

00:26:58 ◼   ► And if I do that, that's where I think you get the most bang for your buck.

00:27:01 ◼   ► And that's where building features out and doing these little improvements that you can

00:27:05 ◼   ► you can ultimately, you can over time make your app

00:27:09 ◼   ► just more, better and better without making it

00:27:11 ◼   ► more and more complicated, or more and more sprawling.

00:27:16 ◼   ► - All right, thanks a lot for listening this week.

00:27:18 ◼   ► Please recommend us on Overcast if you get a chance,

00:27:20 ◼   ► help spread the show, tell a friend,

00:27:22 ◼   ► we'd love to get more listeners to the show.

00:27:25 ◼   ► And if you wanna support our network and us at Relay FM,

00:27:28 ◼   ► Relay FM just launched memberships recently,

00:27:31 ◼   ► so you can pay money optionally to any Relay FM show

00:27:35 ◼   ► or to all of Relay FM shows.

00:27:37 ◼   ► If you wanna just give like a nice

00:27:38 ◼   ► basically monthly donation to us.

00:27:40 ◼   ► We'd appreciate that if you feel like it,

00:27:41 ◼   ► if not, no big deal.

00:27:42 ◼   ► Thanks a lot to Imageous for sponsoring.

00:27:44 ◼   ► And yeah, thank you all for listening,

00:27:46 ◼   ► and we'll talk to you next week.

00:27:48 ◼   ► - Bye.

00:27:49 ◼   ► [