Developing Perspective

#73: Updates, Updates, Updates.


00:00:00   Hello and welcome to Developing Perspective. Developing Perspective is a podcast discussing

00:00:05   news of note in iOS development, Apple, and the like. I'm your host, David Smith. I'm

00:00:09   an independent iOS developer based in Herndon, Virginia. This is show number 73, and today

00:00:14   is Tuesday, August 21st. Developing Perspective is never longer than 15 minutes, so let's

00:00:19   get started.

00:00:20   All right, first, quick little note. Just wanted a sort of a public service announcement.

00:00:25   As of right now, when I'm recording, there are likely about 21 days, calendar days, between

00:00:30   now and when iOS 6 will launch.

00:00:32   That is assuming the widely rumored and Jim Dalrymple deept date of September 12th.

00:00:39   It turns out to be actually true.

00:00:42   And typically, iOS 6 will launch for Apple accept submissions either that day or at the

00:00:49   latest that Friday.

00:00:51   but if you're trying to be sort of safe and ready,

00:00:53   you probably want to be iOS 6 ready and tested

00:00:56   and good to go on the 12th, so about 21 days.

00:01:00   So just putting that out there.

00:01:02   If you have an app that's new,

00:01:04   taking advantage of some of the new features,

00:01:06   that's sort of the target that I think

00:01:07   you should probably be heading towards.

00:01:09   So 21 days, three weeks.

00:01:11   I look forward to seeing what you guys got.

00:01:13   I got a few things in store, not too much this time around,

00:01:16   but a few things.

00:01:19   So the main topic I'm going to talk about today is updates.

00:01:25   An update is when you take your application and you make it better.

00:01:31   You do something to it, you fix it, you improve it, you do whatever, and you then take that and submit it to the store.

00:01:34   And I want to talk about some of the parts of that process that may be slightly surprising or unexpected as you go through it.

00:01:44   So first, when you submit an update, it's slightly different than a new application,

00:01:50   where a new application you set a date when it will be released.

00:01:52   With an update, you just submit it and wait.

00:01:55   You can choose to say if you want it to be released to the store immediately, or you

00:02:00   can have it be held for developer release.

00:02:03   The difference there basically is if you say release automatically, whenever the app's

00:02:09   approved, assuming it's approved, it'll just be live in the store and replace the existing

00:02:12   version.

00:02:13   that's fairly straightforward.

00:02:15   Hold for developer release is when it's approved,

00:02:17   you'll get an email or a notification that says,

00:02:19   hey, your app's been approved.

00:02:20   Click this button whenever you're ready for it to go live.

00:02:23   And this is something that you can take advantage

00:02:25   of to great effect if you have features or things that require

00:02:31   server-side components to be scaled up, readied, whatever.

00:02:34   If there's a marketing campaign, those types of things

00:02:37   that are going to be geared in.

00:02:39   And it's just kind of up to you.

00:02:41   I would say typically I use hold for developer release

00:02:45   for probably about 80% of my updates

00:02:47   just because I like the control of that.

00:02:49   The only exception to that is if I'm doing kind of like

00:02:52   a critical bug fix release where I have released something

00:02:55   and then all of a sudden I realize, oh goodness,

00:02:57   there's this critical bug that I need to get out there

00:02:59   as quickly as I can.

00:03:00   I'm not going to hold that for developer release.

00:03:02   I just want that in there as quickly as possible.

00:03:04   I heard some rumors that people say that Apple

00:03:07   gives hold for developer release updates

00:03:10   a little bit of a boost, or a slight delay,

00:03:13   compared to non-hold-for-developer release apps.

00:03:17   It's questionable, I'm not sure,

00:03:20   but it's certainly something to keep in mind.

00:03:22   Like I said, it's just sort of anecdotally,

00:03:24   some people have said that if they say release automatically,

00:03:27   it goes slightly quicker, but the App Store review process

00:03:30   is so, you know, so inconsistent

00:03:35   that it's almost impossible to know if that's true.

00:03:37   But just something to keep in mind.

