Under the Radar

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

00:00:04 ◼   ► 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, in the summertime here after a big new iOS release like we have at WVDC every

00:00:16 ◼   ► year, one of the decisions that we have to face as developers is when upgrading our existing

00:00:21 ◼   ► apps to the new OS.

00:00:24 ◼   ► And if you assume that you're only right into the new OS and you don't have to worry about

00:00:28 ◼   ► like iOS 10 compatibility, and we'll talk about that later, deciding what of the new

00:00:32 ◼   ► OS to adopt at all.

00:00:35 ◼   ► And so this could take various forms.

00:00:37 ◼   ► This is both new styles of the UI that the system apps pioneer or that the APIs make

00:00:41 ◼   ► available to you, and also down to things like API choices.

00:00:46 ◼   ► Because every time a new OS comes out, not only are there usually new styles you can

00:00:50 ◼   ► take advantage of, but there's also usually new APIs that you could use that you might

00:00:54 ◼   ► have already implemented manually in some way in your app in the past, and now there's

00:00:59 ◼   ► a new system way to do it.

00:01:01 ◼   ► And so there's always the question of whether you adopt that for your app and dump your

00:01:04 ◼   ► custom thing or not.

00:01:06 ◼   ► Because it isn't always an easy decision.

00:01:09 ◼   ► So I think first we want to start out with the style element here.

00:01:12 ◼   ► iOS 11 actually did not introduce a lot of new styling, as we had predicted it might,

00:01:19 ◼   ► but it did introduce one that will affect almost every app I know of that's not a game,

00:01:23 ◼   ► which is the new iOS 11 navigation bar style with the giant big bold black text as the

00:01:30 ◼   ► title and then maybe an integrated search box, which is nice.

00:01:34 ◼   ► But that big bold black text with the big white gap above it is very different from

00:01:39 ◼   ► all previous navigation bar styles.

00:01:41 ◼   ► And the navigation bar is an element that almost every productivity style or non-game

00:01:46 ◼   ► app, there's a pretty good chance it uses a navigation bar somewhere in it.

00:01:49 ◼   ► And so this affects lots of people, lots of apps.

00:01:52 ◼   ► And the question is, like Overcast has a navigation bar, David, many of your apps do as well,

00:01:57 ◼   ► the question is do you change your apps look to look like this?

00:02:02 ◼   ► >> Yeah, and it's tricky.

00:02:04 ◼   ► I think this one in particular, I've been struggling with it so much because I don't

00:02:10 ◼   ► really like the new nav bar.

00:02:12 ◼   ► >> Yeah, I knew the delay.

00:02:14 ◼   ► >> So iOS 7 in some ways, which is another example of the big wholesale UI changes, I

00:02:21 ◼   ► liked a lot of them.

00:02:22 ◼   ► In fact, I liked them so much because they made my apps look better in comparison to

00:02:27 ◼   ► the other apps because I didn't need a complicated rich detailed textures and dimensionality

00:02:33 ◼   ► and things.

00:02:34 ◼   ► I could get rid of a lot of that and make a lot of progress.

00:02:36 ◼   ► Whereas this one, I sort of like it sometimes, but the way that the nav bar is designed to

00:02:44 ◼   ► interact with scrolling and things, I find really awkward and clumsy.

00:02:49 ◼   ► And I sort of like the feel, but not so much.

00:02:54 ◼   ► It's growing on me a little bit.

00:02:56 ◼   ► As I've been updating Pedometer++ this last week, I've been making some changes to try

00:03:01 ◼   ► it out, and I kind of like where it's going, but I don't really like their implementation.

00:03:06 ◼   ► And so then I'm kind of in this place now where I'm starting to think, should I build

00:03:09 ◼   ► my own navigation bar?

00:03:11 ◼   ► >> The answer to that is almost always no.

00:03:13 ◼   ► >> It probably is no, right?

00:03:15 ◼   ► It's this weird question because I don't really like the way that if you have, you know, like

00:03:22 ◼   ► it starts big and then as you scroll up it gets smaller, but it doesn't like shrink.

00:03:26 ◼   ► It just sort of like jumps from one size to the other, which maybe it's just a beta thing,

00:03:31 ◼   ► but it seems like that's kind of the way it's designed to work.

00:03:35 ◼   ► But it's a struggle.

00:03:36 ◼   ► And I think moreover, that style of UI will only fit in, like I would need to make other

00:03:44 ◼   ► changes to the UI of my apps, you know, holistically to fit that kind of style.

00:03:50 ◼   ► Like if you look at the music app, which is probably the best place to kind of, on iOS

