The state of the Apple App store (both IOS and Mac) have been a topic of discussion among developers on and off for a couple of years now, but over the last few months this discussion has been growing and it’s clear developer discontent is growing. There have been a lot of suggestions about how to fix the stores, but a lot of them tend to be simplistic (“we need paid upgrades”) that don’t consider the complexities involved, either technically in the back end or in the business logistics.

Rene Ritchie at iMore has just waded in with a very well-thought-out What no indie developer wants to hear about the App Store. He touches on an aspect that I don’t see talked about much — that perhaps Apple doesn’t see the store as broken. It is, after all, bringing in lots of money for Apple and developers, as Apple touts at every product announcement and analyst meeting.

My take: I don’t think the App Stores are broken; I think they’re doing exactly what Apple wants them to, because Apple’s interest is in supporting the corporate app developers and the larger studio developers. They care about the NetFlix app and Adobe’s applications and what Gameloft is doing, not about what the small indie developers want or need.

In fact, I’ll argue that the biggest problem the App Store has is that there are too many developers trying to squeeze into that large — but finite — space that is the App Store ecosystem.

On twitter’s discussion of Rene’s piece today, someone commented that the store made it impossible for many apps to be sustainable. My response was that most apps don’t deserve to be sustainable, and that’s the first big reality check developers need to get their heads around:

It’s not Apple’s job to guarantee your app to be successful. Most apps won’t be, and if you look through the App Stores, most of them don’t deserve to be.

A quick note about my background: When Palm attempted to reboot and build a phone around the WebOS platform, they hired me as their Developer Community Manager. My role was to act as a platform evangelist, a developer advocate back into the company, help teach the developers how to work with and succeed on the platform, get things fixed when stuff broke and generally act as the developer cat herder and the voice of the developer back into the teams making decisions that impacted them. As you can see from how well the WebOS platform did, I obviously did an awesome job of this.

As part of this, before we hired a team to run the app store and do app reviews, I did those roles, and I managed review and publication through much of the beta, and I was part of the group that helped make decisions about whether to approve apps into the store where the decisions were unclear and subjective — and yes, that means sitting around discussing whether “Jiggly Boobies” violated content standards (it did, and was repeatedly rejected) and which Kama Sutra apps passed guidelines and which ones didn’t (the ones using stuffed toy elephants did; others… didn’t). Even after the store team was hired (and we brought in someone from Apple who was a big plus for us in figuring all this out) I still got stuck managing and policing the review/comment area of the store, to the degree you can police a feedback area where they didn’t bother to build in basic administrative tools like blocklists or some kind of interface to let me look at or delete abusive posts…

The scale of what Apple has to do is an order of magnitude bigger and more complex than what we had to deal with launching the WebOS app store, but many of the issues and problems are the same and many of the complaints I’m hearing about Apple’s Ap Stores are the same ones I was hearing on a regular basis at Palm. And this is an important point we all need to understand:

The app store effectively didn’t exist before Apple and the iPhone, so this is all effectively brand new and we’re all still figuring out best practices. And this is all happening as Apple and the rest of us figure out online ecommerce and payment, device security and malware protection and app oversight and developer management on a global scale with the complexity and impact of being compliant with the tax and legal domains of dozens of countries.

It’s a big, big, complex hairy beast.

At Palm I spent a lot of time proposing ways to improve the app store and get our developers waht they needed, ideas that were routinely ignored, of course. This may sound familiar, but the most common request I got from developers was for demos with a pay-to-unlock (as opposed to supporting a free demo app and a paid app, a structure that sucks on many levels) and for paid upgrades. What developers got was In App Purchase (sound familiar?) because companies like Gameloft that we wanted on WebOS were pushing their revenue models in that direction.


The reality is you may not like the “buy a bag of diamonds” model, but it works, and you should take advantage of it in your app design if it makes sense. I see too many developers fighting the app store because it doesn’t support the economic models they want, rather than trying to adapt and use the forms that it does.

Fixing the App Stores

With that background in place, a few thoughts on how Apple could improve things. I’m a strong believer that the indie developers are where the innovation comes from, not to mention the next generation of experts on the platform, and that it makes sense to invest in supporting them beyond what the revenue their apps will return through sales on the platform, but in all honesty, the revenue numbers and analytics make that a tough sell, and Apple is likely in that place where there are 300 proposals on the project list for the next year, and resources for 50 of them, so how do you choose which ones make the cut? If the decisions are driven by revenue, analytics and by discussions with key partners, you start to see why the indie developer needs get neglected. But here are the things I would consider as priorities to lobby for if I were playing developer advocate for Apple.

Well, honestly, first thing I’d want to do is create a developer advocate role within Apple for the indie developers so there’s someone on the inside that can both help Apple understand the needs of indie developers and create a communication conduit back out to them. And hey, Apple, I know this guy who knows this guy…

In my mind, though, there are two core problems that needs to be addressed:

There are too many apps, and too many developers, squeezing into the finite ecosystem of the App Stores. Nothing we can’t fix by nuking 30% of the developers out of the ecosystem. Sucks if you lose the lottery, though.

Reviews and the dreaded star rating are the #1 determiner of sales, and the entire review/feedback/rating system is a toxic dumpster fire of epic proportions and this entire concept and implementation needs to be rethought (but don’t feel bad, Apple, with the possible exception of Amazon, they all suck. Yours sucks about as bad as anyones, it’s not particularly worse than the others, but nobody’s figured this out).

Too Many Apps!

Consumers are conditioned to think that “large number of apps” is a good thing; the thought is that if there are large numbers of apps in a store, they’ll be able to find the app they want. At Palm we were always under pressure by the carriers to get the number of apps up because when people were looking at buying a phone, if they didn’t like the number they’d reject the phone as an option. Quality of the apps wasn’t even a consideration, only the size of the store.

Apple is complicit in this through how hard they promoted the number of apps in their store in the early days, but I think they were connecting to an existing mindset and not creating it, and I’ll be damned if I have been able to think of a way to fix this, but we need to look at changing the discussion from “lots” to good. In a society where the streets are lined with large, mediocre national fast food chain outlets, I don’t see this as solvable easily (if at all).

But let’s talk a bit about how to improve the quality of apps in the store, or more correctly, improve the discoverability of YOUR app in the app store, which is what really matters here. First, and I think most reasonable developers know this, if you think it’s Apple’s responsibility to sell your app, you deserve to fail and disappear without a trace. Apple supplies the platform, you have to supply the sales, promotion and incentives to buy your app. There is no magic here. A common complaint I got at Palm was that people’s apps weren’t selling, and when I asked them what marketing they did, I got some variation of “it’s in the store…”.

There’s no free lunch. Unless you are in at the very beginning of the ecosystem when competition is minimal, you won’t magically be found and users won’t go out of their way to discover your app. Getting into their brain and making them want to try your app is still your job.

Yes, app store discoverability can be improved, and yes, it sucks when someone searches and your app shows up with 300 other apps, but how does your app stand out from that group of 300, and how will a prospective buyer know that? Those are things you need to solve; a better search engine won’t.

That said, I think Apple should be looking at ways of putting the app stores on diets. There’s a lot of crap in there, and not all of it deserves the electrons wasted to display them in a search result. The problem, of course, is how to choose what to purge, and as I said earlier, it sucks if you lose the lottery, dude, even if it makes the ecosystem healthier without you. It seems everyone assumes that when these things happen they’ll be on the winning side…

But there are a few things I think Apple can do to improve the quality of the app store and the quality of search results without getting into editorial/policy decisions about the “worth” of a given app, which is especially tough given the size and scale of the store. And maybe this isn’t a removal from the store, but instead a removal from search results, so if a developer wants to market and promote an app on their own, they can continue to do so and possibly earn their way back into the search results.

First, I’d remove apps that haven’t been updated in three years. Honestly, if you aren’t doing some kind of even minimal bug fixing when Apple releases each new version of the OS, you aren’t really trying and the app is likely abandoned. Stop supporting absentee landlords

Second, let’s find a model to purge the worst apps in the store. Take the 1% lowest rated apps and purge them. This can’t be a straight “worst ratings”, but needs to be a math model that both looks at number of ratings in the last year and how poor they are. You want the 1% with the most poor ratings, not just the lowest 1% (nobody cares about an app that only got one rating. we want the one with 100 to go first).