00:03:39   will say, and this has bitten me before, once an app goes in review, or specifically once

00:03:45   an app is approved, that version of the application must be released to the store. There is no

00:03:51   way at that point to pull it back. And I say that because once you've submitted an application,

00:03:58   between then, so when it goes into sort of the waiting for review stage, until it's approved,

00:04:03   you can go into iTunes Connect and you can say, "Reject this app," or, "Reject this binary,

00:04:07   this version, whatever.

00:04:09   And it'll just disappear.

00:04:10   So it'll be pulled out of iTunes Connect,

00:04:12   and you can replace it with something better.

00:04:14   And that's great.

00:04:15   The classic place where I found that is I

00:04:18   submit something to the App Store.

00:04:20   I'm playing with it on my phone or whatever for the next couple

00:04:23   of days, and then all of a sudden,

00:04:25   I find this critical bug that I really

00:04:27   don't want to see in the store.

00:04:28   So I pull it, get to the back of the line, resubmit it.

00:04:31   It takes a little longer for review,

00:04:33   but I'd rather do that than submit an app with all

00:04:36   bugs. But once it's approved, there's no way to get it back. I've talked to people who've

00:04:41   tried to contact Apple, have them do it, and they find some critical bug in it that's,

00:04:46   you know, they're holding it for developer release, so it's not in the App Store, but

00:04:50   it has been approved. You're pretty much, you have to release that. If you're in a circumstance

00:04:55   where you have, for whatever reason, you absolutely cannot release it, the only thing you can

00:04:59   really do, and I've done this once myself, is you have to just essentially pull it from

00:05:03   from the store, release the update, submit an update

00:05:08   to replace it, and I'll probably ask Apple for an expedited

00:05:11   review.

00:05:13   For me, once, one of my apps was just out of the store

00:05:16   for four or five days because there

00:05:19   was a critical bug in the update that I just

00:05:22   didn't want anyone to ever see.

00:05:24   So I put it in a developer.

00:05:25   It's like you pull it from the store, submit the update,

00:05:28   wait till it's approved, and then re-add it to the store.

00:05:31   So you just want to put that out there.

00:05:33   It's a good thing to just keep in mind.

00:05:37   Generally speaking, once you submit it,

00:05:38   you should be assuming that people are going to see that.

00:05:41   So you don't want to be too fast and loose with it.

00:05:43   But that's just something that you're really--

00:05:46   right up until in review, you can pull back.

00:05:49   You can cancel the submission after that.

00:05:54   You're on your own, and you just have to make it work.

00:05:57   So one of the things about updates that are interesting--

00:05:59   One is updates are a great way to help you gauge engagement with your users and measure

00:06:05   that.

00:06:06   And it's a tricky problem to say like how many active users do you have, how many people

00:06:10   do you have who use your application on a regular basis.

00:06:13   And one of the ways that you can sort of do it is to just look at after you submit an

00:06:17   update, if you go into your iTunes Connect report, it will tell you how many people have

00:06:21   updated that application.

00:06:22   And so that's how many people have downloaded it since the update was approved.

00:06:26   And that, compared to the total number of sales, is probably a pretty good indication

00:06:31   of how many people are sort of somewhat active users.

00:06:35   That doesn't mean they use it all the time, but it means they likely still have it on

00:06:38   one of their phones or iPad or whatever.

00:06:40   So it's just kind of a metric that I often look at just to get a sense of how many people

00:06:44   sort of still have it.

00:06:47   Another interesting attribute of sales or updates is I've almost always seen updates

00:06:55   minor updates specifically often cause a short-term drop in sales.

00:07:02   I say that here because it's totally normal, but totally freaked me out the first time it happened.

00:07:06   And as best I can tell, it's because there's a couple of things that kind of reset when an update gets approved.

00:07:13   Your ratings get reset, and some of the display in the store gets changed a little bit,

00:07:18   and it'll kind of have this--the app looks kind of odd, typically for a day or two,

00:07:24   or depending on how often you get ratings, but the biggest part is all of a sudden it

00:07:28   says like not enough ratings for this application or something like that in the store.

