A few days ago I noticed that one my favourite iOS apps, Day One, had recently been renamed to “Day One Classic”. I didn’t think much of this at the time but eventually I realised why this had happened: the current version of the app was being mothballed in favour of a shiny new 2.0 version which would be released as a brand new SKU.
I don’t mind paying a premium for apps. In fact, I reckon I’ve paid for hundreds of apps since I got my first iOS device in 2008. Therefore, I figured I’d pay for this latest update if it looked like it was worth it. I currently use Day One Classic as a personal journal and have done on-and-off for a few years now. To be honest, the current version of Day One Classic ticks all the boxes for me and off the top of my head I couldn’t think of any shiny new features that might tempt me to try the new version at this stage. At first glance the UI of the new Day One 2.0 seems more or less the same although it actually has less syncing options than the former version.
Day One is developed by Bloom Built who explain their reasons for charging for the new update on their website:
Day One 2.0 is the result of over two years of design and development. Paying for Day One 2.0 means that we’ll be able to continue to maintain and develop the Day One apps.
As an app developer myself, I can relate to the amount of work that will have gone into this latest version of the product. Bloom Built themselves have stated that this version is a complete rewrite from the ground up of their codebase and that the paid upgrade is a investment in this and the product’s continued development.
These reviews from the UK App Store cast some light on the public reaction so far:
… what drives me berserk is that for what amounts to relatively minor incremental improvements we have been forced to pay for everything again.
… When companies randomly charge you for quite expensive upgrades it really does change my views on openness and transparency. Unhappy about the price hike.
… I’ve been using Day One for years and don’t begrudge the upgrade price in general - it’s a great app - but little has changed to justify the 2.0 moniker.
I think on some levels the public reaction - whether justified or not - contributes to me thinking that customers are most concerned with the product that they see before them right now. To them, this is the app that they see: not the technology behind it nor the promise of what the product might be in the future. The code behind this product may be beautiful, elegant and maintainable and the product may one day have some amazing new features. However, ultimately the end-user only sees the pixels on the screen and those may not be vastly different to the previous version at this stage in the product’s lifecycle.
One of the risks of charging a fixed-price for an app as Bloom Built have chosen to do with Day One is that you effectively cut off your potential for earning a recurring revenue: once a user has paid their fee there is no easy way of earning further revenue from them as they may feel they have already paid their due. As the developer of an app you will need to be careful that you choose your price point carefully as you only get one shot at this per-user unless you decide to adopt a different payment model such as in-app-purchases (IAPs) or subscriptions further down the line. If you do decide to charge a one-off fee and your product has a long lifecycle there may come a point when you feel that the original users of your product have had their money’s worth and that you are justified in seeking additional revenue. This leaves you in a bit of conundrum because your choices are now limited.
These are the main choices:
- Add some in-app-purchases to your existing product. This may potentially coincide with making the app the app free to lower the barrier to entry.
- Alternatively, ship a new update of the app as separate SKU. This is the option that Bloom Built chose with Day One 2.0.
- Less mainstream models such as Overcast’s Patronage model.
Either way this can be a tricky decision to make. On the one hand, there’s a certain sense of entitlement as an end-user of an app that you have already paid for. I’m certainly not immune to this feeling myself! If you choose the first option and integrate IAPs into your product you can end up alienating your existing users who feel that they shouldn’t have to pay to receive additional functionality because they have already paid an up-front fee. This feeling can be exacerbated if the app is also now given away for free as a way of lowering the barrier to entry. I have experienced this myself with Way Of Life which at some point went from a paid app to a free app supported with IAPs.
We’ve also seen the potential risks of the second option, as is the case with Day One 2.0. It is a shame that there isn’t currently a way to do paid upgrade paths within the same app. This could work by keeping the same SKU but allowing the developers to specify a required payment to receive upgrades to the application past a certain version. This would be a similar mechanism to releasing a new SKU but without the hassle of migrating all your users. It also potentially solves the problem of communicating this change: had I not noticed the name change and an App Store feature of the new version of Day One by Apple I might not have noticed that I was no longer receiving updates at all.
Unfortunately, the paid-upgrade path is not currently supported. However, recently Tim Schiller has taken over the operation of the App Store business so perhaps changes might be in the pipeline. The App Store certainly needs some love.
As for me: I’ve decided I’ll upgrade to Day One 2.0 when they release version 2.1 which will feature end-to-end encryption, as this something that is important to me personally. Ultimately, whether or not to upgrade is a choice, not an obligation, and as end-users we are not entitled to receive unlimited upgrades to a product we’ve paid for once.
On the other side of the coin, as developers, we face interesting challenges. How do we fairly charge for new major new versions of the same product with a single up-front fee without alienating our existing users? Perhaps a more important question is whether or not the single up-front payment is still relevant in 2016.
Either way, I watch this problem area with keen interest and look forward to Day One 2.1!