Chapter 13. Upgrading

Developer Name: Marco Arment

Development Company: Marco Arment/Tumblr

Tags: Release Strategy; App Store; Iteration

URL: http://marco.org

The life of an app depends on more than just initial coding and design. It also relies on knowing how to handle the second act: upgrades, name-changes, spin-offs, price adjustments, and so on. And it means adapting to the fast-changing mores of the App Store.

To understand all that quizzical stuff, this chapter consults Marco Arment, lead developer of the blogging platform Tumblr, which claims 2 million users and one of the most innovative and user-friendly Web interfaces around. Arment is also author of the popular "read later" app Instapaper for the Web and iPhone (pictured in Figure 13-1). You can find more of his thoughts about the iPhone, the App Store and the Web at large at http://marco.org.

The simplicity of Instapaper's UI belies its clever concept and execution.

Figure 13.1. The simplicity of Instapaper's UI belies its clever concept and execution.

One question many of the developers in this book have pondered: do I charge for my upgrade? Do I charge for my app at all?

I just think totally free apps are just stupid these days. I don't mean put it in such harsh terms; I just don't think that people make that big of a distinction between free and 99 cents when they're browsing through the App Store for new things to download. I think those [price-points] are so close in people's minds that they're willing to take the 99-cent risk.

There still ends up being big difference in [sales] volume, but relatively, if you're going to release an app, I think releasing it for free is only something you do if the app is something that corresponds to a profitable web or desktop service. Zipcar's app is free, for example, because they don't need the app to make money; they make money through other means. So if you have that sort of external product that the app is kind of an ad for or kind of added-value for something else, then that's when you make a free app. I don't think it makes sense to have standalone functional app on the phone be free.

What about ad-supported apps like your free version of Instapaper?

I think ads are a total non-starter on the phone. I've partnered with The Deck for Instapaper Free, and that's the only partner I would've considered for ads. Almost every other ad partner is terrible.

That the ad quality is so bad on the iPhone is not the ad providers' fault—it's the advertisers', really. They're often serving things that are intrusive, or really cheapening, so you end up having this brilliantly designed app, and this lame movie trailer starts playing in the footer. I don't want that.

Another problem with advertising occurs when your app goes offline. West Coast people who don't spend a lot of their time underground like we do here [in New York] often don't realize that this can cause problems. An ad isn't necessarily going to be useful when you're constantly losing reception, and here you've devoted a good strip of your screen to that ad block—you're giving up valuable screen real estate for it, and it's not registering clicks.

I've ruled [ads] out as a primary monetization option for almost everybody. And if I didn't have a paid Pro version of Instapaper, I wouldn't have an ad-supported version. I put ads in my free version, not as a replacement for Pro, so I can make something off those people who are costing me money to run on the server end. That's really all those ads are for.

Are free upgrades a good idea? Or should you make users pay again? Let's use Exit Strategy NYC, featured in Chapter 6, as an example.

There are two options in the case of Exit Strategy NYC. Jonathan could make his version 2.0 an entirely separate app, and advertise this new subway app "with Exit Strategy" data. But I think I'd still do the free upgrade route; from what I've seen, the new-sales numbers are much, much larger than the upgrade-sales numbers.

Part of the reason for this, I think, is that most people don't keep these apps. They try them out, and there's a high deletion rate. There are a few factors to consider with Exit Strategy NYC: one is that I would expect a high deletion rate for it in its current version. Once you know all your routine stops, you don't need the app that much anymore. You know the three stops that you actually use every day, and that's about all you need. For apps like that, upgrade policy becomes less relevant. Even if your second version is more useful, many users have deleted the first.

Another factor is that this is an app targeting New York, and people are less price sensitive here. When you're selling to markets like this one, you can get away with being more expensive than you could be somewhere else.

All that said, I'd reiterate that the free upgrade is the way to go—not because I don't think people wouldn't pay for version 2.0, but because I think there are so few people upgrading relative to the number of new buyers. The number of upgraders is so small, relatively, that it's not worth pissing them off. Those are the people that are going to be talking about the app to their friends.

Loren Brichter, who developed Tweetie 2 and is featured in Chapter 1, decided not to do a free upgrade. Yet Tweetie 2 still shot to the top of Apple's "top grossing list" when it went on sale. How is Tweetie 2 different from Exit Strategy NYC?

What Loren did with Tweetie 2 was indeed different. I think that the paid upgrade was fair because the app was already very, very popular. Most Twitter users who own iPhones and want a Twitter app on the iPhone already knew about Tweetie, and they've already decided that they use Twitter enough to buy this app instead of using a cheaper, or free, competitor. So I'm guessing that Loren's users are so dedicated that he would see a lot more upgrades than most apps.