00:03:54 ◼   ► 11, the best place to look at this, you know, it's, if you have this big bold nav title

00:04:00 ◼   ► on that sort of left aligned in most places, you kind of then want, if you have section

00:04:07 ◼   ► headings and things that are subsequently down the page, you probably want them to be

00:04:11 ◼   ► big bold and left aligned.

00:04:14 ◼   ► And it kind of lends this look to it that's different.

00:04:18 ◼   ► And on the one hand, I kind of want to update my apps to look like that, mostly because,

00:04:25 ◼   ► you know, I'm not as confident enough in my own design prowess to sort of like stand my

00:04:31 ◼   ► own ground and be like, absolutely, you know, I'm better than where iOS is, you know, the

00:04:38 ◼   ► system designers are saying that the apps should sort of be heading.

00:04:40 ◼   ► And most of my apps too are things that are designed to fit in, you know, they're not

00:04:45 ◼   ► super over, they're not super custom UIs, they tend to feel fairly native.

00:04:50 ◼   ► And in many ways, kind of my goal for a lot of my apps is to feel like they are a system

00:04:55 ◼   ► app, like that is sort of my high level design goal.

00:04:59 ◼   ► And so it's definitely kind of a weird place to find myself.

00:05:05 ◼   ► But like, I'm still kind of stuck right now on whether or not I should do it in this case.

00:05:09 ◼   ► Yeah, I'm also still pretty undecided on the nav bar thing.

00:05:15 ◼   ► I too do not like it, you know, upon first glance.

00:05:19 ◼   ► And I'm trying to figure out because, you know, when they make changes like this, and

00:05:23 ◼   ► I mentioned this before, so I'll make it brief, but when they make changes like this, it's

00:05:26 ◼   ► hard to know whether this is something that only Apple apps will ever adopt, or whether

00:05:30 ◼   ► this is going to become the new expected standard for all apps.

00:05:34 ◼   ► Sometimes these things are only Apple apps, you know, in practice.

00:05:37 ◼   ► And so this, and if you do something that's only Apple apps, at best, your app looks boring.

00:05:43 ◼   ► At worst, it seems like you're trying to rip off Apple's apps.

00:05:46 ◼   ► So it's, I'm not sure, should I have a giant title on my home screen that says overcast

00:05:52 ◼   ► like that?

00:05:53 ◼   ► I don't know if that's the right move or not.

00:05:54 ◼   ► It doesn't seem right to me right now.

00:05:56 ◼   ► But I am going to play with things a little bit more throughout the summer.

00:06:00 ◼   ► Yeah, and I think also it's probably something that I have in the back of my mind is, obviously

00:06:04 ◼   ► Apple has a much better sense of the hardware roadmap going forward.

00:06:10 ◼   ► And it's really complicated too, and as I'm trying to think about design changes to, you

00:06:15 ◼   ► know, it's like, you end up like doubling, triple guessing yourself, because you're sort

00:06:18 ◼   ► of like, well, are they doing it this way?

00:06:21 ◼   ► Because on a future bit of hardware, this design will feel at home and make sense.

00:06:28 ◼   ► And if they are, then like, in some ways, I can get a jumpstart on taking advantage

00:06:33 ◼   ► of that if I kind of go where they're kind of leading.

00:06:37 ◼   ► Or it could just be, that just happens to be what they like, and they're trying it now.

00:06:42 ◼   ► And like, it's, this is the style for iOS 11.

00:06:45 ◼   ► And then maybe iOS 12, it will change again.

00:06:47 ◼   ► And like, that ambiguity is a little weird.

00:06:51 ◼   ► I mean, it's sort of like this was like these emphasis this year on sort of safe edges on

00:06:57 ◼   ► the side of the screen, and an overall emphasis on vertical space, like making it not particularly

00:07:05 ◼   ► at a premium, which is like, maybe so are we talking that, you know, the widely rumored

00:07:09 ◼   ► like edge to edge phone that's super long?

00:07:12 ◼   ► Like maybe?

00:07:13 ◼   ► I don't know.

00:07:14 ◼   ► But it's, I kind of feel like if I, when I start looking for clues, I can start seeing

00:07:21 ◼   ► clues, but then I start wondering, am I just making this stuff up?

00:07:23 ◼   ► Yeah, the other thing to think about too is like, what if they change their mind really

00:07:28 ◼   ► quickly on this?

00:07:29 ◼   ► You know, this is based on, it basically looks as though the style that they've been kind

00:07:34 ◼   ► of pounding out with Apple Music has now taken over the whole OS.

00:07:38 ◼   ► And Apple Music is not a variable designed app.

