Under the Radar

27: Fast App Review


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

00:00:04   I'm Marco Arment. And I'm David Smith. Under the Radar is never longer than 30 minutes,

00:00:08   so let's get started. So an exciting thing happened

00:00:12   over the last, I guess it's about a week or so, at least

00:00:16   since I first noticed this and started to hear about it. So as

00:00:20   you would imagine, as someone who has quite a few apps, I submit to the App Store

00:00:24   on a semi-pre-regular basis. Usually I'll have at least an app or two

00:00:28   to in review at any given time.

00:00:30   And I noticed something a bit funny.

00:00:33   The app, my app started to get through review really quickly

00:00:37   and in fact, this is now sort of gone from being

00:00:40   this sort of a freak occurrence, which I've had before.

00:00:42   You know, in the past I've had like a freak app review

00:00:44   that just went through in a day or two

00:00:46   or I think I've even had a couple that went through

00:00:48   in a few hours and you know, who knows what that is.

00:00:50   But this has happened now three times in a row

00:00:53   where my last app reviews have taken 27, 25

00:00:57   and 17 hours respectively.

00:01:00   And I've started to hear more generally from app developers

00:01:03   that this is a thing now, that whatever is causing this

00:01:07   to happen is a consistent thing, it isn't just my account.

00:01:11   And if you go to App Review Times,

00:01:13   which is this lovely little community sourced site

00:01:17   that Dave Voor, who's the guy who also does

00:01:19   the iOS Dev Weekly newsletter runs,

00:01:21   where you can submit your App Review Times,

00:01:24   it seems like this is a thing,

00:01:26   that the vast majority of apps that are, you know, people who have submitted their app

00:01:31   review times recently are saying that it's taking, you know, a day or two. You know,

00:01:35   somewhere between, you know, one or two days, which is a massive departure from what we

00:01:41   had before. And, you know, certainly it's fair to have the side note. Obviously, yes,

00:01:46   I know Android has no review time and it's amazing and it's wonderful, but this is the

00:01:50   world in which the iOS app store lives and has lived for a very long time where there's

00:01:56   As long as I can remember, the app review has taken about a week. Sometimes it takes

00:02:02   a bit less than a week, typically around big updates. So like in September, sometimes things

00:02:07   will speed up a little bit because there's new updates, lots of updates coming out, Apple

00:02:12   wants to get those ready for the new phones, great. Sometimes it can get a bit slower,

00:02:17   sometimes it can be 10 days, 2 weeks, but I would say about a week has been what it's

00:02:22   been for seven or eight years now.

00:02:24   And now all of a sudden, it seems like, fingers crossed,

00:02:27   Apple has changed something in their process,

00:02:31   in their staffing, in their automation, in who knows what.

00:02:35   But they're doing something that's

00:02:37   meaning that app review is taking a day.

00:02:40   And that seemed like a pretty big deal and something

00:02:42   that we should talk about.

00:02:43   Because I feel like a lot of the ways in which I approach

00:02:47   development are, in many ways, sort of

00:02:50   they're working backwards from, whenever I submit, it's going to be a week until that

00:02:56   shows up in the store. And so if you change that calculus to essentially be a day, then

00:03:01   a lot of things about the way, updates that I think are big enough or good enough to actually

00:03:06   submit, or things might change, and just in general, it's good for a lot of reasons, and

00:03:11   there's also some tricky things that I think will also be worth updating. So does that

00:03:16   make sense?

00:03:17   - Yeah, I mean, I'm as surprised as anybody,

00:03:20   because as you said, it has been about a week,

00:03:23   whether it was six days or eight days,

00:03:25   it's been about a week for almost the entire history

00:03:29   of the App Store.

00:03:30   And we should clarify the iOS App Store.

00:03:32   The Mac App Store has gone all over the map,

00:03:35   because it seems to have gotten a lower priority

00:03:39   most of its life.

00:03:41   And so the Mac App Store times have often been

00:03:43   as high as 30 days, which is horrible,

00:03:46   that's pretty crippling to any actual efforts to get quality software into the market. But

00:03:51   on iOS it's been pretty much a week forever. And I don't think this is a coincidence. I

00:04:01   think Apple is pretty clearly setting internal metrics of whatever guideline they consider

00:04:07   to be good enough, they hit that guideline. And it's pretty obvious that for most of the