What happens when the scope of your app changes with a second version, as with Exit Strategy NYC? Should Jonathan have changed the name and risked losing the benefit of SEO in the App Store, in the hopes of having a name that describes the app better?

I would never call what's in the App Store "SEO." He's right to have kept the name, but I think doing it for SEO reasons is looking at the issue the wrong way. It's hard to get found in the App Store. But [Jonathan] would be wrong to assume that people are finding it now. The question is: are people finding his app because of the App Store, or are they finding it because of external pressures, like people blogging about it or people talking about it? I think with a "real-life" and location-based app like his, you're going to get a lot of word of mouth—friends being like, "Hey, look at my iPhone, look at this cool app I have on it." I think very few people are finding that app in the App Store randomly, or through any sort of search characterization. The App Store is so cluttered with crap that it's really hard to search for anything by category or function. It's much easier to search for things when you know the name. It's the same thing on YouTube. No one searches YouTube like, "Oh, I'll just type in funny videos and see what I get." Of course not! There's just too much crap. So people go to YouTube when they want particular clip that they can search for.

The truth is, if you are not on the top of the App Store [lists], you're invisible—you don't exist. The Top list matters the most, and then staff picks, and the editorially selected ones, too. If [Instapaper] is on one of those, my sales will usually double or triple for the week that it's there. Then they go right back down.

Does the name of an app need to convey exactly what the app does?

That's a very hard choice. First of all, Exit Strategy NYC is a great name, so I don't think it would be worth giving up the name unless what the new version was doing didn't make any sense at all with the name. There might be a slight problem in that the words "Exit Strategy NYC" don't really tell you this is a subway mapping application. But he's going to have trouble competing for that "subway app customer anyway, because if he's priced at $3.00 already, he's not competing for the impulse buyers—and those are the people that actually need the title to say NYC Subway Map to make the purchase. If he is trying to compete for them, he's probably going to lose on price.

If he's already competing for a kind of premium market—a market for people who do a slight bit of research before buying anything—then he doesn't need to really worry that much about having the name say "subway" or worrying about App Store SEO; that's all irrelevant.

Do you think buyers have price "benchmarks" that developers should attend to?

Well, there is no one global answer for all apps; games in particular seem to command lower prices, for example, which is unfortunate because they take a lot more work. It seems that you can't launch a game for more than $3.00 unless your name begins with EA. So many times I'll read about some great game, and I'll go to buy it and I'll see it's 99 cents and I'll just feel bad; I would've paid more! So when we're talking about price, you've got to segment out the games, and that's a big segment of the market.

People talk a lot about downward pressure on prices, but I think the factors that contribute to that supposed downward pressure don't actually matter. Things like customer reviews and star ratings are a good example; they don't matter, not a bit. They don't affect sales whatsoever. Especially if you're not going for the impulse buyers, and if you're not trying to compete for the Top lists, then nothing in the App Store matters, because people usually already have decided, even before they click the App Store link on whatever blog they're reading, that they're going to buy the app.

When you hear people say that games need to cost x amount, or apps have to cost x amount, they're often saying that because they read some user review where somebody says, "Well this is great, but it really should cost less." But user reviews are just a bad sample; they do not represent the whole of user-ship at all. When people review apps, they are encouraged to be negative. The rate-on-delete dialogue really encourages negativity.

So reviews are skewed negatively in the App Store?

Yes, because there's no corresponding positive prompt. It'd be one thing if the third time you launched an app, Apple popped up the same dialogue that said, "Do you want to rate this app?" You know, some kind of corresponding equivalent that was in a positive context. But if you're deleting an app, you probably didn't like it very much, or you probably just no longer like it, or find it no longer useful. As soon as they added rate on delete, everybody's star ratings plummeted.

Point being, the people who are rating or commenting are very much a non-representative proportion of the population—most people, I think, are willing to pay more than those reviews suggest. Ask developers who actually sell something, they can tell you: "At this price I got this many sales, and at this [cheaper] price, I got this many more." The difference usually isn't massive. Many would tell you: "I haven't touched my price and I'm still doing fine."

What is the case to be made for apps over $5.00?

I know a lot of people who are still in the $5.00 to $10.00 range. PCalc [RPN Calculator, pictured in Figure 13-2] is a great example. From the very beginning, the developer launched at $10.00, just like I did with Instapaper; he's was like, "This is what I know it's worth, and I'm not budging on the price." I don't think he's ever even had a sale, and he didn't even have a free version until a few months ago. Still, he's doing fine! Because people who buy an advanced calculator app are probably somewhat careful buyers who are willing to pay $10.00. I mean think about it: $10.00 in the software world is still nothing.

