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. 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 ◼   ► [