00:04:13   history of the App Store, that's been a week. And there's lots of reasons why Apple might

00:04:17   want to not get faster. One of the biggest ones obviously is the faster they review apps

00:04:23   the more frequently people will submit updates, so it'll increase the total volume of updates

00:04:28   they're going to have to deal with, which will increase their cost, increase the size

00:04:32   of that team that the team has to be, etc. And as you get more and more people in this,

00:04:39   the app review team, you're probably going to have more mistakes made, and that increases

00:04:44   the risk of angering developers, getting negative press, possibly letting bad things through

00:04:50   instead of being too aggressive on the good things.

00:04:54   So there's certainly reasons for Apple to want to keep the review times high for all

00:05:00   these kind of accessory benefits they get from it.

00:05:03   And it really does seem like for the last eight years they have just thought that one

00:05:07   week was good enough and that was a good balance of all these factors according to them and

00:05:13   developers have kind of just gotten used to it and have just, I was resigned to accepting

00:05:18   that it would just always be about a week because they obviously were targeting that

00:05:20   and so that was just the way it was always going to be forever. And the idea now that

00:05:27   over the past few months, like if you look at the graph on the Shania development thing,

00:05:33   you look at the graph like it it hasn't been like a dramatic drop just yesterday

00:05:38   it's been like a pretty straight downward slope for the last few months

00:05:44   basically since Phil took over and it's it's probably related although Phil

00:05:50   already ran that department before so like like Phil already was the head of

00:05:55   the department that contains app review so he was already the top of that before

00:06:00   before. So presumably he could have, you know, he probably

00:06:03   could have adjusted this before and just and didn't because

00:06:06   I he probably thought he was he was probably the one who made

00:06:08   the decision that seven days was was a good target. So there

00:06:14   are changes afoot like this is there's because it has not

00:06:17   just been like all of a sudden in like a day it's been like

00:06:21   this because it's been this this kind of steady progression

00:06:23   downwards over the last few months. I think it's more

00:06:26   that this is intentional and that this is possibly

00:06:30   the new goal, possibly here to stay,

00:06:33   and that will just have tremendous effects

00:06:36   on our development, because like,

00:06:38   like I remember back when App Review,

00:06:39   you know, back when the App Store started,

00:06:40   and App Review settled pretty quickly

00:06:42   into this one week delay, I said a number of times

00:06:46   back then, like, you know, 'cause back then,

00:06:48   iOS developers had not quite resigned ourselves

00:06:50   that this is like the inevitable forever state,

00:06:53   and we were like, oh, App Review is terrible,

00:06:54   there should be no App Review,

00:06:55   we should have direct access and be able to update

00:06:57   as much as we want just like people could always do

00:06:59   on the Mac, et cetera.

00:07:01   And at the time I remember saying like,

00:07:03   there's a huge difference between having a short app review

00:07:08   and having a long app review.

00:07:09   And the longer it takes, generally like the more of a burden

00:07:13   it places on developers and the more of like a slowing

00:07:16   effect it has on technological progress, on development

00:07:20   and on your ability to ship quality software.

00:07:22   I remember even saying back then, seven days is, you know, we can tolerate this, but it

00:07:28   would be totally different if it was 24 hours.

00:07:32   And now it appears that after eight years, they are actually changing it so that it is

00:07:38   24 hours.

00:07:40   And I never thought this would happen.

00:07:41   I am very happy about it.

00:07:44   It will change the way we do things, and not all those things will be for the better, but

00:07:48   I think most of them will.

00:07:50   I don't know, I mean, what do you think,

00:07:54   how will this change, I mean, your special case also,

00:07:58   because you do so many apps, how do you think

00:08:00   this will change the way you work?

00:08:03   - So, I was trying to think through how this changes things,

00:08:06   and the biggest, like, I think it makes,

00:08:09   has different impacts on different kinds of updates

00:08:11   that I'm trying to do, and it's also probably

00:08:14   one thing I looked up ahead of time was,

00:08:17   I was curious what the current adoption rate

00:08:20   for updates is recently. Since iOS 7 there's been automatic app updates, so customers don't

00:08:27   have to go to the App Store and hit update anymore. For most people it just happens.

00:08:30   Although I believe that's off by default, isn't it?

00:08:33   If it is, then a lot of people are turning it on, or going to the App Store a lot, because