That second one, of course, needs to be tied to each regional store independently. It sounds easy, but in fact “finding the worst 1%” gets complicated fast but I think is worth pursuing.

I also think Apple should track the “worst developers” in the store, where we can define that as some combination of the two rules above, plus factor in things like DMCA takedowns, app rejections, etc… and choose to revoke their developer privileges. This one would require a lot of thought to make sure we are hitting the actively bad developers rather than the new or naive, but my guess is a lot of the crap comes from relatively few developers pushing lots of generic titles, and finding the worst of the bunch can make notable improvements.

Which leads me to one final thought: I think Apple should consider raising fees to join the developer program to publish apps. I also think it makes sense to have an annual fee (probably one for free, and a higher one for paid or IAP apps), and if a developer doesn’t pay that fee the app is removed from the store.

This has lots of nuances to worry about and is a slippery slope, but the reason I like this idea is that it both helps deal with the abandoned app problem and it puts a throttle on crap apps where people throw a hundred or a thousand or thousands of simplistic, generic apps out there as a way of trying to abuse search SEO and discovery in the store — and we’ve all run into that crap. Putting a price tag on entry into the store, even if it’s effectively a token cost, will reduce this kind of store abuse.

The goal of these ideas is to reduce the noise in the system so that the good apps will more easily float to the top and be found and to reduce the end-user problem of downloading apps only to find they’re crap, which ultimately makes uses think all of the apps in the store are crap. This is all about improving the app store ecosystem for everyone by identifying and removing the mouldy, smelly bits.

Reviews Suck

There is a problem with this approach, and it’s the big problem with the App store in general. Identifying the worst 1% of apps in the store depends in large part with the review ecosystem — user reviews and the star ratings.

Which suck. Massively.

The star rating is one of the top determiners for whether someone downloads and/or buys an app, and the systems are badly flawed to the point of being useless, easily manipulated, and just sit down and talk to developers about how they’ve been screwed by this and they’ll talk your ear off.

And their are no easy solutions, but I think there are solutions. Fixing this is beyond the scope of this piece, but folks who’ve heard me get going on this know I have opinions, and I floated a few proposals at Palm on ways to limit how star ratings suck. I’ll be happy to talk your ear off about this over a beer, or perhaps sometime later write up my thoughts based on the proposals I wrote at Palm, but this thing is already approaching novel length and so I’ll leave it to another time.

But I will say this: the group that’s come closest to solving this is Amazon, and they use a reputation engine that helps them understand what users have a close and float their product reviews up into view, and which users are brainless twits and need to have their reviews buried under concrete, and all App stores need to build in that kind of intelligence as well, because not all opinions are equally valid and there are ways to use the reaction of the community to a review to help judge this and weight that review in among the mass of reviews. And that nobody but Amazon does this is insane.

Was this rant helpful to you? Yes/No.

I do think Apple’s reset of reviews every time someone releases an update is both useful and a huge problem. It’s useful because if an new release is broken that’ll become obvious quickly, but it’s both open ot abuse and it makes it impossible for a developer to build goodwill for their app over time.

My preference is for an app’s primary start rating to be based on a 12 month weighted average, where reviews that are older have less influence than reviews that are newer. Apple should show a “Rating for this release” as a secondary metric, not as a primary one.

And Apple needs to add a “contact the developer” button (maybe allow it to be optional for the developer to have this) so that there is an easy way for them to be contacted at the point where people leave reviews and ratings, because whether you like it or not, people go there and leave support requests and rants, and you want to give developers a chance to circumvent that into a real support loop.

Frankly, some users are just going to rant and whine anyway, but that’s why you want a reputation system driving how much that kind of user can impact an app rating. But many users go to the review area (because it’s easy to find) when they’re having problems with an app, and giving them a way to get into a support discussion rather than dumping it off as a 1 star rating is one way to improve things for all involved, and it’s simple. and you aren’t going to rewire this user’s behavior — so this is a relatively easy option to sidetrack it into the “proper” channel if a developer wants to enable it.

New Economic Models

A lot of developers have called for Apple to improve things by changing the economic models of the App Store. The two biggest requests are, I think, the ability to publish an app in demo mode with a paid unlock, and for paid upgrades.

I agree with them in theory, but take a step back and think about it from the technical back end challenges. You sell someone an app. Two years later, you release a paid upgrade. A customer chooses not to buy the upgrade and stays with the old version. They then have to reinstall their phone (or replace a broken one) and reload and download all of their apps.

What app do they get? Is Apple now required to store every version of every app and keep track of which version goes to every user based on which upgrades they have or have not paid for? This is a logistical nightmare for Apple. It’s solvable, but it’s really tough at best and fraught with problems in the best of sitautions. I can well understand why Apple doesn’t want to do this.

And think about this: you’ve built “Great App”, and two years later “Great App 2” as a paid upgrade. And then a year later, we find a huge security hold in “Great app” the original because of a security vulnerability in a library you used. How do you update it for those users who chose not to upgrade to “Great App 2”?

I don’t know how you — or Apple — could unwind this scenario. Other than making “Great App 2” a separate app, which is, of course, the current (broken) model.

So paid upgrades turn into a real horror show pretty quickly, folks. I think it’s not a case of Apple not caring, I think it’s Apple looking at the edge cases of the various failure scenarios and backing slowly away until they can find a big enough stick to hit it with.

But the need is there. The current situation — publish it as a new app — works but is somewhat painful. One way to improve it is to make it easier to migrate data, but I think the shift to cloud data stores is basically solving that problem for us, it’s not what it was a few years ago.

But I’ve been thinking about ways to solve both the demo problem (the user experience of downloading a free app, deciding to buy it, and having to buy and download the paid one — and transfer data to it — is painful) and the paid upgrade problem, and I think there’s a hybrid scenario that might work.

I’ve been following the work Marco Arment has been doing on Overcast and the thinking he’s put into that app and the business models it uses. For Overcast 2, he went to an IAP patron model. If you haven’t looked at this, you should, and look at the choices he’s made — I think they can be useful for many developers and apps.

But it got me thinking about ways to use or extend IAP as paths through this maze of pain. I’ve also been looking at how many of the bigger developer groups — and I’m notably pointing at Creative Cloud from Adobe and Microsoft 365 — have been shifting to the membership/subscription model. Yes, there’s been a lot of noise and pushback on Adobe but I think they ultimately got the pricing right and their revenue numbers show that users have in general bought into Creative Cloud as an option.

So here’s my thinking.  I would like a way to use IAP to enable something like a demo mode that unlocks to a fully enabled app. you can download it for free, once you decide you want full capability, you use IAP to unlock it. Developers can choose this to be a one-time buy (permanent capability, effectively like buying an app today) or as a subscription model with annual renewal.

If a user chooses to not pay the renewal, the app would then pumpkin back into demo mode. There are some nuances here for developers to deal with, such as this return-to-demo taking users data hostage, but they can be managed.

This would avoid the problems caused by the paid upgrade problem’s edge cases. it creates a recurring revenue stream for users by adopting in this subscription  model that Adobe and Microsoft have been pushing into the mainstream for us. And because it’s a (relatively easy, he says not having to write it) enhancement to existing IAP technologies and not a massive rewrite like the paid upgrade would be, it’s fairly easy for Apple to add to the store.

So it seems like a nice compromise where everyone wins. or at least doesn’t lose badly. And IMHO, I think between the existing pay-once model, allowing the download demo and unlock model through one-time IAP and an annual subscription model, plus more use of Macro’s patronage setup, we more or less have economic models covered in the App Store pretty well.

And… It’s not a huge technological hurdle for Apple to get there or a huge pain for developers to figure out how to use or implement. Apple just needs to decide it wants to do it…

What do you all think?

One more thing

Oh, before I go, one more thing.

As long as we’re talking about App Store economic models, how about this one? If Apple were to create an “Apple Music for Apps” where users paid a flat fee subscription and could download and use any apps published into this service, would you as a developer consider publishing your app into it? Assume you’d get paid a royalty based on number of phones you’re installed on and also how often the app is opened (with details of the mix between the two worked out later).

It seems to me for a lot of utility style apps, this might be the best possible world, but I haven’t really worked out the details of the model yet. Still, I thought I’d throw this out for discussion since I think it has some interesting opportunities..