Developing Perspective

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.