The iOS App Store really is a brilliant thing. I first learned to program way before internet access was widely available, so the options for sharing my first creations (in STOS Basic, on the Atari ST), amounted to 3.5in floppy disks – today, if you can code something you can easily distribute it to a global audience of millions. It. Is. Brilliant.
But let’s not pretend that the whole affair is flawless. Over the past year or two of working with apps I’ve been mentally compiling a wishlist of ‘Stuff the App Store really, really should do better’ – I don’t expect Apple to care, but since I’m waiting for a 6GB file to download over domestic broadband, here it is. If nothing else, it could be interesting to look back in another two years and see which, if any, have changed.
Free with In-App-Purchases
The whole reason this list popped back into my head today is the news that, finally, Apple seems to be making small inroads to fixing this long time issue. Many developers – my company, and my personal business, included – make use of a model where a free app can be used to offer paid-for content. My work is making magazine apps where the reader, and some articles, are free but others are paid for. My personal apps offer a limited amount of function for free, with a payment unlocking more.
Neither are entirely free, and I’d never claim otherwise, but the App Store marks them with a big ‘Free’ button, and that annoys some customers who feel they are being misled. It’s bad for them, bad for us (ONE STAR), and not exactly beneficial for Apple. It seems that the company is now marking these apps with a note on the web store view – I really hope it can find a way (‘Free App’?) to do so in the main store.
Sort out International Subscriptions
The Subscription concept used in Apple’s Newsstand is, well, odd. For one there’s the fact that subscriptions are mandatory for Newsstand, and the ‘Mandatory Free Subscription’ concept that allows free-issue publishers to work around that. But more importantly, the in-app subscriptions do not support geography.
By way of example: say I sell a magazine called Unicorns Monthly. People in, say, Narnia buy auto-renewing subscriptions. I then have to remove the app from sale in Narnia (legal letter from an angry lion) – a process Apple makes very simple. What I can’t do is stop the in-app subscriptions of my customers there, so they will continue to be billed. They’ll keep getting issues for a while, but if a mandatory update is needed it’ll be unavialable to them, and they are left with recurring payments for a product they can’t use.
It’s bonkers. If an app binary is no longer for sale in a given territory, why not make the IAP subscriptions off-sale in that area, too – that would allow app publishers to wind down support properly.
Buy, buy, sell, sell
Here’s a big one: you can’t move any app from one account to another if the publisher is bought or sold. This isn’t just a magazine thing, but it becomes an even bigger pain in the backside when the apps have subscriptions attached. My team produced four magazine apps with significant readerships – when we set up as an independent company, there was no way to take those apps with us.
The best you can do is set up a new app and close the old one, but then there are hundreds or thousands of customers – many of whom you may not even be able to contact, because Apple subscribers have to opt-in to share even an email address – who have paid for a product that disappears. There are strategies for mitigating this problem (essentially, batch importing known users into a separate authentication service for the new app, and notifying old app users of the process), but it’s a horror.
Moving apps between accounts must be a pain for Apple. But I’d pay for the service. Big companies would pay a lot.
No API for data
A minor thing, but there’s still no official API for getting app sales data – instead you can use the web interface, third party tools (I like AppViz), or set up CRON jobs to run shell scripts that use a Java autoingestion class provided by Apple (I like that too, because I’m a geek). A proper API, though, would allow for more and better analysis tools.
ONE STAR
And here’s the big one. The current app review mechanism allows angry people to quickly lash out at a developer – sometimes with good reason, sometimes not – and, because happy customers are seldom as vocal as mad ones, pushes developers towards ‘Why not rate this app’ nag screens in order to get positive feedback on the board. In many cases, angry reviewers could be made happy with just one sentence explaining that, yes, they *can* do what they want, by tapping button X, or whatever – but the developer has no way to contact them.
It’s a tough one to fix, of course, but here’s my two cents: developers should be able to ‘answer’ any review, positive or negative, in up to 150 characters. This response would be sent, by email, to the reviewer. After this response, the reviewer would be offered the opportunity to change their review rating. Meanwhile, when an App Store user chooses to download another app, they could be offered the chance – while waiting – to quickly star-rate their last purchases.
Sound fair?