Clearly, iOS is a massive, continuing success. But a couple recent headlines got us thinking about improvements Apple could make to the overall iOS experience: Path was publicly harangued after it was discovered that its app uploaded the entirety of users’ address books to Path’s servers. Developer Anton Sinelnikov’s apps were pulled from the App Store—not just for being ripoffs of other apps, but for being terrible ones, at that.
Those stories and others got us thinking: With just a few small changes, Apple could make iOS and the App Store markedly better.
iOS is exceedingly careful about protecting your location privacy. Apps that want to use your geographic location must seek your permission first. You can enable or disable location permission for apps any time after the fact too, by visiting Location Services in the Settings app.
But if an app wants to access the entire contents of your address book, it can do so freely, even transmitting that data to a remote Web server and calling your ex-girlfriend to tell her you still have feelings for her. That was the focus of the recent Path kerfuffle wherein it was discovered that the social networking app would do just that, save for calling your ex—allegedly. Path apologized for its address book snagging, claimed to have wiped its entire database gathered from said snagging, and released an update to its app that seeks your approval before uploading your address book (to better help you connect with other friends who use the service).
This kerfuffle should never have been able to kerfuff in the first place, though. Apple ought to put the same privacy pop-up restriction in place before apps can get at your personal data you store with iOS’s built-in apps, as well as providing granular controls for your personal data, just like it does for location. That wouldn’t hamper apps that need access to your address book or calendar in the slightest, just like it doesn’t hamper apps that need to know your location now. Rather, it would simply keep your own personal data safer, and let you decide who gets to do what with it.
You’ve heard great things about that app—Angry Vintage Photo Filter Zombies with Friends!—but you’re not sure you’re ready to pony up the whole $2 it costs. If you’re not laughing right now, that’s because you know it to be true. Wouldn’t it be great if you could try out an iOS app before buying it?
Yes, yes, a thousand times yes. Right now, it’s up to the developer to provide either a free version of an app with fewer features or other restrictions, or to distribute a free app that users can try out, then buy the full features via in-app purchase. That’s frustrating, to put it lightly. Software demo versions are a tried-and-true tradition, and a great way to let prospective users decide whether or not a particular app is really their cup of tea.
When developers submit their apps to the store, Apple ought to allow them to select what kind of demo version they want to offer—timed, limited to a certain number of launches, feature restricted, and so forth—and then implement a way for those conditions to be monitored by iOS. That takes the onus off the developers, and encourages users to download apps freely, and then buy only the ones they really want.
Oh, and let’s not forget to clearly mark demos for users—we’re thinking the same sort of sash that gets used on new Newsstand issues. And make it easy for users to upgrade from a demo version to the full version with a tap of a button—both developers and users will send their heartfelt thanks to Cupertino.
There’s a cynical downside to Apple implementing such a solution: The current approach requires that you spend money on apps whether you’ll like them or not, whereas the approach we’re proposing might mean folks spend less cash by avoiding apps that turn out to not be right for them. Let’s take the optimistic view instead here, Apple: Maybe folks will start buying more apps if they needn’t fear they’re about to waste two New Jersey Turnpike toll payments on a possible lemon. Plus, it’s a great way for users to avoid apps with, shall we say, limited functionality that are designed more to part unsuspecting consumers with their cash than to provide a useful service.
Upgrading on a Curve
Last week, Tapbots released Tweetbot 2.0 for iPhone and Tweetbot for iPad. Each version costs three bucks.
That means that folks who already owned Tweetbot for iPhone scored a free upgrade to Tweetbot 2.0, but still needed to cough up another $3 if they wanted to buy the entirely separate Tweetbot for iPad app. We have no problem with Tapbots charging customers for brand new functionality that came out of brand new development and included brand new features (chief among them, “iPad support.”) But why should we have to buy two separate versions of the app?
Because Tapbots had no real alternative. Ideally, the company could charge existing customers $3 to upgrade to a newly-universal Tweebot app, but force entirely new customers to pony up $6 instead. Unfortunately, however, Apple doesn’t allow such pricing options in the App Store.
This is not a problem that in-app purchases can solve, for a variety of reasons. (For one, what would an app in need of an iPad-friendly in-app upgrade show when you first ran it on an iPad? An iPhone-sized interface? A blank screen pointing you towards the in-app upgrade button? Good luck getting Apple to approve that.)
Paying money to upgrade software isn’t a new concept; we’re used to it. Right now, Apple’s seeming suggestion is to launch new standalone apps each time developers want to release a major upgrade—but that’s obviously no solution either. When the Tweetie app (the one that predated, and eventually became, Twitter’s official app) went from version 1.0 to version 2.0, Tweetie 2.0 was a standalone purchase, separate from the initial app. That meant no incentive pricing for owners of the first version, which is hardly a customer-friendly approach—but what else can developers do?
One gets the sense that Apple would prefer to leave its App Store simpler, with nary a notion of paid upgrades. But one further gets the sense that this approach doesn’t benefit consumers in the long term. And as the App Store gets more mature, developers face an unpleasant choice: Keep rolling out free updates, or alienate customers by charging for all-new versions.
Let’s make a deal
Along those lines, it would be handy if developers had more flexible control over the pricing of their apps. Sure, right now they can drop the price for a limited time, and advertise that on their site or in the app’s description, or hand out redeem codes that allow a limited number of people to download a free copy of the app—but that’s a pale shadow of the incentives that app makers have long been able to offer for Mac OS offerings.
Imagine if developers could give out coupons to reward their users and allow them to try a new app at a price break. Or partner up with other developers to offer some sort of cross-promotion so that when you buy Studio A’s new app, you get 20 percent off an app from B Productions.
We know well that many users like buying bundles of apps, so why not give developers an opportunity to team up with others, or even just create a package deal for their own applications? The App Store is a vibrant economy; there’s no point in handcuffing developers who are looking to build their own business while also delighting consumers with great deals.