Tag Archive for appstore

Pricing: We’re Doing It Wrong

Like many of you I am an independant software developer and have found some success leveraging the App Store. Many developers, myself included, have bought into the low price / high volume business model and we’ve had some mixed results…. I’ve been considering the pricing issue for a while and have come to an odd, but by no means original, conclusion: we are all underpricing ourselves. Please note before you read this that I am excluding games from the equation here

This might sound strange given the rise of freemium software and the general wisdom that cheaper software sells in higher volumes. However, it doesn’t seem to hold up.  Taking a fast look at the current top ten grossing paid applications on the Mac App Store, the average price of an app is $75 and the most commonly appearing figure is $20. Now before you get too excited about that $75 figure keep in mind that the average is shot up by a few apps at $200 or more. Also, keep in mind that I am using the ‘top grossing’ for my metrics rather than ‘top paid’; I’m using ‘top grossing’ because it isn’t clear what it means to be a ‘top paid’ app but an app’s gross revenue is an accepted metric I can use to judge its commercial success.  A few other things I’ve noticed from looking at the top grossers: none of them is $0.99, none of them is $1.99, none of them is even $4.99, and the lowest priced apps are $20.

To be honest, I don’t know what price points we should all be hitting, but anything below $4.99 for desktop software seems like far too low; in truth, I am starting to feel like the $4.99 price point is even a bit too low given how much work we put in our products. All I know is that we (software developers) need to end this race to the bottom on price.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Effects of App Store Distribution pt1

Those of you who follow me here or on Coder Radio or on any of the social networks that I frequent will know that I have been running a little experiment with my new Mac Application Code Journal; for those of you who randomly got here via a search or something like that, the experiment was trying to sell a consumer target Mac OS X application outside of the Mac App Store. No need to go into too much detail, since if you want more info you can go check out episode ten of Coder Radio, but the experiment did yield a result and a lot of feedback. Basically, there is ample evidence to support the idea that, in general, apps that target OS X will do better on the App Store than via direct sales.

As with the mobile space, I believe that increased reliance on app stores will have some considerable effects on the business of app development, the developers, and the apps themselves. So I am writing this three part series to discuss those issues and am taking something of novel approach (novel to me at least): I am going to look at this issues by comparing two very different apps Mars Edit, and my own Code Journal. I picked Mars Edit as a point of comparison because it is established and is in a different space than Code Journal, so there isn’t any risk of bias. Additionally, in many ways Mars Edit can be seen to represent the traditional Mac application model while Code Journal more closely resembles the single purpose “app ideal”.

The eight hundred pound gorilla in the room is app pricing. In general it is becoming increasingly hard to sell an app for more than a few dollars; some would argue that even getting the few dollars at all is really hard. Of course, there are exceptions to this, but those tend to be from either large game companies (think EA, Activision, etc) or from established Mac developers. An example of the latter would Daniel Jalkut’s Mars Edit, an app that is currently selling for $39.99 on the Mac App Store. Mars Edit’s success is a great story but also very atypical of pricing for productivity apps in the store and a lot of that may be due to Jalkut’s and the app’s cache’ in the Mac developer / enthusiast community; again for those who don’t know Jalkut was a former Apple engineer and has been fairly active in the community. Additionally, Mars Edit was successful long before Jalkut took it over; he actually bought the app from another developer in 2007.  A quick survey of competing apps in the same space on the store showed that most of Mars Edit’s competitors tend to be in the ten to fifteen dollar range and seem to have poorer placement in the store, which suggests weaker sales. One notable exception is the $39.99 MacJournal; Yes, there are of course other applications on the store that charge more, such as OmniGroup’s OmniPlan, but  we are looking at its competitors here.

What does this all mean? Honestly, Apple is the only who has the data to be able to truly say if the store if pushing prices down across the board. There certainly seems to be a correlation in applications being priced lower and the rise of the app store model, but there is an alternative argument (with an alternative villain) that could be made: free web apps may be forcing prices of native apps down by training consumers that a large class of applications should be free, such as Google Docs. Again, Apple is really the only who can disprove or prove the first point for sure and the web app debate is something for another day.