00:08:38   what I saw is that for me I'm seeing about three days to get 80% of people updated to

00:08:46   the latest version. Because that's also an important thing to keep in mind, because even

00:08:50   Even if the app update cycle is a day, it's still a while until that update will be running

00:08:57   on everybody, all of your customers' apps.

00:09:00   But it's still a pretty substantial change if, say, we're going to a world where 80%

00:09:04   of your customers get the update four days, one day for app review, three days for actually

00:09:09   updating it on their phone, versus 11, 12, 13 days.

00:09:14   That's a pretty substantial change.

00:09:17   But that's good to keep in mind. So within about three or four days, I can get people

00:09:22   doing things. For small changes, like bug fixes, I ship an update and I get a crash

00:09:29   report back. Something like that. Some situation where there's this little change that is obviously

00:09:34   wrong with what's currently out there. This changes the dynamic for me a lot for looking

00:09:40   at it and saying, "Well, maybe I'll just do a .01 release, .02 release, .03 release."

00:09:46   the more iterative model in terms of these little fixes when I used to look at those

00:09:54   kind of updates and I'd bundle them together because a lot of those fixes really are short

00:10:00   and simple and kind of verifiably correct. If you look at it, you'll find the line of

00:10:05   code where, "Oh, what am I thinking? I have an off by one error, I have an out of bounds

00:10:09   error," something that is just obvious and fixable. And I want to get that out to my

00:10:14   my customers as quick as I could,

00:10:15   but going through a one-week process

00:10:20   when I can't submit any other changes,

00:10:24   it usually didn't make sense,

00:10:25   and so I'd tend to bundle these things up

00:10:26   and then do a sort of a bigger submission,

00:10:29   and when that one came out, maybe I'll do another one,

00:10:33   but the cadence of that was very much,

00:10:37   I'd be doing maybe an update or two a month,

00:10:43   you could imagine a world where you would do updates much more regularly. I mean, in

00:10:46   many ways it's much sort of like you imagine with web development, where you can do releases

00:10:51   on a fairly regular basis, and as a result, your average lifespan of a known bug will

00:11:00   drop dramatically. You discover a bug, you fix a bug, you ship that out to your customers.

00:11:05   So for small changes, it seems like that's something that I'll have to think through.

00:11:10   On bigger releases, it sort of changes things.

00:11:14   I think the biggest thing that it changes is if it can become consistently around a

00:11:18   day or two, then when I'm doing a big update, something that I'm trying to market around,

00:11:22   something that I'm trying to get attention for, it'll be great to have some better sense

00:11:27   of if I put it in review, it'll be approved or rejected within 24 hours.

00:11:33   Say that was like what this becomes.

00:11:35   And I really hope Apple doesn't change their mind on this and this is just some kind of

00:11:38   cruel experiment. But if this is actually the new reality, then that changes that a

00:11:45   lot because I can submit my update, I can get it approved, and I can coordinate my marketing

00:11:49   versus the thing that I end up having to do now where I submit it and I tell people in

00:11:55   the press and talk to people and say, "Hey, sometime in the next seven to ten days, I

00:12:00   hope, it'll be approved." And if you can write an article about it, that would be great.

00:12:06   But the worst thing on those updates is if it gets rejected.

00:12:10   And if you get a rejection, and then getting the rejection re-reviewed takes a week, suddenly

00:12:16   you can end up with something that you hoped was going to be one week, can become three

00:12:19   weeks or more.

00:12:22   And so turning that around to you get rejected, you resubmit, you get approved, and that's

00:12:26   two days rather than two weeks is just massive for release planning for big marketing pushes

00:12:33   and things like that.

00:12:34   - Yeah, I mean, the rejection thing, I think,

00:12:36   is one of the biggest savings here,

00:12:38   because, especially if you're submitting a brand new app,

00:12:42   Apple's gonna nitpick a lot of things

00:12:44   you might not have thought of,

00:12:45   or they're gonna disagree with you

00:12:47   on something that's kinda near the edge of a rule

00:12:49   or something.

00:12:50   Rejection is a multiplier of this app review time,

00:12:54   where it is not uncommon for a 1.0 of an app

00:12:59   to get rejected one to three times

00:13:02   before one finally gets approved,

00:13:04   with little changes here and there.

00:13:06   The more you go near third rails,

