Developing Perspective

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

00:00:04 ◼   ► news of note and iOS development to Apple and the like. I'm your host, David Smith.

00:00:08 ◼   ► I'm an independent iOS developer based in Virginia. This is show number 193. And today

00:00:14 ◼   ► is Friday, August 8th. Developing Perspective was never longer than 15 minutes. So let's

00:00:19 ◼   ► get started. All right, today I am going to dive into the wonderful wide world of app

00:00:25 ◼   ► and kind of unpack them a little bit,

00:00:27 ◼   ► hopefully give you some kind of a good construct

00:00:30 ◼   ► to think about app updates in, why you should do them,

00:00:33 ◼   ► why you maybe shouldn't do them, that sort of thing.

00:00:36 ◼   ► And a lot of this-- the reason I'm doing it today

00:00:39 ◼   ► is coming out of a blog post that hopefully many of you have seen

00:00:43 ◼   ► where I did a fairly detailed analysis

00:00:46 ◼   ► of the state of app updates in the App Store.

00:00:49 ◼   ► And I recommend that if you're listening to this, if you can,

00:00:53 ◼   ► Go and read that at some point, either before or after you listen to this.

00:00:57 ◼   ► It's constructive, I think, to get a good sense of what the state of the App Store is

00:01:03 ◼   ► as it relates to app updates more generally.

00:01:07 ◼   ► And generally speaking, the results from my analysis were pretty interesting.

00:01:12 ◼   ► Along the lines of things like finding out that about 50% of top apps, so apps that are

00:01:18 ◼   ► charting in the US App Store in the top 100, in their category have been updated in at

00:01:23 ◼   ► least the last three months, or 26% of apps overall have been

00:01:28 ◼   ► updated in the last three months.

00:01:30 ◼   ► Which is, if you think about it, is a pretty remarkable

00:01:32 ◼   ► thing, that that high proportion of apps are seeing

00:01:35 ◼   ► constant updates.

00:01:36 ◼   ► And obviously, there's also apps that are being newly

00:01:38 ◼   ► released, but that's a pretty high proportion.

00:01:41 ◼   ► And if I look at it over the course of the last year, so

00:01:44 ◼   ► the last 12 months, it's 86% of top apps were updated in

00:01:48 ◼   ► the last year, and 60% of overall in the App Store apps

00:01:52 ◼   ► are updated, which is kind of remarkable when you start to think about it.

00:01:56 ◼   ► That 60% of apps in a store as large as 1.2 million apps have seen some kind of update

00:02:04 ◼   ► or activity in the last year.

00:02:06 ◼   ► That's a lot of apps.

00:02:08 ◼   ► That's a lot of updates.

00:02:09 ◼   ► That's a lot of people putting energy into updating their apps.

00:02:13 ◼   ► And especially when you put it in the context of the majority of those people are probably

00:02:16 ◼   ► not actually seeing huge amounts of traffic or downloads from their apps, based on my

00:02:21 ◼   ► my own experience, if you're not ranking fairly highly in the store, you're probably seeing

00:02:25 ◼   ► very low traffic for a lot of, you know, in a lot of categories. And so there's a lot

00:02:31 ◼   ► of apps just being updated in general, out of course, out of necessity, whatever. But

00:02:38 ◼   ► it's a lot of apps. I mean, if you think about it, that 300,000 apps were updated in the

00:02:43 ◼   ► last three months in the App Store, at least like that's pretty crazy. And there were actually

00:02:49 ◼   ► probably more individual updates in the last three months,

00:02:53 ◼   ► considering many apps are updated more than once

00:02:55 ◼   ► in the last three months.

00:02:56 ◼   ► But 300 of the apps were updated in at least that three months.

00:03:00 ◼   ► That's a ton of work.

00:03:01 ◼   ► There's a lot of people putting a lot of energy and effort

00:03:04 ◼   ► in making sure that the apps are up-to-date and refreshed

00:03:09 ◼   ► and all these types of things.

00:03:11 ◼   ► And that's a lot of energy going into that.

00:03:13 ◼   ► And I imagine if you're an app developer,

00:03:14 ◼   ► that's something that you think about yourself.