The Top lists have also caused the [price] benchmarks to be set very strangely. The reason why we see so many 99 cent apps on the App Store is because people look at the Top lists and see everything there is 99 cents, so they think they have to price their app cheaply to succeed. But that's just wrong: people are willing to pay more than that. Maybe not 40 million of them, but you don't need 40 million downloads.

Here's what I mean: if you already have a limited audience, you can price [your app] higher and make up for the lack of volume you're going to get. Obviously you also have to consider your overhead, to make it worth it doing; sometimes you have to price it at a certain price or higher, or it just can't exist. That goes even for developer hobbyists, developers who have day jobs and do this in their free time; it's easy for them to think, "Well this doesn't really cost me anything for me to make, I'm doing it in my free time." But there's cost of time, opportunity costs, and sometimes cost of back-end support.

PCalc RPN Calculator, by TLA Systems Ltd., debuted at $10.00 and has stayed at that price point. "People who buy an advanced calculator app are probably somewhat careful buyers," says Arment.

Figure 13.2. PCalc RPN Calculator, by TLA Systems Ltd., debuted at $10.00 and has stayed at that price point. "People who buy an advanced calculator app are probably somewhat careful buyers," says Arment.

You dropped the price of Instapaper Pro. What did you learn from that?

I dropped my price from $10.00 to $5.00 in late June [2009]. I had a feeling I was going to keep it at $5.00 permanently, but just in case I called it a sale in the event I wanted to go back up without too much flack. It ended up that my average per day is significantly higher—it's more than twice as high—so therefore, it's worth keeping the price at $5.00.

Why not go lower?

Well, it's important to remember how much relativism is going on here. When I went from $10.00 to $5.00, that got a lot of press and that was the biggest sales day I've ever had. Everyone who was used to the price at $10.00 said, "Oh my God, the price is cut in half from $10.00, it's a sale, jump on it!' Five dollars is still considered expensive for the App Store, but that didn't seem to matter to them—to them it was a sale. So if you start out high, you have that luxury of being able to incite more sales by a temporary reduction, at a price that is still a pretty good price for your product. But if you start at one or two bucks, you don't really have that ability.

Zach West, who is profiled in this book in Chapter 10, said he deliberately priced Prowl a little on the high end to cut out novice users who would flood him with support requests. Do you always want as many sales as possible if you're doing your own customer service?

Well, Instapaper is always a support-heavy app because it requires the installation of the bookmark. Installing the bookmark on the phone is a train-wreck of usability, it's really terrible, there's no good way to do it. There are two awful ways to do it, and you have to walk the users through creating the ["Save Now"] bookmark, then saving it, then editing it—I mean the process is just miserable.

It was really important that I got so much email in the beginning, because the users really did help me refine the instructions and the features and everything, and I made some really good documentation pages based on those emails. Finally I put up a note on my support page saying, "I'm sorry, but I can no longer answer emails about installing the bookmark, here's my best instructions," because most problems you just can't diagnose by email.

But in my case, at least, I have not really found that it has anything to do with price. Instapaper is a little weird because I have a free version, so I'm guessing most people try the free version first.

It's also worth noting that when I dropped the price to $5.00 I removed the mention of Instantpaper Free from the description of Instapaper Pro. Previously, I had a note in Pro that said in all caps, PLEASE TRY THE FREE VERSION FIRST. The situation I didn't want was people to buy Pro for $10.00 and then not being able to install the bookmark, since I can't give refunds. Right before I changed the price, the number of emails I was getting for the [bookmark installation] support issue had dropped to zero. And that's why I figured it was okay to remove the mention of free. As a result, I have very few people who bought Pro and who can't figure it out; maybe I get one a month. For whatever reason, Instapaper buyers do seem a little more technically inclined, and I am able to talk them through it.

Like a lot of iPhone apps, Instapaper has a desktop version. Should you build an iPhone companion app as a standalone?

Overwhelmingly yes. My initial assumption was that nobody would ever need to install [the Instapaper bookmark] on their iPhone, because they could sync it over from Safari on the desktop. I would always suggest that to people, and found that nobody was syncing their bookmarks.

Overall I was amazed at how many people do so much computing on the iPhone without using a computer. There are lots of people who write all their email on the phone, and it's become their primary computer—especially among less technical adults or teenagers who don't have their own computers but have an iPod Touch.

There are a lot of Windows people with iPhones too, so in the case of [developers] with Mac apps, the iPhone may be the only way to serve Windows customers. In that respect, it's a really good place to be if you want to sell software for money.

Why haven't we seen more apps like Prowl that use push notifications in a useful way?

Push has surprised me in a few ways. I was surprised by the complete lack of fanfare when it was turned on because people had been complaining for so long that it had been delayed—"We need push, I can't believe it's not out yet"—and when it came out, hardly anybody began using it.