00:13:09   like in-app purchase or pay services,

00:13:12   the more likely that is to happen.

00:13:14   But either way, you always had to plan,

00:13:18   well, this app I'm planning to launch

00:13:21   might get rejected one to three times

00:13:24   before I can launch it.

00:13:25   So now your buffer, which used to be like,

00:13:28   well, this is probably gonna be in the store

00:13:30   sometime in the next month,

00:13:32   can now shrink down to,

00:13:34   this can probably be in the store sometime in the next week.

00:13:36   And that is substantially better.

00:13:39   It dramatically decreases the cost of rejection.

00:13:44   And it also decreases how bad it is

00:13:47   if Apple wrongly rejects you.

00:13:50   - This is true, yeah.

00:13:51   I'm delighted that,

00:13:53   I'm honestly still trying to wrap my head around

00:13:57   some of the changes because I think about this,

00:14:00   And I combine it with thinking recently about the business models and the things that are

00:14:05   along those sides in the App Store, where things like paid updates, which we don't have,

00:14:13   would make bundling up changes into large things make a lot of sense.

00:14:20   The model of software where your version number is like you have a 1.0 and then a year later

00:14:25   you have a 2.0 and that kind of a model, which I would say feels fairly outdated at this

00:14:32   point, changes too dramatically if there's no incentive on the business side to bundle

00:14:39   up your changes, and if releasing updates becomes really lightweight and straightforward,

00:14:44   it's kind of like this situation you end up with, I believe, I think this is what Chrome

00:14:48   does with the browser, where there's just a new version all the time, or even a scenario

00:14:54   where I think, I don't actually use the Facebook app, but I believe it's just sort of every

00:14:59   week gets an update and the number goes bigger or something along those lines. I've heard

00:15:03   of a lot of software companies moving to that kind of a model where you just ship on a very

00:15:10   regular basis and the product just sort of always gets better rather than there being

00:15:15   these discontinuities in updates. Rather than having these big moments where customers have

00:15:23   to be like, "Whoa, what's going on?" And sometimes you'll still have those if you're doing a

00:15:26   big UI refresh or something like that. But in general, if the app is just sort of always

00:15:32   getting better, if it's getting updated in the background behind the user, you can kind

00:15:36   of get into a very interesting pattern there that kind of completely gets away from the

00:15:40   concept of like, "Oh, I'm working on my next big 3.0." It's like, no, the app is just always

00:15:45   getting better, and I don't need to break them up into these big updates because updates

00:15:50   are lightweight. They're like this sort of this very simple thing that, you know, it's

00:15:55   even if there was no app review, it taking you like the difference between a day and

00:16:01   zero days is fairly minor because the majority of the time is going to be spent in getting

00:16:06   people to actually go and download it from the app store, like to get the new software

00:16:10   anyway. So as long as that number is on that very low end, it's warped by the update rate.

00:16:16   And so it's essentially free to do, which hopefully Apple can adapt to, because I would

00:16:22   imagine the rate will necessarily go up.

00:16:25   But I mean, the Android store has had essentially no app review.

00:16:29   Well, they have app review, but it doesn't take time.

00:16:32   I'm not entirely sure on the details of that, but I remember they famously announced that

00:16:36   they had added app review to the Google Play Store, but nobody noticed.

00:16:41   Yeah, I think it takes like a few hours to a day, something like that, but it's short.

00:16:47   And that works, and that's great, and if that's our world too now, that's kind of wild. I

00:16:52   would love the worst thing, and I think you ran into this recently with an Overcast update,

00:16:57   where you ship an update, all your testing, all these things, somehow you missed a pretty

00:17:04   substantial bug. You know, a data loss bug, something that's crushing your server, some

00:17:10   kind of really heinous bug. And previously, for those things, we would have to go and

00:17:15   do the, like, you know, like, get on our knees and beg Apple, "Hey, please give me an expedited

00:17:19   review." And Apple was usually pretty good about that. You know, in my years, I've requested

00:17:25   probably a handful of those. They've always granted them. I mean, the email you get back

00:17:29   was always a bit comical, because it has this kind of like, "Well, we'll make a special

00:17:33   one-time exception for you. You really shouldn't rely on this." You know, it's like poor,

00:17:37   it's like sort of this kind of very condescending email you'd get back, but whatever. I don't

