
Is It Time For Apple To Update App Store Pricing Rules? - yapcguy
http://www.fastcolabs.com/3017187/open-company/is-it-time-for-apple-to-update-app-store-pricing-rules
======
yapcguy
Ken Case is a nice guy, always polite whenever you speak to him. However,
someone should do him a favor and tell him that after 5 years of Apple
ignoring him, it's obvious he's in an abusive relationship and needs to get
out.

OmniGroup was successful before the App Store, and based on the quality of
their software, will remain so even if they quit the App Store.

 _> “Apple is certainly aware of our desire for upgrade pricing,” Case tells
me. “It's something I've been asking for since before the launch of the
original App Store in 2008. ... “Our relationship with Apple has always been
great--and this certainly doesn't change that,” he says. “I don't think
they're trying to work against our interests; they just have to decide where
to focus their efforts, and our priorities are not always their priorities.”_

~~~
passerinelabs
How do you go from Apple not including a feature in the MAS (in this case,
upgrade pricing) to "abusive relationship?" I and every other small Apple
developer would really love some analytics capabilities in the app store, but
we don't go around calling its absence "abusive" on Apple's part.

The MAS is just another sales channel and Apple doesn't force you to use it.
It's not incumbent on them to add features just because some people want them.

~~~
yapcguy
Yes, I'm being a little dramatic, but...

Apple does "force" you to use the MAS. You can't use the iCloud APIs unless
your app is sold in the MAS which means you also have to accept sandboxing.
Who knows what else will be tied to the MAS in the future.

The situation is farcical because developers are paying Apple 30% of their
gross revenue for the privilege of a sales channel with no customer
information and the spectacle of begging for things like upgrade pricing and
analytics.

~~~
passerinelabs
I actually really like the idea of sandboxing and entitlements for Mac apps.
It's appropriate for like 90% of all the apps I run and I'll happily click
through a scary warning for the things I don't think ought to run in a
sandbox.

For some developers the MAS is a really nice alternative to direct
distribution. You don't have to setup a merchant account and deal with all
that. Your apps are automatically searchable (if not really discoverable). You
have a built-in review/rating system to establish credibility pretty quickly
(which absolutely impacts sales). It's not a horrible system, and again, Apple
doesn't force you to use it... unless you want to use iCloud, but then again
there's nothing stopping you from doing your own cloud sync solution as Omni
has done.

~~~
yapcguy
Sure, but the rules are completely arbitrary.

What if they suddenly say only apps distributed in the MAS can use AirDrop,
CoreData, CoreAnimation, etc.?

It's not as if they will bother telling developers beforehand.

Go look at the Apple developer forums today, under the iOS 7 beta section,
people only found out that the iOS App Store allows older versions of apps to
be downloaded because 9To5Mac found out about it and published a blog post. No
official guidance (as yet) has been given to developers.

------
josephlord
I think with iOS 7 and Mavericks it will be possible to do upgrade pricing
because of the new features in the receipts which critically include initial
purchase date. With that you can offer an in-app purchase to upgrade to the
new version features to customers who bought before a certain date and provide
them automatically to those who bought after the date.

Note that I have not tested this or even studied the API in detail as I have
no need for it at the moment.

It isn't without downsides though as you need to have both (or more) modes
running inside the same app and test them to ensure that they all continue
working.

~~~
fpgeek
You're missing the point. It's not about what is technically feasible. Omni
Group didn't have technical issues implementing their upgrade solution and it
contradicted no policy that they were aware of at the time.

Nevertheless, Apple decided that they didn't like it and shut them down. They
might do the exact same thing to an app that simulated upgrades via in-app
purchases. Developers have been asking for upgrade pricing for years and
gotten nothing. In many cases, Apple has even stopped offering upgrades for
their own apps.

Given the development effort required, would you bet on Apple allowing your
upgrade solution through?

~~~
josephlord
Yes actually if I needed to do upgrade pricing. The solution from Omni
involved enabling/encouraging purchase of digital goods outside the App Store
which is one of Apple's brightest red lines in their App Store rules. The
solution that I propose is completely within the App Store system and Apple
still get their 30%.