00:03:16 ◼   ► And so what I wanted to do today is in that context

00:03:20 ◼   ► to think about the types of updates

00:03:22 ◼   ► that we do to our applications,

00:03:24 ◼   ► trying to think through some of the reasons we do them,

00:03:27 ◼   ► the types of them, what they are,

00:03:28 ◼   ► and then hopefully ask some thought-provoking questions

00:03:31 ◼   ► about why we're doing that to make sure

00:03:33 ◼   ► that we're spending all this energy and all this time

00:03:36 ◼   ► in ways that is going to be effective for our customers

00:03:39 ◼   ► as well as for ourselves.

00:03:41 ◼   ► So when I think about it, I think of the app updates

00:03:45 ◼   ► falling into a couple of different categories.

00:03:48 ◼   ► And for the purposes of what I'm saying here,

00:03:51 ◼   ► I'm not talking about the actual binary that you ship

00:03:54 ◼   ► as an update to the store,

00:03:56 ◼   ► because an actual shipped update will include

00:03:58 ◼   ► many different categories potentially of update,

00:04:01 ◼   ► just by its nature.

00:04:02 ◼   ► It may have a variety of the things

00:04:04 ◼   ► that I'm going to be unpacking now.

00:04:06 ◼   ► So don't think about it in those terms,

00:04:07 ◼   ► but these are any change

00:04:09 ◼   ► that you're making to your application

00:04:11 ◼   ► once you've shipped it the first time is an update.

00:04:14 ◼   ► and you have to think about what those different types of updates are,

00:04:18 ◼   ► because if you can't categorize them,

00:04:20 ◼   ► it's often difficult to reason about the effectiveness and importance of them,

00:04:27 ◼   ► especially when you're trying to balance

00:04:29 ◼   ► the various different choices and options you have for how you spend your time.

00:04:33 ◼   ► You need to know what it is you're doing so that you can understand why you're doing it,

00:04:37 ◼   ► so you can ultimately understand whether you should be doing it.

00:04:40 ◼   ► So the first kind of update is what I would call a compatibility update.

00:04:44 ◼   ► This is an update that exists to allow the existing feature set of an application work a new hardware,

00:04:52 ◼   ► a new operating system against a new API in the back end, something like that.

00:04:56 ◼   ► You're not really adding things, you're just making sure that it continues to work and fixing it.

00:05:01 ◼   ► These are often things that you'll have to do around the iOS updates.

00:05:05 ◼   ► And some of the changes that you are making

00:05:09 ◼   ► are not adding functionality or improving things.

00:05:11 ◼   ► They're just addressing bugs.

00:05:13 ◼   ► Apple changed the way that rotation works.

00:05:15 ◼   ► And so you need to make a change to your code

00:05:17 ◼   ► to make it so the rotation continues to work.

00:05:20 ◼   ► That's not enhancing the functionality.

00:05:21 ◼   ► It's just making it so that the existing functionality works.

00:05:24 ◼   ► The next kind of update are remedial.

00:05:27 ◼   ► So a remedial update is something

00:05:29 ◼   ► that is designed to correct a flaw or deficiency

00:05:33 ◼   ► in the existing functionality.

00:05:34 ◼   ► So this is your bug fix update at its simplest.

00:05:38 ◼   ► But essentially, it's something where you had originally said,

00:05:41 ◼   ► the app does X. It turned out it didn't quite do X.

00:05:45 ◼   ► And so you do an update to make it so that X actually works.

00:05:49 ◼   ► The next type of update is what I would

00:05:51 ◼   ► call a defensive update.

00:05:54 ◼   ► This is an app update that you're

00:05:57 ◼   ► trying to do to keep up with competition,

00:05:58 ◼   ► that you're doing something as a reaction to another customer--

00:06:02 ◼   ► or sorry, to a competitor so that your customers like your app

00:06:07 ◼   ► as well as they do of someone else.

00:06:09 ◼   ► And this is very similar to the next kind,

00:06:11 ◼   ► which is an enhancement update.

00:06:12 ◼   ► An enhancement update adds functionality or capability to an app.

00:06:16 ◼   ► And I'm splitting those out in terms of a defensive update