00:07:41 ◼   ► And so there's two other possibilities here.

00:07:44 ◼   ► Maybe this is a bad design.

00:07:46 ◼   ► You know, Apple, not everything Apple designs is good.

00:07:50 ◼   ► Sometimes it doesn't work out and they change it in the next version.

00:07:52 ◼   ► Apple Music has done that many times so far because they tried to cram a lot of functionality

00:07:56 ◼   ► into one app and it's very hard to design.

00:07:59 ◼   ► And so there is the distinct possibility that this is really just this year's fad and that

00:08:06 ◼   ► it'll be different in 12, as you said.

00:08:08 ◼   ► And if that's true, then it might not be worth wasting time switching all your whole UI to

00:08:12 ◼   ► this if it's going to change in a year.

00:08:14 ◼   ► So we'll, you know, we'll have to figure that out.

00:08:16 ◼   ► Yeah.

00:08:17 ◼   ► And reality too is switching back and forth is almost certainly going to be confusing

00:08:24 ◼   ► in terms of from a customer experience perspective.

00:08:26 ◼   ► Obviously, their other apps are changing in this case and so it might feel more reasonable

00:08:32 ◼   ► to change and if it changes again.

00:08:35 ◼   ► But on the same time, it's like if they change again in iOS 12 and they kind of go even more

00:08:40 ◼   ► all in on this, this is just like stage one of giant bold text everywhere.

00:08:46 ◼   ► Then you're even more behind.

00:08:48 ◼   ► Like, then you're two years behind and then you're kind of, that's an even more abrupt

00:08:53 ◼   ► jump for your users if suddenly you're like, you know, I really need to get rid of all

00:08:56 ◼   ► my, you know, small pitiful headers.

00:09:00 ◼   ► I need to go to these gigantic headers.

00:09:03 ◼   ► Like, it's a weird thing to play by myself, but I think right now, like if I had to make

00:09:08 ◼   ► a call, I'm leaning towards mostly adopting the new look and just mostly hoping that,

00:09:16 ◼   ► in doing so, I'm, you know, my future self will thank me for being ahead of this rather

00:09:25 ◼   ► than finding myself either this fall when there's some new hardware announcement or

00:09:29 ◼   ► something where like now this makes a lot of sense or just down the road as the years

00:09:33 ◼   ► go on that if I'm not like building this sort of design technical debt, then I'm eventually

00:09:39 ◼   ► going to have to pay off, that I can't just kick down, you know, sort of kick down the

00:09:42 ◼   ► can for years and years.

00:09:44 ◼   ► Because if I look back now at an iOS 6 app, you know, I look at that and it's like,

00:09:48 ◼   ► oh man, this is, it looks really out of place.

00:09:51 ◼   ► And maybe that's, in six months, that's not going to feel out of place, but maybe

00:09:55 ◼   ► in a year it will.

00:09:57 ◼   ► And then I'm just like digging myself into a hole by trying to hold on to the past.

00:10:01 ◼   ► Yeah.

00:10:02 ◼   ► And the other problem though is that your users might resist change in your app.

00:10:07 ◼   ► And this is something we'll get to in the second half of this.

00:10:09 ◼   ► But first, we are sponsored this week by Indeed Prime.

00:10:13 ◼   ► Indeed Prime helps tech talent such as us, software developers, data scientists, simplify

00:10:18 ◼   ► their job search and land their dream job.

00:10:21 ◼   ► Candidates get immediate exposure to the best companies with just one simple application

00:10:25 ◼   ► to Indeed Prime.

00:10:27 ◼   ► And companies on Indeed Prime's exclusive platform message the candidates with salary

00:10:31 ◼   ► right up front.

00:10:32 ◼   ► And the average software developer gets five employer contacts with an average salary offer

00:10:37 ◼   ► of $125,000 a year.

00:10:40 ◼   ► Indeed Prime is 100% free for candidates with no strings attached.

00:10:44 ◼   ► So sign up now at Indeed.com/Prime.

00:10:48 ◼   ► Once again, it's 100% free for job candidates.

00:10:51 ◼   ► So sign up now at Indeed.com/Prime.

00:10:54 ◼   ► Thank you very much to Indeed Prime for sponsoring this show.

00:10:57 ◼   ► So we talked about this UI question we have now.

00:11:01 ◼   ► And I have a couple of blurry lines on the way to the API discussion.

00:11:06 ◼   ► One of them for me, probably the big one for me that I'm facing with Overcast is I spent

00:11:12 ◼   ► a lot of time in Overcast 3.0 developing a custom full-time table view reordering method

