Under the Radar

7: Building New Features


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   [