00:17:42   mind being condescended to if that meant that my app got approved in a few hours, and this

00:17:47   kind of terrible bug. I've shipped updates where it's like if you launch that particular

00:17:52   version it would start corrupting your database or things. These things happen, and they're

00:17:57   terrible, but I almost wonder if Apple would still have the expedited system in a world

00:18:02   of if it's a one-day review cycle.

00:18:06   If you can request a one-hour review,

00:18:09   I don't even know if that would even make sense.

00:18:11   But it's lovely to think that at worst,

00:18:13   it would be a day before I could get something out.

00:18:16   - No, I mean, it takes them about a day

00:18:17   to respond to those requests.

00:18:18   So I think that actually might be a sign.

00:18:21   If they end up eliminating the Expedited Review System,

00:18:24   I think that would be a sign that they intend

00:18:26   to keep the review times this low.

00:18:27   Because with the review times being approximately a day,

00:18:31   that system doesn't make sense anymore,

00:18:33   there's no gain there.

00:18:35   Because it takes about a day to get the affiliate reviews.

00:18:37   So yeah, I mean that would, man that would be great.

00:18:40   This really would, like many of the problems of AppReview

00:18:46   are proportional to the time it takes AppReview to happen.

00:18:49   And so, you know, you don't get rid of all the issues

00:18:52   of AppReview by having short review times,

00:18:54   but you do make a lot of them a lot smaller of a problem.

00:18:58   And so I, man, this is great.

00:19:00   Anyway, we are sponsored this week by Braintree.

00:19:03   Go to Braintreepayments.com/radar.

00:19:06   Why make payment integration more difficult

00:19:08   than it has to be?

00:19:09   Braintree's powerful full-stack payment platform

00:19:12   allows you to accept nearly any type of payment

00:19:14   from any device with just one integration.

00:19:17   It's flexible to your system's needs

00:19:19   and supports most languages.

00:19:21   Whether you're using Java, Ruby, or Python,

00:19:23   you'll always have a range of server-side

00:19:25   and client-side SDKs available.

00:19:28   This code supports Android, iOS, and JavaScript clients,

00:19:31   and this takes just 10 lines of code to implement Braintree.

00:19:35   Now by next year, maybe even next week,

00:19:37   there could be a whole new way to pay.

00:19:39   Maybe it'll be the next Bitcoin, the next Apple Pay,

00:19:41   maybe both.

00:19:42   Fortunately, Braintree's full-stack payment platform

00:19:45   is easily adaptable to whatever the future holds,

00:19:47   so you can adapt easily too, except everything

00:19:50   from Pounds to PayPal to the next big innovation

00:19:53   from any device with just this one integration.

00:19:56   And when that next payment method comes out,

00:19:57   all you have to do is update a few lines of code.

00:19:59   No late nights, no complicated recoding,

00:20:02   no stress about staying ahead of the curve.

00:20:04   Braintree is here to help.

00:20:06   Braintree makes payments and your job a whole lot easier.

00:20:08   Learn more at Braintreepayments.com/radar.

00:20:12   Thank you very much to Braintree

00:20:14   for supporting Under the Radar and all of Relay FM.

00:20:17   So I wanted to also mention the impact

00:20:20   this has both ways on quality.

00:20:23   So like for me, I've mentioned before,

00:20:26   I stress out like crazy when doing a release.

00:20:29   And part of the reason I stress out

00:20:31   is what you mentioned earlier of like,

00:20:33   I know that if I screwed up something big time,

00:20:35   it's gonna take me a week to get a fix out there.

00:20:38   And that's just horrible.

00:20:40   And like worst case scenario,

00:20:41   if the app, if something's really bad,

00:20:43   like a data loss bug,

00:20:44   I'm gonna have to pull the app from the store

00:20:46   until I can get a fix out there

00:20:47   and lose like a week of sales.

00:20:50   I've never had to do that,

00:20:51   but that always been like,

00:20:52   kind of like the fail safe in the back of my mind,

00:20:54   like well I might someday have to do that

00:20:56   if it's really bad.

00:20:57   - I've had to do that.

00:20:58   - Yeah, it's bad, right?

00:20:59   - I've pulled an app from the store for a week,

00:21:01   and it's just like, well, that's that.

00:21:04   - Yeah, that's a huge dent in your income

