Tuesday, January 6, 2015 [Tweets] [Favorites]

The 2014 Panic Report

Cabel Sasser:

My gut says no, that full price every single time is rough, but then we’re setting the precedent that maybe not all of our major upgrades are paid upgrades, which we’ve been pretty consistent about in the past. If we could offer traditional discounted upgrades via the App Store, this paragraph wouldn’t exist. This is one area where the App Store feels like one of those novelty peanut cans with the snake inside.

[…]

To be honest, I was pretty nervous to be pulling Coda from the Mac App Store. But when we finally did it, I felt an incredible, almost indescribable sense of relief — mostly because as we began to wrap up bug fix releases, we were able to immediately post them to our customers within minutes of qualifying them. My god. That’s how it should be. There’s just no other way to put it — that’s how you treat your customers well, by reacting quickly and having total control over your destiny. To not be beholden to someone else to do our job feels just fantastic. (Also to not pay someone 30% in exchange for frequent stress is a fine deal.)

[…]

The results were interesting. We sold a couple hundred fewer units of Coda post-App Store removal, but revenue from it went up by about 44%.

[…]

I can’t comfortably say “the system worked”. It’s still an awful and nerve-wracking feeling to know that, at any minute, we could get thrown into a quagmire of e-mails, phone calls, code removal, and sadness, just by trying to ship something cool.

There’s a little more history here than I’m letting on. We had a very long, very torturous situation with Status Board almost being pulled that we’ve never written up out of sensitivity to our relationship with Apple. I only mention it here because it proves that it is possible to fix these awkward rejection situations without Apple suffering negative PR in the public eye — we did that “offline”. But it took an absolutely massive amount of mental energy and time to work through — positively Sisyphean. I would never want to do it again — I’ve run out of patience, I guess. I can say for certain that the “bad PR” version of the app dispute process is monumentally more effective. Which is a shame.

[…]

This is the biggest problem we’ve been grappling with all year: we simply don’t make enough money from our iOS apps. We’re building apps that are, if I may say so, world-class and desktop-quality. They are packed with features, they look stunning, we offer excellent support for them, and development is constant. I’m deeply proud of our iOS apps. But… they’re hard to justify working on.

First, what a great piece of writing this post is. Second, Panic’s low iOS revenue is a terrible indicator for the health of the platform. If top-quality apps, a solid customer base and brand, and marketing support from Apple aren’t enough, what does one need to succeed? Apple clearly likes Panic-style apps, so you would think it would try to encourage their development. Instead, Apple has designed the App Store to do pretty much the opposite. Why? This strategy seems to make no long-term sense unless one believes that quality apps don’t matter.

Milen Dzhumerov:

It escapes my mind why a premium hardware company would want to run a software store that’s equivalent to a dollar shop (or worse). Yes, people will buy phones because there’s tons of free apps but we’re slowly reaching a point (or already there) where the quality of those apps is so bad, that all other platforms have them as well. The number of apps is no longer a competitive advantage like it used to be in 2008. In the long term, it wouldn’t matter what phone you buy, if all the software is available on all mobile OSes.

Due to the un-sustainability of the App Store policies, the premium software that will keep people in the iOS ecosystem just won’t get built - that’s a recipe for disaster. Just look at the Panic 2014 report (and multitude other reports as well). It’s precisely those developers that have built the ecosystem, have been innovating and creating superb 3rd party software and have been advocating Apple products for decades. And now Apple have turned their backs on them.

Update (2015-01-08): Wil Shipley has some suggestions for the App Store.

5 Comments

And now Apple have turned their backs on them.

Is there some evidence that Apple had a choice? I.E. that it could have created a store where prices would have been at some level that sustained the current developer model?

Is there some evidence that Apple had a choice? I.E. that it could have created a store where prices would have been at some level that sustained the current developer model?

Yes - a few of the things that could have been done that would encourage sustainable pricing:

- Trials: without trials, developers are forced to lower their prices so that customers would even try their software. This is completely non-sensical: why would we require upfront payment to just try an app out? The best way to judge apps is to try them yourself. The argument here has been: just make it free with IAP. Again, that's not a real alternative for many apps - you cannot sell the app piecemeal and chop it up. Most developers see it as deliberately crippling their apps, taking things away so that they can work around the lack of trials. Again, this makes no sense - people should be able to try the software before buying.

- Top Charts: Those encourage a race to the bottom because in order to make money at low prices, you need more units. How do you get more units? You need to be higher in the charts so that you're visible. How do you get more units? Lower price. Rinse and repeat and we arrive at $0.99 (for the Top Paid charts). I there was a 5ยข tier, I bet that's where we would be.

- Paid Upgrades: As I mentioned earlier, recurring revenue is required if you want your favourite apps to survive, there's no way around it. Paid upgrades are the most honest and straightforward way to do it.

When you combine the effect of the above, you end up representing software as cheap and disposable. This is unsustainable in the long term, as we're seeing right now - pretty much everyone I know is reporting steady revenue declines, with some very few exceptions. Wil Shipley mentioned: The App Store currently works only for the developers who hit it HUGE. Everyone else I know is going out of business. We need upgrade revenue.

I'd guess that the reason why we don't talk about those failures publicly is because they are masked by the huge churn of developers and hobbyists who have a go at the App Store and then give up when they see it's impossible build a business. So you have a constant flux of new apps which makes you think everything is fine and dandy but the reality might be very far from that.

>Is there some evidence that Apple had a choice?

Yes. They could let companies sell iOS apps outside of the App Store.

@Milen "The argument here has been: just make it free with IAP. Again, that's not a real alternative for many apps - you cannot sell the app piecemeal and chop it up. Most developers see it as deliberately crippling their apps, taking things away so that they can work around the lack of trials. Again, this makes no sense - people should be able to try the software before buying."

I would say you have 4 main types of trial:

- limited feature set
- limited time of trial
- limited feature set + limited time of trial
- full feature set that becomes limited after a specific amount of time

It could be possible to deal with all these cases via IAP. A IAP asset could be a full time asset and/or a full feature asset.

The problem I guess is that with the time asset, this would mean that the app would stop working (*) after a certain period of time following the first launch after the app has been installed (**). And so Apple would probably reject the solution on the basis that an app doing this does not follow a f***ing Guideline rule.

* more probably display an alert to tell the user to purchase the IAP asset.

** of course, if you remove the app and then reinstall it, the trial period would reset. But this is basically what you can already do on a desktop system (e.g. Transmit, SubEthaEdit, etc.) by removing the appropriate file.

*** Not a foot note: it's just that the word has been redacted.

@Stephane

Before I start, I'm assuming that for a trial to be of actual use, you need to be able to try the full feature set - otherwise you cannot determine whether the feature you actually would fulfil your requirements.

This leaves us with one viable option: full feature set + limited time. This is impossible to be implemented on iOS right now, because of the following reasons:

1) An app cannot stop working after a certain period of time, as per the App Store Guidelines (as you point out).

2) Even if it did, as you say, the user can just delete the app and re-install - normal users are familiar and know how to do that. But the same is not true for the Mac as there are some crucial differences. On iOS, when you delete the app, it also deletes the prefs file and all the associated local storage. On the other hand, if you just bin the .app on the Mac, the pref files stay and if you re-install the app, you will not bypass the trial. Notice the difference: on iOS it will be trivial and easy to circumvent, on the Mac a bit harder. Obviously, if anyone is determined to circumvent it, they can do it on both platforms - every scheme is defeatable, the only question is how much effort it takes (and power users on Mac do know how to trash the prefs but there are still a few other ways, all of them defeatable, too). Actually, Apple can just implement time limitation as part of the OS and then it's practically impossible for normal users to circumvent without jailbreaking.

So, again, we come to the conclusion that a real trial is not possible within the current framework, assuming we want the user to be able to try out the full feature set (which, as far as I am concerned, is a requirement as I want my customers to know exactly what they're getting before buying).

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment