PodSearch

Under the Radar

87: Old Code Vs. New APIs

 

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]