I think people realized after they were given push that in most cases, they don't want it. It can actually get pretty annoying. Another thing that surprised me is that I had assumed before it came out that there was going to be this quick rush where one dominant app was going to replace text messaging with its own network, so it would be functionally equivalent but free. To the best of my knowledge, I don't think that's happened.

When iPhone first came out, there were a few missing links with MapKit; do you think push will evolve the same way?

No. I really think push is one of those things that people ask for, they think they want it, and if you give it to them, they quickly realize they don't want it. Users don't always consider the bad parts of what they're requesting. When people were asking for push notifications, they probably weren't considering that you could get overloaded with them, and they would constantly bother you about something insignificant. And a lot of people don't have the self control to limit the amount they receive, they go on information bingeing, and they want alerts for everything, and they end up with the most annoying phones in the world.

I feel the same way about how people abuse [RSS] feed readers. They subscribe to feeds that give them 1,000 unread articles a day, and they feel overloaded: "Oh God, I have too much to read!" Well, just delete some! But they don't make that leap sometimes. Twitter's falling into this trap now, with lists; people are saying they need lists of people so they can sort them and organize them. Just follow fewer people! Or create another account! It's not that hard!

So you can't assume your users have self-control?

Right! It's a very big problem. When I added feeds to Instapaper 2.0, I added folders, and I had this idea that I could add "starring" to folders like on Gmail. The idea was you could see other people other star articles, recommendations, shared folder lists, and everything else. At the same time, I thought, "Oh, I'll add some feeds, why not?"

Then I realized: this is going to be abused to hell. What I really wanted was a feature to give me something to read. But I thought I needed to limit it: the phone will only ever hold the most recent 250 articles, total. And its feed folder will only show the most recent 10 within itself. There's no way to get by this by paying more money or something like that—I'm talking about the Pro version, too—because that's not why I put the limits in place. I put limits in place to protect people from themselves. Because if you have a lot more feeds than that, updates will take forever to upload, they'll be loading all these things, not really reading, if the folders hold more than 10, they'll develop these huge backlogs when they ignore a site for a few weeks.

I have a similar feeling about "unread" indicators. People always ask me why I don't add an unread indicator to folders. No! I don't want to do that. People think they want that, but to me, an unread indicator indicates urgency and an obligation. It's not a simple status count. You see the red number, and it's like, "Uh-oh, I need to do something, something needs my attention!" And that's not what Instapaper is. It's specifically designed to remove that obligation from you, and to be no obligation.

Why didn't you make Instapaper for iPhone a mobile web site instead of an app?

Well, the main advantages would be for a web app you totally bypass the App Store. You could update quickly, anytime you want, and you could violate [Apple's] policies if you wanted.

But there are lots of problems building a web app for the iPhone. Before the iPhone 3GS and the 5th gen iPod Touch, you only had 128 megs of RAM, and WebKit is very heavy, very RAM-intensive. Because of that, there are a lot of things you just can't do if the base of your app is a web view, because it removes much of your usable RAM already. Now the web view does support canvas elements, which allow you to do a lot of fairly well accelerated calls. But still you're always going to get better C code, always. And there's always going to be capabilities with the phone that Apple will not have access to through JavaScript. Hardware's part of it—things like the accelerometer data, you can get some of it in JavaScript, but you couldn't do tilt scrolling, for instance. Another problem is that you can't really take a photo with the camera, and you can't do anything with the photo: you can't prompt user for a file to upload, for example. You also have very limited control over the keyboard, and which keyboard is shown, and what input is shown or not shown.

As far as a I know, I don't think you can do multi-thread JavaScript either. I don't think WebKit supports that yet.

If you're building a web app, there are also behaviors in WebKit that you can't override. I even hit some of them in the web view of my app. If you tap and hold a link, for example, the OS will pop up an action sheet asking you to copy, cancel, or open a new window. Or in the case of a web view, it'll just say copy or cancel. That's new to 3.0, but I can't disable that on my app. I have no control of that menu, and I'm not even notified when that shows up.

There are also all those little built-in browser features that you can't disable in your web app, too, like selection of text. If you have something that is technically a link, but you're using it for some image JavaScript thing, if someone taps and holds it, it's going to perform the copy action.

Or if someone leaves your app, they switch to something else, on a 3G with only 128 megs of RAM, when they come back, it'll be flushed out of memory. It'll have to be reloaded, but it doesn't necessarily notify you in the right way that it has reloaded. It's very strange.

Another problem occurs if you hit a JavaScript exception; mobile Safari will do what every other browser does when it hits an exception, it will just stop executing the JavaScript. No notification happens, and you can't catch the exception that easily—there's nothing you can do. The web app just stops working and nobody knows why.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.218.136.90