Pricing Philosophy

Our first app was developed in 2008 and was in the initial 20,000 apps released for the app store. In that time, the store has changed a lot. Since day one, we have charged for our apps, and generally not at rock-bottom prices. An early review complained that “we were better than all other apps in the category… but priced higher”. Well yes, that’s kind of the point.

The store these days has a lot of subscriptions, and I’ve seen multiple cases of apps, both free and paid, move to this model. We don’t sell subscriptions for any of our apps, and if we ever introduce one it would only be for something that has a reoccuring value-add (think backend server functionality, or data updates).

I personally use very few subscription app services. Ones I’m happy with have an exceptiional track record of updates and functionality beyond simply keeping the app running. While it is definitely work to keep apps going—APIs change every year—it just doesn’t seem user-friendly to charge the price of Netflix to access the core functionality of an app, especially ones that are largly static (no backend, no major data updates).

The best example of an app subscription done right is Slopes. It has backend functionality, and provides continual data updates, and clearly has a lot of active development. You buy a season pass to use it that season. Contrasting that, if an app does 1 thing really well, but doesn’t require continued updates outside of maintaining the pace with iOS, then I don’t really want to pay monthly. While few adopt the alternative model of having numbered paid versions for new releases, it is probably the better way to go in order to fund development.

For our apps, the updates to keep pace with iOS are on us. We use our own apps, so we need these changes anyway. The one service where a subscription makes sense would be Geospike. After all, we have to run a server to store all the data which is a continuous expense (and provides continual value). We might get around to adding that one day.