00:21:07   and in the app's growth and usage

00:21:08   and sucks for the customers, so yeah.

00:21:10   So I've always had in the back of my mind,

00:21:13   man, if I screw this up,

00:21:14   this is gonna take me a week to fix.

00:21:15   And if it only takes me a day to fix,

00:21:19   that's a pretty big difference.

00:21:21   And so the faster you can get updates out,

00:21:26   the more, the lower stress it is,

00:21:29   but also I think the more likely I might be

00:21:32   to let my standards slip of testing and quality assurance

00:21:37   to be like, 'cause before,

00:21:40   if you've ever rejected a binary

00:21:45   more than 24 hours after you submitted it,

00:21:48   then if you think about it in this new system,

00:21:51   that would have shipped to customers.

00:21:53   And I've done that a few times.

00:21:55   I did that like two weeks ago.

00:21:57   So I feel like this will, this is a double-edged sword,

00:22:02   it will increase the ability for us to get fixes out there

00:22:08   and to improve quality and to be faster,

00:22:10   but I think it will also increase the likelihood

00:22:12   that we ship bad bugs.

00:22:14   And it's gonna take a certain degree of self-control,

00:22:18   of quality assurance, of good rigorous practices

00:22:21   to prevent that.

00:22:23   One of the weird side effects of this is that right now,

00:22:27   getting your app approved through the App Store

00:22:29   takes roughly the same amount of time or even less

00:22:31   than getting TestFlight beta approval

00:22:33   for the first version of the beta

00:22:35   that you ship in TestFlight.

00:22:37   So hopefully that's a temporary hiccup,

00:22:40   and hopefully that will change maybe to the point

00:22:42   of getting rid of TestFlight review entirely,

00:22:44   'cause it doesn't make a lot of sense,

00:22:46   and especially in this world,

00:22:47   'cause basically right now, I am more incentivized

00:22:51   to just update the app for everybody

00:22:53   than I am to run a beta,

00:22:55   because running a beta will take way longer now

00:22:57   than just getting the update out there.

00:23:00   - Which is very strange.

00:23:01   And I think it also, I was thinking too,

00:23:03   one of the things, when I was talking about this online,

00:23:08   the comment I got back was this,

00:23:09   well, this is just gonna make people use the public

00:23:12   as their QA department,

00:23:13   which I think is sort of what you're saying.

00:23:14   It's like, well, I may as well just ship it out

00:23:17   into the world, and if there are bugs,

00:23:20   people will tell me and I'll submit an update and we'll go back round and round. And I guess

00:23:25   the reality is that may be true, and for some people that may happen, but I think overall

00:23:32   the average quality will still go up because it's like our ability to sort of ask them

00:23:38   -- in a lot of ways I think of software quality, it's like you're trying to get to say -- for

00:23:44   some arbitrary measure, say it's like crash-free users, which is I think the way Fabric and

00:23:48   and crashlytics measure it.

00:23:50   It's like I want that line to approach 100%,

00:23:53   and the faster I can iterate on it,

00:23:56   the faster I'm going to get it there.

00:23:58   So while some reality, 'cause I think

00:24:03   viewing public QA is a bad thing, it can be,

00:24:05   but the reality is a lot of bugs

00:24:08   can only be found in the wild.

00:24:11   If beta testing and internal QA were perfect,

00:24:16   then we wouldn't need a crash reporter.

00:24:18   I wouldn't need Crashlytics in my apps.

00:24:20   I would have just caught all the bugs before I shipped it.

00:24:22   But that's not the reality.

00:24:24   And especially any app that involves user data in any way.

00:24:28   I have a recipe book app,

00:24:30   and sometimes I find some very strange and interesting bugs

00:24:34   that are caused by issues that I wouldn't have,

00:24:38   I never even dreamed of or imagined would be issues.

00:24:41   But it's like that's just the way people are using the data,

00:24:44   or it's their particular language or character set

00:24:47   has a weird quirk that causes a strange issue.

00:24:50   - See also our episode number 16, Designing for Misuse.

00:24:53   - Yes, exactly.

00:24:55   Some of these things you're only gonna find.

00:24:56   But for me, there is definitely, I have to keep,

00:25:00   I think it's a good cautionary word

00:25:02   to keep in the back of our minds

00:25:04   that just because our review is quick

00:25:06   and fixing a potential bug is more lightweight,