00:11:17 ◼   ► where you can drag around the manual order of playlist entries using a permanent little

00:11:24 ◼   ► drag handle on the right side of the table cell.

00:11:27 ◼   ► This was a ton of work and hacks and everything else.

00:11:30 ◼   ► And I finally did get it working.

00:11:31 ◼   ► And it mostly works as a few edge case bugs that are really hard to find and fix.

00:11:35 ◼   ► But for the most part it works.

00:11:37 ◼   ► And there's a nice little visible handle there.

00:11:39 ◼   ► So it's obvious that you can do that.

00:11:41 ◼   ► And it's fast to just instantly tap it and move something up.

00:11:45 ◼   ► iOS 11 introduces a standard drag and drop API.

00:11:50 ◼   ► One of the things it can do, part of what it does is offers full-time reordering to

00:11:54 ◼   ► supported table views.

00:11:55 ◼   ► And I'm really torn on whether I should dump my old custom implementation and move to this

00:12:02 ◼   ► new one.

00:12:03 ◼   ► And this is something, I faced this a lot over the years with Instapaper.

00:12:07 ◼   ► One of the examples I had with Instapaper was when they added a system dictionary that

00:12:13 ◼   ► apps could bring up a dictionary pop-up controller.

00:12:16 ◼   ► I had been shipping my own dictionary in the app.

00:12:19 ◼   ► And so my app binary was like five megs worth of dictionary.

00:12:24 ◼   ► And then the rest of it was like, it was a big part of the app binary.

00:12:27 ◼   ► I had to write all this dictionary code.

00:12:29 ◼   ► And I had my own little dictionary pop-ups.

00:12:31 ◼   ► And the definitions, I forget where I was pulling them from.

00:12:33 ◼   ► I think it was Wichenary or something, some kind of free source.

00:12:37 ◼   ► So they were okay, but they weren't great.

00:12:40 ◼   ► And my UI wasn't great.

00:12:42 ◼   ► But it was, you know, done basically.

00:12:44 ◼   ► And then Apple started shipping theirs.

00:12:45 ◼   ► And I decided to make it an option.

00:12:50 ◼   ► And you can use the system dictionary if you want, or you can use my old one.

00:12:54 ◼   ► And that was totally the wrong move in retrospect.

00:12:58 ◼   ► Because the system one looked nicer.

00:13:00 ◼   ► It worked better.

00:13:01 ◼   ► It had a better source for definitions.

00:13:03 ◼   ► It required almost no code in my app to invoke.

00:13:07 ◼   ► And if I would have only shipped the system one, it would have dramatically reduced the

00:13:10 ◼   ► size of my binary.

00:13:11 ◼   ► Instead, though, for a while, I think I eventually did remove it.

00:13:14 ◼   ► But for a long, for I think a couple years, I just did both and made it an option.

00:13:18 ◼   ► And this was just the worst of everything.

00:13:19 ◼   ► This was now, I'm maintaining two different code paths.

00:13:21 ◼   ► I have this option cluttering up my settings screen and making the app, you know, look

00:13:25 ◼   ► more complicated for people.

00:13:27 ◼   ► And losing my own dictionary support, it was a feature loss to remove that eventually.

00:13:35 ◼   ► But that was a feature that almost nobody cared about.

00:13:38 ◼   ► So all the advantages of using the system one and dumping the one I had written and

00:13:42 ◼   ► been maintaining, I could have had those advantages earlier because really nobody cared about

00:13:46 ◼   ► my implementation of this feature.

00:13:48 ◼   ► So when I look back at Overcast's reordering handle problem, I'm a pro and cons list.

00:13:54 ◼   ► The pros of replacing my drag and drop thing with the new drag and drop API, and this applies

00:14:00 ◼   ► to so many things, is that, you know, first of all, new users coming to the app will expect

00:14:05 ◼   ► your app to work in a standard system way.

00:14:09 ◼   ► And so anything you do that deviates from the system is going to cause probably some

00:14:14 ◼   ► usability hurdles for some people, maybe for a lot of people.

00:14:18 ◼   ► And it also might make your app look old or weird or different.

00:14:21 ◼   ► And sometimes that's cool.

00:14:23 ◼   ► In many ways you want that in certain things, but it's hard to walk that balance and it's

00:14:28 ◼   ► risky.

00:14:29 ◼   ► So the safest thing to do is to make your app behave like the system apps in things

00:14:33 ◼   ► like basic UI control.

00:14:36 ◼   ► Also, if I switch to the built-in one, I can dump all that buggy code.

00:14:42 ◼   ► It's a huge set of hacks to make mine work.