00:06:18 ◼   ► versus an enhancement update,

00:06:20 ◼   ► because the motivation of why you're doing them is different,

00:06:23 ◼   ► even though the actual end result may be the same.

00:06:25 ◼   ► You're potentially just adding functionality or capabilities to your app

00:06:28 ◼   ► in either case.

00:06:29 ◼   ► If you're doing it defensively,

00:06:31 ◼   ► you need to be thoughtful about why you're doing it

00:06:34 ◼   ► in a way that is different than if it's self-motivated

00:06:36 ◼   ► or motivated by your customers asking for a feature.

00:06:39 ◼   ► If you're just doing it to keep up with the Joneses,

00:06:43 ◼   ► you need to be very thoughtful.

00:06:45 ◼   ► And so I'm splitting them out because I

00:06:46 ◼   ► think I've found from my own experience

00:06:47 ◼   ► that to be a helpful way to think about it.

00:06:50 ◼   ► That am I doing this because someone else is doing it,

00:06:52 ◼   ► or am I doing this because I think

00:06:54 ◼   ► this is best for my own app?

00:06:56 ◼   ► So defensive and enhancement.

00:06:59 ◼   ► The next kind is a marketing update.

00:07:02 ◼   ► And this is an update whose purpose is drawing attention

00:07:05 ◼   ► to your application or to try and gather or garner more

00:07:09 ◼   ► revenue for your application.

00:07:10 ◼   ► Sometimes you're not actually doing much to actually--

00:07:14 ◼   ► at its core, changing the functionality of your

00:07:16 ◼   ► application.

00:07:17 ◼   ► But there are things that you're doing whose purpose is

00:07:19 ◼   ► to try and do gather marketing.

00:07:22 ◼   ► One part of this to think about is the way that you do

00:07:24 ◼   ► version numbering is essentially almost always a

00:07:28 ◼   ► a marketing update to your application.

00:07:30 ◼   ► You're making a change from whatever the old version number

00:07:32 ◼   ► is to the new version number.

00:07:34 ◼   ► That's a marketing decision.

00:07:35 ◼   ► That isn't really a technical decision.

00:07:37 ◼   ► You know, deciding when I'm going to call this a 2.0

00:07:39 ◼   ► versus a 1.5.6 is a marketing decision.

00:07:43 ◼   ► And it's a marketing update that you're making when you're

00:07:45 ◼   ► sitting down to plan out your update.

00:07:48 ◼   ► And that could also be a rebranding effort,

00:07:50 ◼   ► or adding other in-app purchases,

00:07:52 ◼   ► or repartitioning things, or some of those types of things.

00:07:55 ◼   ► But there are choices you're making

00:07:56 ◼   ► that are on the marketing side of your application.

00:07:58 ◼   ► And the last kind of app update is a refactoring update.

00:08:04 ◼   ► This is a change that you're making to your application

00:08:06 ◼   ► that doesn't actually change the user-facing portions of your application,

00:08:10 ◼   ► or certainly not in a way that they would likely be noticing

00:08:13 ◼   ► or its intent isn't for them to notice,

00:08:15 ◼   ► but it improves it internally in some way that makes your life easier

00:08:19 ◼   ► or makes your code cleaner or more reliable or something like that.

00:08:23 ◼   ► And so that's different, obviously, than a remedial update

00:08:25 ◼   ► where you're fixing bugs, because those are things

00:08:28 ◼   ► that the user would have probably noticed,

00:08:29 ◼   ► whereas refactoring is things where

00:08:30 ◼   ► you're trying to be more proactive rather than reactive.

00:08:35 ◼   ► So you have compatibility, remedial, defensive,

00:08:38 ◼   ► enhancement, marketing, and refactoring updates.

00:08:42 ◼   ► All right, so in that construct, if you

00:08:44 ◼   ► think about app updates in those six buckets,

00:08:47 ◼   ► what are the things that you need

00:08:49 ◼   ► to be thinking about as you plan an update, right?

00:08:51 ◼   ► Because the process of doing an app update

00:08:54 ◼   ► is in some ways different and distinct than the process and thought process that you should

00:08:58 ◼   ► be having when you're designing the initial release of an application.