00:25:09   we still have to have the discipline

00:25:11   of keeping ourselves to high standards,

00:25:14   that we're not just gonna like, oh, we'll just ship it

00:25:15   and fix it in post kind of mindset.

00:25:19   But if we embrace the ability of what that means,

00:25:22   if we keep our standards high,

00:25:25   they can now, the overall quality can get to that much higher

00:25:29   and much higher quality level so much faster.

00:25:33   You know, it's sort of in a way that I think of

00:25:34   in some ways like iOS updates,

00:25:37   like iOS, you know, big major updates

00:25:39   where Apple doesn't update once a year

00:25:42   with a few point releases along the way.

00:25:45   That's a much slower process necessarily

00:25:47   to getting towards really high quality overall

00:25:51   because it just takes longer.

00:25:54   And so there's a much higher period

00:25:55   where things aren't gonna be as good.

00:25:58   - Yeah, and I think, and we can see,

00:26:01   it's not like this is going to be the first platform ever

00:26:04   that has fast app updates available.

00:26:06   We can see from existing platforms,

00:26:08   the Mac, the web, maybe Android, I don't know,

00:26:12   but you can see from other platforms

00:26:14   What happens when developers can update their software

00:26:16   whenever they want?

00:26:17   And the answer is, some products become

00:26:20   like crashing unstable and changing every day,

00:26:22   but most don't.

00:26:23   Most just have releases that are carefully issued

00:26:26   when they need to be, and like most of my Mac apps,

00:26:28   don't update themselves every day, it's fine.

00:26:31   They wait until they have a solid release,

00:26:34   and then they update them.

00:26:35   Web apps tend to be the same way,

00:26:36   where you're generally not noticing changes

00:26:39   every single day to web apps that you use.

00:26:41   They're generally not like crashing constantly

00:26:43   because everyone's running untested code. People just have discipline and good practices

00:26:47   and they figure out how to make it work. And I think iOS is going to be the same way. As

00:26:52   this time stays down, if it stays down, as we hope it does, then we're just going to

00:26:56   see just in the long run better software. And there might be some hiccups along the

00:27:01   way as some developers get a little bit too careless with it, but I think that will iron

00:27:05   itself out fairly soon and it'll just be great. And I'm just assuming this stays here,

00:27:12   I could not be happier that they're making changes like this

00:27:15   because this means that they care

00:27:19   and that they recognize that the previous system

00:27:21   was not as good as it can be.

00:27:23   - Exactly, and I, honest, genuine thanks to,

00:27:27   if anybody who happens to listen to the show

00:27:29   happens to work in App Review

00:27:31   or know someone who works in App Review,

00:27:33   highest of fives, this is awesome.

00:27:36   This is exactly the kind of thing that is an encouragement

00:27:40   to me as a developer, especially as a smaller developer,

00:27:43   that there are changes afoot,

00:27:46   that things, we've been talking about for a while,

00:27:48   that the App Store is a trickier and trickier place

00:27:50   to make a business and to make a run at.

00:27:53   And these changes in some ways are small,

00:27:57   but they are impactful in terms of

00:27:59   they allow me to ship better product more easily,

00:28:02   and that's awesome, and so thank you.

00:28:06   - Also, big congrats to the App Review team

00:28:09   for the amazing degree of secrecy that they have.

00:28:12   Through my web presence and everything else,

00:28:17   I have met a lot of Apple contacts

00:28:20   or heard from a lot of Apple people

00:28:22   from every department you can think of in the company

00:28:24   except App Review.

00:28:26   I have never heard from or met or heard about anybody

00:28:31   who either worked in App Review

00:28:33   or who even knew anybody who worked in App Review.

00:28:37   That's pretty crazy, that's saying a lot.

00:28:39   Anyway, so good job on them.

00:28:40   They're more secret than the car.

00:28:41   Anyway, so congrats, Hyperview.

00:28:43   Thank you for doing this.

00:28:44   Please keep it up.

00:28:45   We are looking forward to this being our new reality.

00:28:48   I believe that's all the time we have for this week.

00:28:50   So thank you very much for listening, everybody.

00:28:52   Thank you, Phil Schiller.

00:28:54   You're amazing, and please keep this.

00:28:58   And we'll talk to you guys next week.

00:29:00   - Bye.

00:29:00   [