00:07:34   And I've found that sort of that strangeness rather than just have it's like it's almost

00:07:39   better to have, you know, whatever series here, it's like three stars, not a great rating.

00:07:43   But I think that often will do better than this kind of this weird transient state.

00:07:48   So often I see that with major releases, you often get around this because often you'll

00:07:52   be trying to either having press or other things going on around,

00:07:57   sort of other activities to promote the application that can overcome it.

00:08:02   Or you've created, you know, done something that makes it more compelling

00:08:05   that people can see and are excited about.

00:08:08   But the first time that happened to me, it kind of freaked me out.

00:08:11   And every time that happened still, I sit there and you kind of watch.

00:08:15   And how long that dip takes seems to be very non-deterministic.

00:08:21   So I've usually seen it turn around.

00:08:24   And typically, after a week at least,

00:08:26   you'll have seen the cyclical pattern of the store happening.

00:08:28   But it's just something to keep in mind.

00:08:31   And it's normal.

00:08:34   Obviously, you could submit an update that was horrible,

00:08:37   and it would permanently hurt the sales of the application.

00:08:41   But I'm assuming that it's just--

00:08:43   for the purpose of what we're talking about,

00:08:45   it's just you submitted an update,

00:08:47   and it just didn't-- while it's in that weird state,

00:08:50   your sales may drop, your ranks may drop.

00:08:53   And that's just probably an important thing

00:08:55   to keep in mind, because you don't

00:08:57   want to be constantly submitting updates to your application.

00:09:00   There was a time in the App Store

00:09:01   where that was really good for you, where you would constantly

00:09:05   want to do updates.

00:09:06   Because every time you submitted an update and it was approved,

00:09:08   you would be moved to the top of the release date,

00:09:12   or the recently updated or the recently added apps.

00:09:16   Apple no longer does that.

00:09:17   That's only based on new submissions.

00:09:20   So updates don't really give you any boosts like they used to.

00:09:24   And it seems like whenever they happen, at least for me,

00:09:27   you'll often see a little drop off in sales.

00:09:29   So you want to make sure that you're bundling in lots

00:09:30   of functionality, lots of things in sort of bigger chunks.

00:09:33   And so at this point, I typically only do releases

00:09:36   other than bug fix releases probably once a quarter, maybe,

00:09:39   once every three, four months, something like that.

00:09:41   And I found that to be much better for my nerves.

00:09:44   It seems like it's often enough that customers still

00:09:47   feel like you're engaged, that you're

00:09:48   working on the application, that it's not abandoned, those kinds of things.

00:09:52   But you want to avoid constantly throwing up updates.

00:09:55   It's also probably a little annoying to your users.

00:09:57   Because whenever there's an update, their App Store icon is going to turn red.

00:10:01   Most people I know have the App Store on their home screen.

00:10:04   And if you're anything like me, I can't stand it when apps have a red badge on them.

00:10:07   It just gets under my skin and drives me crazy.

00:10:10   So if I'm going to the App Store, I'm having to go to there once a week to hit an update

00:10:14   for an application unless it's somehow content oriented or something.

00:10:18   But even there, there's better mechanisms for it.

00:10:21   So generally I'd say only do updates every couple of weeks--or every couple of months,

00:10:27   maybe once a month, just to run through your application.

00:10:30   But just be careful about that.

00:10:31   Don't get too update crazy.

00:10:33   And the last thing I was going to talk about, and this is based on a question I got from

00:10:37   Paul Donahue, who was asking just sort of how do you encourage users to always be on

00:10:43   the latest version of your application.

00:10:46   Often this is irrelevant, where either there's a bug in the old version that you're constantly

00:10:51   getting support requests for, which is really frustrating.

00:10:54   On the flip side, old versions use old servers or all kinds of things that you want to migrate

00:11:01   away from.

00:11:02   There's truly two ways to do it.

00:11:04   There's sort of in-app methods and there's external methods.

00:11:08   methods would be something like you have a messaging system built into your

00:11:11   application.

00:11:13   This could be as simple as