00:09:02 ◼   ► Once you, when you're doing your initial release, you don't have any baggage.

00:09:06 ◼   ► You don't have all these constraints of existing users on your platform with a specific set

00:09:11 ◼   ► of expectations, with a specific set of wants, with data that you have to migrate.

00:09:16 ◼   ► There's a lot of things that you have to do that are much more complicated once you're

00:09:19 ◼   ► doing your first update versus when it's an internal build

00:09:24 ◼   ► or something that hasn't yet been released.

00:09:26 ◼   ► And so you need to be thoughtful about this.

00:09:28 ◼   ► The first question I always try to think about is,

00:09:32 ◼   ► is this update necessary?

00:09:34 ◼   ► And if so, why concretely am I doing it?

00:09:41 ◼   ► I find left to my own devices, I will often

00:09:45 ◼   ► do updates just because they are kind of cool or interesting to me technically or personally.

00:09:53 ◼   ► You can have good reasons to do something, but they may not actually be applicable to

00:09:59 ◼   ► a wide audience in your application, or you're just doing it because you can.

00:10:04 ◼   ► Those are situations where it's very dangerous, I think, to be making a change to your application

00:10:08 ◼   ► if you don't have a good, concrete reason for why you're doing it.

00:10:13 ◼   ► I found in my own experience that you can end up wasting a lot of time if you don't

00:10:17 ◼   ► have a good reason for doing an update.

00:10:18 ◼   ► If you're doing it just because you think you should or because, well, that's what you

00:10:21 ◼   ► do.

00:10:22 ◼   ► You put out an app update, then you do a couple of bug fix releases, and then you look for

00:10:26 ◼   ► your 1.1 and you start thinking about what are my 0.1 releases going to be.

00:10:31 ◼   ► You just kind of are looking for things to do rather than having a good reason to do

00:10:35 ◼   ► them in the first place.

00:10:37 ◼   ► The most important question you usually have to ask is, will adding this functionality

00:10:42 ◼   ► or will doing this change improve the app for the majority of my users?

00:10:46 ◼   ► And often the answer to that is kind of a hard one

00:10:50 ◼   ► because your initial feature set is very often designed

00:10:54 ◼   ► around addressing your core set of users' needs.

00:10:58 ◼   ► And your updates will often be trying to address

00:11:00 ◼   ► a diminishingly small number of your users.

00:11:03 ◼   ► If it is an update that will address a problem

00:11:06 ◼   ► that your majority of users are having,

00:11:08 ◼   ► well, that's probably a deficiency in your 1.0,

00:11:10 ◼   ► But that's fine.

00:11:11 ◼   ► Like, obviously, do that thing.

00:11:12 ◼   ► If you can do something that makes your application more

00:11:15 ◼   ► functional, useful, or better for 90% of your users,

00:11:18 ◼   ► of course, do it.

00:11:20 ◼   ► But if it isn't, you want to try and characterize an update

00:11:23 ◼   ► in terms of what proportion of your users

00:11:25 ◼   ► is it actually going to improve, and to make sure you wrap

00:11:28 ◼   ► your head around that, to make sure you're reality checking

00:11:30 ◼   ► its importance and the validity of that.

00:11:35 ◼   ► Another thing to also keep in mind along that same track

00:11:38 ◼   ► is making sure that the people you're doing--

00:11:41 ◼   ► you're implementing it for your actual user,

00:11:43 ◼   ► rather than for your vocal minority,

00:11:45 ◼   ► or for famous or fancy people, right?

00:11:48 ◼   ► Something that I know for myself is you'll often

00:11:50 ◼   ► read a review of your application,

00:11:52 ◼   ► if you're fortunate enough to be written up in a review of,

00:11:54 ◼   ► you know, someone who does app reviews.

00:11:56 ◼   ► And they'll pull out something and say,

00:11:58 ◼   ► I don't like that it does X.

00:12:00 ◼   ► And because it's coming from the kind of a source or a place

00:12:03 ◼   ► that you respect, you often will sometimes

00:12:06 ◼   ► to put disproportionate value on that feedback, or at least I will.

00:12:09 ◼   ► And so I need to always make sure that I'm checking myself and saying,

