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.”
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.
Unless you want your app on iOS at all. Or unless you want your app to work out of the box on any user's machine without scary security warnings.
Please. The wheretos and the whyfors of the negatives of Apple's particular flavor of walled garden have been discussed ad nauseum. You know damn well the problem here isn't that they don't have an upgrade pricing option, the problem is that they came down like a ton of bricks on someone for sidestepping the problem.
That very much is abusive, and "blah blah you have a choice" does not absolve Apple of criticism of this weak policy.
As long as you've built and signed your app with your dev cert gatekeeper will open it with no scary warning -- no? That's always been my experience at least
Assuming that the OS is set to permit developer-signed apps. That's the default for now. If the Mac moves further in the direction of iOS, it might not stay that way.
It's hyperbole sure. But the fact is that Apple's refusal to add upgrade pricing goes directly against Omni's entire raison d'être. They release exquisitely detailed and full-featured apps, and they've been doing so longer than any OS X developer since their roots are back in NeXT.
The current App Store pricing devalues software, it turns it into a disposable commodity to be purchased and discarded. Apple is willing to sacrifice it's own pro apps to this devalued future because that's not where it makes its money anyway and it has some major scar tissue from being held hostage by the likes of Microsoft and Adobe.
You can say it's just another distribution channel, but it's obvious that the App Store is the future, and is by far the most convenient and recommended channel and that will only increase over time. Comparing it to something that is easily provided by third-parties like analytics is to miss the fundamental connection: Omni makes the type of software that App Store pricing makes impossible to create and maintain over time. If this continues the ecosystem will dry up, and the type of pro users who love Omni's stuff will all disappear as well. It's a bitter pill to swallow because they love Apple's tech, but the writing may be on the wall.
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.
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.
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.
This is just FUD. It's clear why sandboxing is required for the MAS - so that users can expect iOS like safety from the apps. It's also clear why MAS is required for iCloud - because otherwise anonymous developers would be able to arbitrarily abuse the storage service.
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.
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.
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.
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.
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?
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).
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.
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.
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).
28 comments
[ 2.9 ms ] story [ 80.4 ms ] threadOmniGroup 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.”
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.
Please. The wheretos and the whyfors of the negatives of Apple's particular flavor of walled garden have been discussed ad nauseum. You know damn well the problem here isn't that they don't have an upgrade pricing option, the problem is that they came down like a ton of bricks on someone for sidestepping the problem.
That very much is abusive, and "blah blah you have a choice" does not absolve Apple of criticism of this weak policy.
The current App Store pricing devalues software, it turns it into a disposable commodity to be purchased and discarded. Apple is willing to sacrifice it's own pro apps to this devalued future because that's not where it makes its money anyway and it has some major scar tissue from being held hostage by the likes of Microsoft and Adobe.
You can say it's just another distribution channel, but it's obvious that the App Store is the future, and is by far the most convenient and recommended channel and that will only increase over time. Comparing it to something that is easily provided by third-parties like analytics is to miss the fundamental connection: Omni makes the type of software that App Store pricing makes impossible to create and maintain over time. If this continues the ecosystem will dry up, and the type of pro users who love Omni's stuff will all disappear as well. It's a bitter pill to swallow because they love Apple's tech, but the writing may be on the wall.
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.
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.
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.
There is no slippery slope here.
> 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.
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.
Also, just because more sales are done direct than via the MAS today, Omni may not expect it'll always be that way.
Is it because a new version requires a totally new/different binary ?
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.
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.
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?
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).
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).