00:11:15   you have a plist file that you host on a web server

00:11:17   and your application just goes, checks, downloads that file when it

00:11:21   launches or something like that

00:11:23   and that file includes a little message and you can just open that and display it

00:11:27   to the user if it exists and you just change that file on the server

00:11:31   whenever you have something to say. And so as an example you could have a

00:11:35   a message that says, "Hey, version 4 of this application is now available. Click here to

00:11:39   download it," or something like that. So you're probably going to have your messaging system

00:11:43   both have a way to display something as well as to have a URL or a call to action mechanism

00:11:49   that you could have them do. And so you have to think ahead if you want to do something

00:11:54   like that. You have to actually build it into your application in order for that to work.

00:11:58   But that's certainly one option. I've seen a couple of applications do that. You want

00:12:03   be careful that you're not nagging your user, because that's probably not necessarily what

00:12:07   they want. It's often, sometimes I've seen this too, is another great way is to, in your

00:12:11   settings app for example, or in a settings area in your application, do something where

00:12:17   you indicate that a new version is available, or you put a banner on the top of the application,

00:12:21   or something like that, something more subtle that they can use the application and not

00:12:25   feel like they're being yelled at, but they are aware that, "Hey, there's a new version,

00:12:29   and here's these great new features." It's often just telling the user, "Hey, version

00:12:32   three is available, it's probably not as compelling as to say, hey, version three fixes this problem,

00:12:38   or version three is this great new content, version three does these things. That's probably

00:12:42   a much more compelling thing to your user. And then externally, there are other ways

00:12:47   you can do it. Obviously, you have, hopefully you're trying to develop some kind of a relationship

00:12:51   with some of your users, whether it's having a newsletter, whether it's having a Twitter

00:12:55   account, a Facebook page, a website, all kinds of places that users can interact with you.

00:13:00   And you can mention, obviously, that there are updates available in that place.

00:13:04   And so that's probably what I typically do is I'm just going to tweet that out and hope it works.

00:13:10   Typically, it's a funny thing because I find that people are actually remarkably good at updating very quickly.

00:13:17   I mean, it is remarkable to me how, especially on the iOS App Store, I'm not sure on the Mac App Store as much.

00:13:23   The iOS App Store is amazing where I will, the day after I submit an update, I mean,

00:13:28   I mean, I am getting probably, it's often in like a third to a half of my updates for

00:13:34   that version will happen in that day, which is kind of crazy when you think about it,

00:13:38   that you can have that good update cycle for your user that you release new software, and

00:13:44   a lot, you know, whatever, a very substantial amount of them will be running it right away,

00:13:49   and obviously that kind of, the number of updates per day goes down slowly from there,

00:13:53   but you have, you've got a very good chunk of them onto it right away, which is awesome.

00:13:58   And so don't worry about this too much.

00:14:00   But like I said, those are really the two ways

00:14:01   that I know how to do it.

00:14:02   You can do it in the app, or you can do it externally.

00:14:05   And you just kind of are encouraging users.

00:14:06   But also keep in mind, some users may never want to upgrade.

00:14:09   And that's their prerogative.

00:14:11   For whatever reason they like the version they're on,

00:14:13   they don't want to mess with it.

00:14:15   You just kind of have to deal with that

00:14:16   and manage it accordingly.

00:14:18   All right, that's it for today's show.

00:14:20   As always, if you have questions, comments, concerns,

00:14:23   the best place to contact me is probably on Twitter.

00:14:25   I'm _DavidSmith there.

00:14:27   The Twitter feed for the show is devperspective on Twitter.

00:14:30   I'm also on AppNet as just DavidSmith without the underscore.

00:14:34   Still trying to work out exactly what is happening on AppNet, but I'm there.

00:14:37   So I figured I'll mention it in case you want to contact me there.

00:14:40   I read my mentions in all places, so just hit me up if you have any questions.

00:14:46   But otherwise, I hope you have a good day, good week, and happy coding.

00:14:49   And I'll talk to you on Thursday.

00:14:50   Bye.