00:14:47 ◼   ► And it does, as I mentioned, it does occasionally cause UI bugs.

00:14:50 ◼   ► And then I could also, the new API is also better than mine in that you can enable things

00:14:54 ◼   ► like multi-episode drag.

00:14:56 ◼   ► So you can pick one up and then you can tap a few additional episodes to add to a drag

00:15:01 ◼   ► to maybe move like five episodes at once to the top of a list.

00:15:04 ◼   ► Or you can even keep holding that down, hit back, back out of that playlist, and maybe

00:15:09 ◼   ► drop them onto a new playlist.

00:15:10 ◼   ► Like you can do so much cool stuff with the new API that mine will never be able to do.

00:15:15 ◼   ► The other major thing is that if I wouldn't have my drag handle on the right side anymore,

00:15:22 ◼   ► then I can replace that with a play button, a one-touch play button, which ever since

00:15:27 ◼   ► 3.0 made the cells not play by default when you tap them, people have been begging for

00:15:32 ◼   ► this.

00:15:33 ◼   ► And it's been this massive controversy in my user base and getting lots of one-star

00:15:37 ◼   ► reviews over it and lots of people who are unhappy about it.

00:15:40 ◼   ► And if I could devote like the right quarter of the cell to just a big play button, but

00:15:46 ◼   ► still have the left three quarters of it bring up the menu thing and then move the info button

00:15:51 ◼   ► into that menu where the play button was, I feel like I could solve a lot of problems

00:15:55 ◼   ► for people.

00:15:56 ◼   ► However, this would be a UI change.

00:16:00 ◼   ► And like any UI change you make, some people will be angry and will leave one-star reviews

00:16:06 ◼   ► for years to come.

00:16:08 ◼   ► And I mentioned this on Twitter last week and I think people didn't quite believe

00:16:11 ◼   ► me.

00:16:12 ◼   ► When I change something in the UI or if I ever remove a feature, some people are so

00:16:17 ◼   ► mad about that that every single time I update the app, they will go and update their one-star

00:16:23 ◼   ► review to make sure it's always on top.

00:16:26 ◼   ► This is a real thing that people do.

00:16:29 ◼   ► And if it was just one person ever who did that, okay, you can't please everybody.

00:16:35 ◼   ► But because it's a small crowd that does that for pretty much everything I ever do,

00:16:41 ◼   ► those actually add up.

00:16:42 ◼   ► So if I have something in the app that is constantly angering old users of the app for

00:16:48 ◼   ► some reason, that actually really does affect, I think, my downloads.

00:16:53 ◼   ► Because especially with the new App Store only showing one review at a time and making

00:16:56 ◼   ► it very hard to see that there are even more that you can swipe between, if the most helpful

00:17:02 ◼   ► review at any given time is one of these one-star angry ones about a feature removal I did three

00:17:08 ◼   ► years ago, that actually could really hurt downloads of the app.

00:17:12 ◼   ► So anything you can do to not anger people too much while also not making your product

00:17:17 ◼   ► bad is usually a good idea.

00:17:19 ◼   ► So a big con for me for changing my drag-and-drop to the system UI would be that it would be

00:17:26 ◼   ► a change and it would generate more of these people.

00:17:29 ◼   ► The new one also, which is kind of annoying for me, the system control is slower to activate.

00:17:35 ◼   ► You know, mine, you tap that drag handle and you can immediately move it.

00:17:37 ◼   ► The system one, you got to tap and wait a second.

00:17:40 ◼   ► It's almost like a long press.

00:17:41 ◼   ► You got to tap and then a second later it kind of lifts up if you're still holding.

00:17:45 ◼   ► And then you can drag it around.

00:17:46 ◼   ► So there's a slight delay.

00:17:49 ◼   ► But then the other thing is like once someone learns that in any app in the system, then

00:17:55 ◼   ► they will know how to do it in all apps that support it.

00:17:58 ◼   ► And I know that this isn't always that strong of a correlation.

00:18:02 ◼   ► Things like the edit button in table view corners.

00:18:05 ◼   ► Almost no one ever taps that.

00:18:06 ◼   ► They don't know what it means.

00:18:07 ◼   ► And anything buried behind the edit button might as well be invisible.

00:18:11 ◼   ► So some things it doesn't work out for.

00:18:12 ◼   ► But drag-and-drop is already a power user feature.

00:18:15 ◼   ► Reordering playlists is already unfortunately a power user feature even though I've supported

00:18:19 ◼   ► it since 1.0 and I really wish people would do it more often.

00:18:21 ◼   ► The fact is they don't do it that often.

00:18:24 ◼   ► So there is some benefit to have it be the new one and to have people only have to learn

00:18:31 ◼   ► that once in the system.

00:18:33 ◼   ► And what kind of pushes me over the edge on this and the reason I'm probably going to

00:18:38 ◼   ► switch to the new one and dump my old one is that you think about what would you do

00:18:43 ◼   ► if you were starting over from scratch.

00:18:44 ◼   ► If you had a brand new app and you can apply this thinking to pretty much any of these

00:18:48 ◼   ► changes.

00:18:49 ◼   ► Style, API, whatever.

00:18:50 ◼   ► If I had a brand new app, how would I do it?

00:18:54 ◼   ► If there was no legacy user base to worry about and no legacy code written yet.

00:18:58 ◼   ► And there's no question I would do the system one.

00:19:00 ◼   ► I would not write my own.

00:19:01 ◼   ► I would definitely do the system one for this because my own is not better enough and is

00:19:05 ◼   ► actually in some ways worse.

00:19:06 ◼   ► So I would definitely use the system one.

00:19:08 ◼   ► And that also means that any new competitor that comes around, not only will they not

00:19:13 ◼   ► have to write yours, they won't have to write your big hack, but they will also use the

00:19:19 ◼   ► system one.

00:19:21 ◼   ► And so you're going to be competing more and more against the system implementation

00:19:24 ◼   ► of these things as you go.

00:19:25 ◼   ► And you're going to be competing against apps that look and work like the system apps

00:19:29 ◼   ► more often.

00:19:30 ◼   ► So you can look at a lot of decisions that try to avoid the sunk cost issues and say

00:19:36 ◼   ► like, "Okay, well if I was starting clean, how would I do it?"

00:19:39 ◼   ► And the answer is usually this new better way.

00:19:42 ◼   ► So I think that's probably the answer here.

00:19:44 ◼   ► Even though it will hurt in the short term and it might cause some people to get mad

00:19:49 ◼   ► at me and leave one star reviews forever, I think overall the app would be better if

00:19:54 ◼   ► it used the new system way.

00:19:56 ◼   ► And overall I'm going to need to do that to be competitive now and in the future.

00:20:01 ◼   ► So I should do that.

00:20:02 ◼   ► >>

00:20:13 ◼   ► Such that the new version is better than your current version.

00:20:19 ◼   ► >>

00:20:20 ◼   ► But not in all ways.

00:20:21 ◼   ► Remember, it has that small delay which actually drives me nuts, but in a lot of other ways

00:20:25 ◼   ► it's better.

00:20:26 ◼   ► >>

00:20:27 ◼   ► Sure.

00:20:28 ◼   ► It's better in ways that a significant number of users would appreciate and be able to benefit

00:20:34 ◼   ► from.

00:20:35 ◼   ► You'd be deleting a lot of code.

00:20:36 ◼   ► There's some clear wins that you can take advantage of.

00:20:39 ◼   ► And at the end of the day, hostage star driven development is almost certainly a bad idea.

00:20:49 ◼   ► I know exactly where you're coming from with a feeling of it can be so frustrating where

00:20:54 ◼   ► a vocal small minority of users can have an oversized impact on the way your app appears

00:21:05 ◼   ► in the app store.

00:21:06 ◼   ► That is really unfortunate.

00:21:08 ◼   ► But the reality is, and this is something I have to keep reminding myself too, is that

00:21:13 ◼   ► in order for -- if my business, and I hope it is, has longevity, the majority of my users

00:21:22 ◼   ► are still to come.

00:21:24 ◼   ► As big as the app may be at this point, hopefully more people will download it from today forward

00:21:31 ◼   ► than today going back.

00:21:34 ◼   ► Because if that isn't the case, then the app is slowly dying and it could be okay, but

00:21:40 ◼   ► it's not the best.

00:21:42 ◼   ► Whereas if it's going up and getting better, then what I want to do is make choices today

00:21:48 ◼   ► that are going to make the experience better for the future user.

00:21:53 ◼   ► In this case, deleting a bunch of code is better probably mostly just in so far as you

00:21:58 ◼   ► don't have to maintain your old version anymore.

00:22:01 ◼   ► Especially something that's kind of hacky and non-standard.

00:22:05 ◼   ► Maybe iOS 10 or iOS 11 doesn't get broken right away, but maybe it gets broken in a

00:22:13 ◼   ► different update.

00:22:14 ◼   ► In some random update down the road, suddenly your thing just completely doesn't work and

00:22:19 ◼   ► you didn't install 11.1.2's beta, so you didn't realize that it was broken, and then suddenly