00:12:12 ◼   ► "Is this something that is only happening to this kind of particular,

00:12:16 ◼   ► you know, this particular reviewer or writer,

00:12:18 ◼   ► or is this something that would actually happen to,

00:12:20 ◼   ► or be a problem for most users?"

00:12:22 ◼   ► Because on the flip side,

00:12:23 ◼   ► one of the things, the questions you need to ask is,

00:12:25 ◼   ► "Will adding this functionality hurt the experience of any of my users?

00:12:30 ◼   ► Will doing this change in any way detract or hurt their experience?

00:12:35 ◼   ► Is it going to make something more complicated?

00:12:37 ◼   ► Is it going to remove some functionality

00:12:38 ◼   ► that they may have relied on?

00:12:40 ◼   ► Is it going to add a risk that something

00:12:43 ◼   ► goes wrong with their data?

00:12:44 ◼   ► Because you need to understand and have, I think,

00:12:46 ◼   ► concrete language around that for yourself.

00:12:49 ◼   ► Because if it does, if it is going

00:12:50 ◼   ► to hurt the experience of some of your users,

00:12:53 ◼   ► sure, you better make sure that you're doing it

00:12:55 ◼   ► for the right reason then.

00:12:56 ◼   ► You need to go back three questions and be like,

00:12:58 ◼   ► why am I doing this?

00:13:00 ◼   ► Because you're hurting somebody in the process of doing this,

00:13:03 ◼   ► And that's always going to have consequences.

00:13:07 ◼   ► Lastly, the last question you always

00:13:10 ◼   ► want to ask when you're doing an update

00:13:11 ◼   ► is, do I expect to be compensated for the time

00:13:14 ◼   ► that I'm going to put into this update?

00:13:16 ◼   ► And by that, I mean updates are taking your time away

00:13:18 ◼   ► from something else, right?

00:13:20 ◼   ► You could be working on a new app.

00:13:21 ◼   ► You could be working on marketing

00:13:23 ◼   ► for your application for the functionality that

00:13:26 ◼   ► already exists.

00:13:27 ◼   ► You could be doing contracting.

00:13:28 ◼   ► You could be playing with your kids.

00:13:30 ◼   ► You could always be doing other things with your time.

00:13:32 ◼   ► And something that I've had to learn myself is that very often I do updates because I

00:13:37 ◼   ► feel like somehow I need to or should, but I don't really have a good plan for making

00:13:42 ◼   ► sure that I'm actually being compensated for that time.

00:13:45 ◼   ► Doing a big point one release or doing a big app update, but without a mechanism for that

00:13:49 ◼   ► really to have an impact on your sales is often going to be a very disappointing thing

00:13:54 ◼   ► where you spend a lot of time, you put something out there and your sales barely change because

00:13:59 ◼   ► It's not either expanding your market,

00:14:01 ◼   ► it's not creating a new opportunity for your existing customers

00:14:04 ◼   ► to give you money if it's adding in a purchase,

00:14:06 ◼   ► if it's adding a tip jar, if it's adding advertising, whatever it is.

00:14:09 ◼   ► If you're not creating an opportunity for the update to give you revenue,

00:14:13 ◼   ► you need to be very, very careful about why you're doing it.

00:14:16 ◼   ► I know I've had to rein myself in a lot of times

00:14:18 ◼   ► where I think of something that's cool that I could do,

00:14:21 ◼   ► but in reality, doing that update won't really actually benefit me.

00:14:25 ◼   ► All right, that's my kind of high-level discussion of updates.

00:14:28 ◼   ► Hopefully that was helpful.

00:14:29 ◼   ► Like I said, you want to be thoughtful about when you're

00:14:31 ◼   ► reviewing an update to make sure you're doing it

00:14:33 ◼   ► for the right reasons and reasons

00:14:34 ◼   ► that you're going to be compensated for.

00:14:36 ◼   ► If you have any questions or comments about the show,

00:14:38 ◼   ► you can email me, david@developingperspective.com

00:14:41 ◼   ► or @m_davidsmith on Twitter.

00:14:43 ◼   ► Maybe have a great week.

00:14:44 ◼   ► Happy coding, and I will talk to you later.