Check back soon for a look at what the App Store seems to be doing to independent software developers.

If you have some feedback please find me on Google+ or Twitter. Also, if you like my posts or work on Coder Radio, please consider purchasing Code Journal either from the Mac App Store or direct.

A Look at Control and the Mac App Store

Much like they have in the mobile space, Apple is leading the charge to commoditize software from independent developers, making it more affordable and convenient for users to purchase and keep up to date. The signs seem to suggest that this has on the whole been a boon for most developers but it has also put an unprecedented amount of control in the hands of Apple regarding what apps Mac developers create and what functionality they can and (more importantly) cannot have. Given that control, Apple has chosen to enforce a few policies that are not in the best interest of Mac developers: they refuse to support paid upgrades for large scale apps, enforce a rather rigid and restricting form of sandboxing, prevent developers from using some of the platforms newest and most interesting APIs on apps that are not distributed via the Mac App Store.

Developing software is difficult, time-consuming, and expensive. Traditionally, developers of large applications have used upgrade pricing schemes to maintain recurring revenues as a way to fund future development of their apps; an extreme example of this would the Adobe suite of tools.  Apple currently does not allow developers to charge for updates. Think about that for a second. Users are going to, as they have been trained to for years, expect  their apps to be kept up to date and, in some cases, provide increased functionality as time goes on. However, the current App Store model forces developers to either betray users’ expectations or somehow finance perpetual development of their apps on whatever one time cost they manage to charge on initial purchase; it should also be noted that apps on the Mac App Store have a tendency to be relatively low cost. Some have suggested that developers could take advantage of the Mac App Store’s in app purchasing APIs to make up the lost revenue. In some cases this might be a serviceable option but falls short of being a full replacement for true update pricing. The issue here is that this limitation discourages the continued development of large scale software for the ecosystem.

Security hasn’t been much of an issue for OS X historically. Despite what Apple fans would tell you, that has nothing to do with any sort of enhanced or inherit security on OS X. The truth is that OS X did not have a sufficient install base to make it an attractive target for malware authors. As Apple has been ever so eager to share, Mac sales are growing rapidly when compared to the overall PC industry. In short, OS X is becoming an increasingly attractive target for malware authors. Apple has responded swiftly to these increased threats in what is probably the most excessive heavy-handed PC security policy to date: sandboxing. If you are reading this, I assume that you already know what sandboxing is, so I won’t bore you by reproducing the definition here. In theory, sandboxing is a good way to make an operating system more secure, but in practice, it is more a restrictive mess than anything else. Basically, sandboxing does not provide enough benefits to be worth the onerous restrictions that it imposes on apps’ functionality.

For us developers, APIs are our windows into the platforms we work on. We depend on those APIs being documented, stable, and consistently available. On those first two counts, Apple has done a tremendous job in recent years. However, with the introduction of Mountain Lion, Apple has restricted a number of its newer and more interesting APIs to applications that are sold on the Mac App Store; if you are interested in what APIs are restricted, there are a number of them, but on the whole, they tend to be the ones that have to do with iCloud or the Notification Center. This is something of a Catch 22 for developers, since users are going to increasingly expect apps to provide the functionality provided by these APIs but may not necessarily want to purchase their apps via the Mac App Store. Once again, we have a case of Apple’s policies forcing developers to run afoul of users’ expectations.

What does this all boil down to? Apple’s recent policies make OS X development a lot more complicated for developers who want to keep up with the operating systems newest APIs but also are unable to comply with the restrictions associated with sandboxing. My take is that if you are developing a powerful application for OS X, odds are that you are going to have sell outside of the Mac App Store, due to sandboxing,  and live in fear of Apple one day using GateKeeper to further restrict the distribution of non-App Store apps. For another take on this, have a look at popular iOS developer Marco Arment’s post on the issue.

I know I have made some pretty strong statements here but I stand by them. If you would like to debate me on these issues or have any other feedback, find me on Google+.