The Mac App Store Still Needs Paid Upgrades(dancounsell.com)
dancounsell.com
The Mac App Store Still Needs Paid Upgrades
http://dancounsell.com/articles/the-mac-app-store-still-needs-paid-upgrades
12 comments
It's a problem in the App Store too and it definitely discourages us from submitting updates when we otherwise would. It amazes me that they don't deal with a fairly small problem like this.
I know app bundles were introduced in the iOS App Store and some developers had started using them as a hack around "paid upgrades." Given that they didn't get a mention in the original post, I'm assuming they don't exist on the Mac App Store. Seems like an easy win that could solve half the problems mentioned...
(For the record: a user that has already purchased an app in a bundle only has to pay the difference to complete the bundle. So the idea is having version 1 and version 2, each for $30, but sell the bundle for $50. Owners of version 1 can essentially upgrade to version 2 for $20.)
(For the record: a user that has already purchased an app in a bundle only has to pay the difference to complete the bundle. So the idea is having version 1 and version 2, each for $30, but sell the bundle for $50. Owners of version 1 can essentially upgrade to version 2 for $20.)
IMHO, the Mac App Store is good for one thing, and one thing only: Apple's Mac apps.
Without trial versions / paid upgrades / all of the other things we've been asking for, it's just not a distribution system I would seriously consider using.
If I was building an OS X app, I would rather go out of my way to support auto-update, custom licensing, etc, than deal with the limitations of the Mac App Store.
Without trial versions / paid upgrades / all of the other things we've been asking for, it's just not a distribution system I would seriously consider using.
If I was building an OS X app, I would rather go out of my way to support auto-update, custom licensing, etc, than deal with the limitations of the Mac App Store.
And it's not all that bad.
* For updates, use Sparkle framework. [1]
* For licensing, use CocoaFob [2] or write your own.
* For payments, use FastSpring like most other indie shops. [3]
Only other detail is having to write a EULA yourself.
[1] http://sparkle-project.org/
[2] https://github.com/glebd/cocoafob
[3] http://fastspring.com/
* For updates, use Sparkle framework. [1]
* For licensing, use CocoaFob [2] or write your own.
* For payments, use FastSpring like most other indie shops. [3]
Only other detail is having to write a EULA yourself.
[1] http://sparkle-project.org/
[2] https://github.com/glebd/cocoafob
[3] http://fastspring.com/
It may not be “that bad”, but it’s still enough to be daunting if you’ve been in full-swing development mode and would rather focus on your application’s key features instead of licensing and distribution.
That said, I have apps on the Mac App Store and though it’s effortless, there are absolutely points of frustration. Most notably, there’s no way to refund or interact with unhappy users or users with questions. Additionally, OS X's sandboxing implementation is still buggy in some areas (mostly involving file dialogs and persistence of user-selected file URLs) which makes writing and usage of applications that frequently work with files in arbitrary user-selected files and folders in the user’s filesystem far more frustrating and failure-prone than it needs to be.
As such, I’m looking into moving into self-managed licensing, with a setup like you’ve mentioned (Sparkle/CocoaFob/etc) but rather than using Fastspring, I’ll probably use a personally maintained branch of Potion Store that supports Stripe instead. I’ve never been a fan of in-betweens like Fastspring as a developer or as a user; as a developer, I dislike the lack of control I have and as a user encounters with Fastspring and the likes feels janky, unpolished, and unprofessional.
That said, I have apps on the Mac App Store and though it’s effortless, there are absolutely points of frustration. Most notably, there’s no way to refund or interact with unhappy users or users with questions. Additionally, OS X's sandboxing implementation is still buggy in some areas (mostly involving file dialogs and persistence of user-selected file URLs) which makes writing and usage of applications that frequently work with files in arbitrary user-selected files and folders in the user’s filesystem far more frustrating and failure-prone than it needs to be.
As such, I’m looking into moving into self-managed licensing, with a setup like you’ve mentioned (Sparkle/CocoaFob/etc) but rather than using Fastspring, I’ll probably use a personally maintained branch of Potion Store that supports Stripe instead. I’ve never been a fan of in-betweens like Fastspring as a developer or as a user; as a developer, I dislike the lack of control I have and as a user encounters with Fastspring and the likes feels janky, unpolished, and unprofessional.
I'm with you on the sandboxing issues and lack of means to contact users.
FWIW, Fastspring is fairly customizable! The value over Stripe is that you don't have to deal with PCI details or worrying about fraud. Also, taxes/VAT in various jurisdictions. (Disclaimer: current customer)
One minor con is that until your store is "vetted" (something like a few months of successful transactions), your checkout form will include mailing address and phone number fields for additional fraud screening.
It's great to have more options of course. I figure I will "graduate" to Stripe if my operation gets to the point where I want even more control.
FWIW, Fastspring is fairly customizable! The value over Stripe is that you don't have to deal with PCI details or worrying about fraud. Also, taxes/VAT in various jurisdictions. (Disclaimer: current customer)
One minor con is that until your store is "vetted" (something like a few months of successful transactions), your checkout form will include mailing address and phone number fields for additional fraud screening.
It's great to have more options of course. I figure I will "graduate" to Stripe if my operation gets to the point where I want even more control.
> One minor con is that until your store is "vetted" (something like a few months of successful transactions), your checkout form will include mailing address and phone number fields for additional fraud screening.
The seller's phone? Or my customers must enter their phones?
The seller's phone? Or my customers must enter their phones?
For refunds you can redirect your users to https://reportaproblem.apple.com where they can request a refund pretty painlessly. Apple usually will issue an refund.
[deleted]
Someone in a podcast I listen to, perhaps Siracusa or Arment on ATP, distilled this perfectly. "There will be paid upgrades in the Mac app store when Apple needs it for their apps."
Even that may not be true. Apple things in the app store don't have to follow the app store rules that external developers have to (e.g. Xcode is not subject to sandboxing), so it's entirely possible that only Apple things could have paid upgrades.
Considering they seem to be moving towards giving everything away I wonder how likely this is....
Maybe more likely than you think. They are, as you say, making more things free (or, rather, "included"). I could see that moving toward giving you a free home version of Final Cut Pro, for example, and then offering a paid upgrade to the real deal with extra features and so on.
I would say it's extremely unlikely, software is a complimentary product to their hardware, it's in their interest to keep the price as low as possible.
Final Cut Pro costs $299.99. Logic costs $199.99. We've all read that Spolsky article, I get it, but that doesn't mean it is wise or inevitable for Apple to make all their software free. Offering limited versions of FCP and Logic for free gives users software that compliments their hardware, but also gives Apple another user in the ecosystem who might step up to the real thing because they're already comfortable with the workflow.
There are definitely limitations, but many developers are willing to trade those for access to an extremely high-profile app marketplace rather than hoping their apps will be found through other channels. Tech is only one piece of the 'successful app' puzzle.
I think most serious Mac developers simply don't use the MAS (notable exceptions being Fantastical and 1Password, but they offer the ability to purchase directly as well).
It also seems like few users browse there. Being in "Top 100 Paid" takes only 20-30 downloads, which underscores how low the traffic is. Source: personal experience.
It also seems like few users browse there. Being in "Top 100 Paid" takes only 20-30 downloads, which underscores how low the traffic is. Source: personal experience.
Omni Group still have 4 apps, priced at a total of $289 in the MAS.
What's the best way to see what the most popular Mac apps are, if Apple's official Top 100 may be based on few sales ?
Are there any sites tracking the best selling Mac apps ?
Are there any sites tracking the best selling Mac apps ?
Don't forget about Textual!
according to the textual dev, he's moving outside the mac app store "mid-to-late Summer 2015".
Certainly. This is far from the biggest problem though.
There are entire classes of applications that you can't find in the Mac App Store even when they're free (like web browsers!) so it's not just money that is keeping them away. Worse, apps that "add on" to popular products do make it in, creating this weird situation where you search for $POPULAR_THING and you don't find $POPULAR_THING but you do find all kinds of "99 cent plug-in for $POPULAR_THING" products. It really serves to clutter up and lower the perceived value of the entire store.
Apple should be treating this as the way to find and install Mac software, and lower every single wall if necessary until the likes of Mozilla, Google, Microsoft and Adobe are all on board with that.
If price is the issue, remind big developers that there are costs to running an app store but negotiate with them until they are willing. For the good of the platform.
If the sandbox is the sticking point (as it is perhaps for Firefox and Chrome), one option is to add an "Advanced Install" button so that all software can still be available on the App Store even if there is an extra hurdle. Apple could still set strict sandbox requirements for default installs. [The sandbox is one reason I didn't submit my terminal app because I cannot find any reasonable default sandbox that wouldn't utterly cripple shells and other common sub-processes.]
Licensing should certainly not be an issue. The fact is, there is a ton of really important free software on the Mac and some of it is GPL. Apple may not like this but they cannot deny that the value of their entire platform has grown because of such software. They should add an option to bundle or link source code with App Store entries. And if they really can't bring themselves to do that, the very least they should allow is an official entry for every piece of software, even if that entry is only allowed to link to an external web site for licensing reasons.
There are entire classes of applications that you can't find in the Mac App Store even when they're free (like web browsers!) so it's not just money that is keeping them away. Worse, apps that "add on" to popular products do make it in, creating this weird situation where you search for $POPULAR_THING and you don't find $POPULAR_THING but you do find all kinds of "99 cent plug-in for $POPULAR_THING" products. It really serves to clutter up and lower the perceived value of the entire store.
Apple should be treating this as the way to find and install Mac software, and lower every single wall if necessary until the likes of Mozilla, Google, Microsoft and Adobe are all on board with that.
If price is the issue, remind big developers that there are costs to running an app store but negotiate with them until they are willing. For the good of the platform.
If the sandbox is the sticking point (as it is perhaps for Firefox and Chrome), one option is to add an "Advanced Install" button so that all software can still be available on the App Store even if there is an extra hurdle. Apple could still set strict sandbox requirements for default installs. [The sandbox is one reason I didn't submit my terminal app because I cannot find any reasonable default sandbox that wouldn't utterly cripple shells and other common sub-processes.]
Licensing should certainly not be an issue. The fact is, there is a ton of really important free software on the Mac and some of it is GPL. Apple may not like this but they cannot deny that the value of their entire platform has grown because of such software. They should add an option to bundle or link source code with App Store entries. And if they really can't bring themselves to do that, the very least they should allow is an official entry for every piece of software, even if that entry is only allowed to link to an external web site for licensing reasons.
This sort of broke the software app business model. One low price for an app for life. Then doing the upgrades to each new version of OSX costs a lot of money. No wonder many companies go out of business or try to avoid developing for the Mac?
Adobe gets around this by offering Cloud subscriptions, paying a monthly or yearly fee to access the software.
Adobe gets around this by offering Cloud subscriptions, paying a monthly or yearly fee to access the software.
I have apps in the iOS and Mac App store, so this is a big sticking point form me. But there is one thing missing from the article, which is a discussion on why Apple wouldn't want to add a paid upgrade model to the App Store (iOS or Mac).
Some potential reasons:
Some potential reasons:
- confusing to casual users who aren't used to this model, and might not expect it
- more expensive (users at this point feel entitled to free or very cheap software)
- potential for abuse (random apps will start charging for every minor update)
About "confusing to casual users who aren't used to this model, and might not expect it":
If we tailor everything to the person with the lowest possible knowledge* , we get two things.
1. Everything around us will be a stupid as we can make it.
2. Eventually a person with even less knowledge will be found.
* I had a much stronger word there before...
* I had a much stronger word there before...
I don't work for Apple, but I think they would point a developer to in-app purchases (IAP) as 'the way' to do paid upgrades.
Still, auto-renewing IAP subscriptions are limited to a narrow class of applications (see AppStore review guidelines #11.15), forcing most to use churn-prone manually-renewing subscriptions. Outside payment systems are largely prohibited for digital goods under #11.13. The combination of these rules forces multi-platform subscription based apps (i.e. Autodesk's 123d-line of apps) to juggle multiple payment systems. Integration between those payment systems is often weak due to lack of a published web service or hook-system for IAP.
AppStore review guidelines can be found here: https://developer.apple.com/app-store/review/guidelines/#pur...
The state of in-app purchases leaves much to be desired.
Still, auto-renewing IAP subscriptions are limited to a narrow class of applications (see AppStore review guidelines #11.15), forcing most to use churn-prone manually-renewing subscriptions. Outside payment systems are largely prohibited for digital goods under #11.13. The combination of these rules forces multi-platform subscription based apps (i.e. Autodesk's 123d-line of apps) to juggle multiple payment systems. Integration between those payment systems is often weak due to lack of a published web service or hook-system for IAP.
AppStore review guidelines can be found here: https://developer.apple.com/app-store/review/guidelines/#pur...
The state of in-app purchases leaves much to be desired.
I think they are quietly loosening 11.15. It started as just magazines, now it has:
Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
On top of that, I know of at least 2 very high profile sports and health and fitness apps that are currently using auto-renewing subscriptions. Now, it's possible they get to do it BECAUSE they are high profile, but the precedent exists. They don't fit in any of the above categories.
Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
On top of that, I know of at least 2 very high profile sports and health and fitness apps that are currently using auto-renewing subscriptions. Now, it's possible they get to do it BECAUSE they are high profile, but the precedent exists. They don't fit in any of the above categories.
[deleted]
IAP doesn't work too well for trials. You have to label it a free app, and then users get angry that you're charging for features.
2.6 Apps that are "beta", "demo", "trial", or "test" versions will be rejected [1]
We released Calendar for MacOS (http://qbix.com/calendar) three years ago and now we are going to add a trial / upgrade mechanism, while distributing through the app store. It's totally done via non-renewing subscriptions for additional features.
As someone who has never done a paid upgrade because I started my life as an indie on iOS, could someone explain to me why it's better than a subscription? Are users just significantly more likely to buy an upgrade than to just subscribe?
I'm currently experimenting with subscriptions on iPhone and I think it at least has potential. To be fair, my conversions aren't where I'd like them to be yet, but I do think there is potential. Many of my competitors are also using subscriptions, and they seem to be doing pretty well.
EDIT: It also allows you to do trials, as long the free version is useful enough on it's own you can happily give out trials of all the premium features.
I'm currently experimenting with subscriptions on iPhone and I think it at least has potential. To be fair, my conversions aren't where I'd like them to be yet, but I do think there is potential. Many of my competitors are also using subscriptions, and they seem to be doing pretty well.
EDIT: It also allows you to do trials, as long the free version is useful enough on it's own you can happily give out trials of all the premium features.
I've had the understanding that subscription isn't an option for most types of apps. Auto-renewing subscriptions are only allowed for content or services. And non-renewing subscriptions are pretty narrow in scope as well. What type of subscriptions are you selling and for what type of features?
Here is Apple's guidance document: https://developer.apple.com/in-app-purchase/In-App-Purchase-...
Here is Apple's guidance document: https://developer.apple.com/in-app-purchase/In-App-Purchase-...
I'm using the non-renewing subscription, which I don't think is really as narrow as some of that guidance seems to suggest. I've seen them used in lots of different apps, in addition to the auto-renewing subscriptions I mention above.
Perhaps if Apple just actually changed those guidelines and made it explicit that this is ok more it would be a path to sustainability for more apps.
I feel like if more apps adopted this users might also become more comfortable with it.
Perhaps if Apple just actually changed those guidelines and made it explicit that this is ok more it would be a path to sustainability for more apps.
I feel like if more apps adopted this users might also become more comfortable with it.
So far I've seen developers do this, they just release it as a new app on the App Store and then you get to buy it all over again. If you don't feel like you need it you can stick to the old version you bought before until you have incentive enough to upgrade. They usually start out at a slightly lower "upgrade" price for the first month or two and then crank it up to the full price.
I realise it's really not the ideal situation but if you really need it for revenue it is possible. You can easily add a mechanism to the old version that nudges people about the upgrade.
I realise it's really not the ideal situation but if you really need it for revenue it is possible. You can easily add a mechanism to the old version that nudges people about the upgrade.
How about forgetting about the upgrade circus and make your app available only as a subscription at an annual subscription cost of 1/3 your intended full price? Then upgrades just happen.
The MAS actually penalizes you if you update an app which has a bunch of good reviews. Because after you publish a new update the average rating that is shown next to your app in the search results/category lists disappears until you get at least 5 new reviews for the current version.
Now this was introduced to the app store(s) because iOS developers bemoaned that they couldn't get rid of bad average ratings when they published a well-received update.
So Apple changed from displaying an average rating of all version to displaying just the average rating for the current version. With the requirement of at least 5 ratings to display any average at all.
On iOS this might work because the volume there is large. But on the Mac App Store it takes months for an average application (read: one that is not permanently featured by Apple) to acquire said 5 ratings.
So you think twice about pushing out an update to your app when the current average rating is 4 or 5 stars. Because once your average stars are gone, your app doesn't look very different from any other 0 rating app in the search results and it's pure luck if the user likes your icon enough to click on it. (Which measurably impacts sales numbers).
I see this with my own software: I currently have an app in the MAS which has an average rating of 4.5 stars and hasn't been updated since June 2014. Because I once made the mistake to update a well rated app and sales plummeted over the next few months until the app could re-acquire 5 ratings to show an average. So I'm not going to push an update of the app to the MAS anytime soon. And if a user complains I send them to the direct download version (which got several big updates during the last year). Yes, I feel bad about it but in the end I'm not going to shoot myself in the foot if I can help it.