If I was planning to use the approach I would reread their guidelines first
with the specific plan in mind to check there was nothing preventing it but I
wouldn't expect to find it (if you do know of a specific clause please let me
know).

~~~
fpgeek
Given that Omni would love to offer upgrade pricing on Apple's App Store, I
don't think outside it or the 30% were the barrier. In fact, I'd be more than
a bit surprised if Omni hadn't suggested the alternatives like OmniKeyMaster
as a paid app.

~~~
josephlord
It still sent users outside the store to get the content which I guess is
frowned up (I can't be bothered to look at the MAS guidelines). As I said the
feature required yet isn't available until Mavericks is released.

------
aleem
As Ken himself notes in the article, it worked for "retail boxes" but that
model is now obsolete.

Upgrade pricing will almost always lead to an abusive relationship where the
consumer is on the receiving end. Rate-limiting features, bumping major
version numbers, setting targets for bi-annual release cycles, abandonment
issues of old versions, creative versioning schemes, complex upgrade paths--it
all sucks for consumers. All internal conversations around features and
releases will also involve revenue assessment, putting business first,
consumers second.

In-app purchases may require some re-architecting but in the end it's a better
fit. All consumers should have the latest core so they get security upgrades
through the life of an app and can buy any features al-a-carte that are
carried forward.

The skeptics should note that web-apps already work this way and it's a lovely
model. You don't need to pay extra to load version 2.0 of a website. If it
worked that way, it would suck for everyone, even more so when the underlying
technology is changing fast (HTML, CSS, browsers, etc).

------
chrislipa
I feel like a developer could hack this pretty easily by enabling upgrade
features through In-App Purchases.

~~~
ap3
My thoughts too, can someone explain why IAP don't solve the upgrade problem ?

Is it because a new version requires a totally new/different binary ?

------
zem
i cannot even begin to fathom the thinking behind this:

> Case could have continued to support OmniKeyMaster against Apple’s wishes
> and accepted the removal of Omni’s apps from the Mac App Store. After all,
> though he admits that Omni’s apps do very well in the Mac App Store, most of
> Omni’s customers still buy directly through their own online store. Instead
> he says he pulled OmniKeyMaster because he and Omni Group have a long
> history with Apple and he respects their relationship.

~~~
objclxt
Omni probably gets quite a bit of 'preferential treatment' from developer
relations than the normal, average developer.

In the case of Apple, this probably includes dev relations actually
_answering_ their e-mails, getting advance access to new features _before_
they're announced (Apple sometimes likes to get third party devs to showcase
their apps at their keynotes), and being able to obtain WWDC tickets without
having to go through the usual stampede.

I can understand why they wouldn't want to risk that by pulling all their apps
from the App Store, and thus annoying Apple. Not saying it's right, just that
I can understand.

------
clarky07
It seems like IAP solves this problem. It might be a bit of a hack, but it
would work. Not sure what the big deal is.

~~~
peterkelly
It provides a partial solution. As a developer, you can issue a new update
which has the new features introduced, and offer an in-app purchase to unlock
those. However it it means you have to continue to maintain the "old" version
of the app (i.e. the app without the new features enabled). For one version
this isn't too much of a problem, but by the time you've released three or
four major version upgrades over a period of 6 years, you've got quite a few
code paths to test.

It also only really works if the things the new version introduces are
features that can be easily isolated from the rest of the app. If a developer
were to do a major rewrite of a core part of the app (e.g. a rewrite of core
functionality which improves performance/usability) then IAP isn't a viable
option. So it's a significant inconvenience.

The other option of course is a subscription model, which is the direction a
lot of large developers (Adobe, Microsoft) are heading in. If the developer
has an ongoing source of revenue from subscriptions, then that could cover the
costs of developing new versions. However not all users want to be forced into
a subscription, particularly for a high-end productivity tool that they are
buying to use over a period of many years.