00:22:26 ◼   ► it doesn't work at all.

00:22:28 ◼   ► Whereas shifting to something that is system-supported and this is the new way that Apple is pushing

00:22:33 ◼   ► us to use, you avoid that situation.

00:22:36 ◼   ► So there's always that too in the background.

00:22:40 ◼   ► In general, the more you can pay off these technical debts, just deal with it right now,

00:22:45 ◼   ► and then your future self will likely appreciate that, almost certainly.

00:22:49 ◼   ► And there will be some people who are angry or grumpy, but unless you, at a certain point,

00:22:56 ◼   ► realize I've had to make peace with the fact that either my app is going to get better

00:22:59 ◼   ► over time, and in doing so will have an ever-increasing number of grumpy people.

00:23:06 ◼   ► That number will go up over time.

00:23:09 ◼   ► The law of a long-running app.

00:23:12 ◼   ► That is either what's going to happen, the app is going to get better, and at the same

00:23:15 ◼   ► time there's also going to be more and more grumpy people.

00:23:18 ◼   ► Or the app is going to stay the same, and there are probably going to be fewer and fewer

00:23:23 ◼   ► people overall.

00:23:25 ◼   ► That's a good point.

00:23:26 ◼   ► Yeah.

00:23:27 ◼   ► One of those two scenarios is probably going to happen, and hopefully the rate of new people

00:23:31 ◼   ► that you're able to gain by making your app better and better and better will far outweigh

00:23:38 ◼   ► the proportion of grumpy people over time, and that's probably a better place to be.

00:23:44 ◼   ► That is a growth mindset that I want the app to be as the best thing it can possibly be,

00:23:51 ◼   ► and just ignore as much as we can what's going on in the past, and just say, "You know what?

00:23:56 ◼   ► It's going to annoy some people.

00:23:57 ◼   ► It's great.

00:23:58 ◼   ► You know who I want to make happy?

00:24:00 ◼   ► A, I want to make me happy, because if I'm not happy with the app, if I'm annoyed by

00:24:05 ◼   ► it, or there's lots of old code that I'm having to deal with and work around, that's not good

00:24:09 ◼   ► for anybody, because then I don't want to work on it.

00:24:12 ◼   ► I don't want to dive into it.

00:24:13 ◼   ► I'm probably going to be, in my case, I'll probably be more apt to get my attention shifted

00:24:19 ◼   ► to something else that's like, "Ooh, look, ARKit's shiny.

00:24:22 ◼   ► Let me just dive over there and start working on ARKit apps and just start ignoring these

00:24:26 ◼   ► apps."

00:24:27 ◼   ► That's not good.

00:24:28 ◼   ► In theory, it's like if I want this app to be exciting for me to develop, that's good

00:24:31 ◼   ► for the customer.

00:24:32 ◼   ► Then hopefully it's also good for the customer, and the app is just getting better and better.

00:24:36 ◼   ► So, yeah, these situations, every summer, it almost feels like it's this new challenge,

00:24:43 ◼   ► but the reality is we've probably been fighting this battle for years and years, and every

00:24:48 ◼   ► year the same thing comes up of this feeling of, "Ooh, should I go for it and should I

00:24:53 ◼   ► not?"

00:24:54 ◼   ► But I'm pretty sure, I think history has shown me that I probably should.

00:24:58 ◼   ► It's in the same way that at the moment you said you left an option to do the old way

00:25:04 ◼   ► in Instapaper, my immediate giant alarm bells go off, and it's like, "No, no, no!

00:25:10 ◼   ► That is the worst!"

00:25:11 ◼   ► That's never the right decision.

00:25:14 ◼   ► Instead of having the best of both worlds, it's like you actually end up with the worst

00:25:17 ◼   ► of both worlds.

00:25:18 ◼   ► It's now like you get none of the benefits and all of the drawbacks.

00:25:22 ◼   ► Yeah, exactly.

00:25:23 ◼   ► And all your users will all request that.

00:25:26 ◼   ► They will all say, "Oh, can you just make it an option?

00:25:28 ◼   ► Give me back the old way.

00:25:29 ◼   ► Make it an option."

00:25:30 ◼   ► No, the answer is always no.

00:25:32 ◼   ► That is not good for the app.

00:25:33 ◼   ► And so I think we can kind of wrap this up with one of the questions that indie developers

00:25:38 ◼   ► face most often every summer when new iOS shiny stuff comes out, which is, "When can

00:25:44 ◼   ► I drop support for the old OS so I can start building stuff exclusively around the new

00:25:49 ◼   ► APIs?"

00:25:51 ◼   ► In some cases, it's pretty much impossible to use the new stuff unless you break compatibility

00:25:56 ◼   ► and unless you start requiring the new OS on day one or whatever.

00:26:01 ◼   ► Some of the more fundamental UI things you pretty much can't conditionally enable in

00:26:05 ◼   ► any reasonable way that doesn't involve keeping around a whole copy of your old app in the

00:26:09 ◼   ► binary, which by the way, people will sometimes request that too.

00:26:14 ◼   ► Don't do that.

00:26:15 ◼   ► But anyway, and I think if you apply everything we've just said to this question, different

00:26:22 ◼   ► apps have different needs and different requirements.

00:26:25 ◼   ► If you're a consultant and you're making apps for people who, for like a big company

00:26:29 ◼   ► that needs to support as many people as possible, well then you have a different set of constraints

00:26:33 ◼   ► there.

00:26:34 ◼   ► But if you're making indie apps yourself and you're just making apps like selling

00:26:40 ◼   ► directly and you don't have to answer to the needs of some big company that has to

00:26:44 ◼   ► serve millions of people and everything, then I would say the choice is very clear.

00:26:49 ◼   ► For all of the reasons we just talked about using new APIs, you can also say, "You know

00:26:54 ◼   ► what?

00:26:55 ◼   ► I can just work with the newest OS.

00:26:56 ◼   ► Like I can make my app require the newest OS at or near the newest OS's release."

00:27:02 ◼   ► So at or near the fall, and you can have all the benefits that somebody would have if they

00:27:09 ◼   ► had no legacy, if they had no existing users to make one star reviews, if they had no legacy

00:27:13 ◼   ► code that they had to maintain or no sunk cost fallacy with the things they wrote in

00:27:18 ◼   ► the past.

00:27:19 ◼   ► You can apply all that same logic to the question of, "Should I dump iOS 10 support and require

00:27:24 ◼   ► iOS 11 as soon as possible and that way I can use all this new stuff?"

00:27:28 ◼   ► The answer for indies is usually, "Yes, you can."

00:27:30 ◼   ► >> And I think too, the biggest thing where I've ended up is that if supporting old OS's

00:27:38 ◼   ► is holding you back in any way, almost certainly just drop the old OS and move forward.

00:27:46 ◼   ► If there isn't this clear, obvious thing where you need to do it, don't just do it for fun,

00:27:54 ◼   ► because at least in the short term, it probably slightly slows down your downloads potentially,

00:28:02 ◼   ► just insofar as now your app is compatible with a smaller percentage of the user base.

00:28:07 ◼   ► But it's one of these things that if at any point you're like, "Oh, I wish I could do

00:28:11 ◼   ► this, but iOS compatibility?"

00:28:13 ◼   ► Then it's like, "All right, that's it.

00:28:16 ◼   ► Conversation's over.

00:28:17 ◼   ► Drop support for the old OS and just plow forward."

00:28:20 ◼   ► As soon as you hit that point, you'd run into it.

00:28:23 ◼   ► But one thing I will also mention to just be thoughtful of, and this is from my bias

00:28:27 ◼   ► as a watch developer that I want to mention, be very thoughtful about how you do it between

00:28:32 ◼   ► iOS and watchOS.

00:28:35 ◼   ► Because things can get really crazy if you support, in this case, watchOS 4, but still

00:28:40 ◼   ► iOS 10.

00:28:43 ◼   ► You can end up in some very funny places that people won't be able to...

00:28:48 ◼   ► The person who stays then on iOS 10 can then never install your watch app, and it actually

00:28:54 ◼   ► just gets deleted off their watch and things.

00:28:57 ◼   ► Or somebody took me off too.

00:28:58 ◼   ► If you make the same version, upgrade the requirement for both iOS and watchOS, then

00:29:05 ◼   ► when that version gets installed on someone, or when that person upgrades to iOS 11 and

00:29:11 ◼   ► that version of your app gets installed, if they haven't upgraded their watch yet, it'll

00:29:15 ◼   ► get uninstalled from the watch.

00:29:17 ◼   ► So something to keep in mind, not great, but in general, be aggressive.

00:29:22 ◼   ► It's fine.

00:29:23 ◼   ► Every time I've been aggressive, I've been worried, and it's never turned out to actually

00:29:26 ◼   ► be a problem.

00:29:27 ◼   ► And with that, we're out of time this week.

00:29:29 ◼   ► Thanks everybody for listening, and we'll talk to you next week.

00:29:32 ◼   ► Bye.

00:29:32 ◼   ► [BLANK_AUDIO]