I first published my app in September 2013. I am still iterating on the app, with 4.0.9 being my latest published version and 4.1.0 under development. With the benefit of time, things have become clearer and there are some things I wish I knew upfront (these are just a collection of thoughts, which I think an Android publisher should think about). (I only first published to the Apple App Store in December 2018, so have no real experience yet – this post is all about Android).
This is just a random list of thoughts on my experiences over the years – things I have done or some times things I wish I had done.
Old versions
In 2019, I’m still seeing app versions being used out in production which became obsolete in 2015 (2.1.1 was used on 6 January 2019 when 2.1.2 was published on 13 January 2015). It is really difficult to control app versions once they are published. Either have a strategy to force users to upgrade, or make sure that your app will stand the test of time. With the latter, I mean, don’t put in layers in your app which will break in 5 years time when you no longer maintain that service (for example, you deprecate a Firebase datastore or move to a different cloud provider). Version 1.0.0 of my app still works exactly the same as it did on the day I built it. And whilst that is pretty good, consider whether you would want to say that 5 years later when the whole world has moved on.
It is simply impossible to easily force upgrades, unless you force it in your app. While many upgrade fairly quickly, many don’t. It’s been over two weeks since I’ve launched version 4 of my app – yesterday’s stats show that at least 27.5% of my users still haven’t upgraded.
This might seem insignificant, but it becomes a big problem when you discover a breaking bug for example. Think carefully whenever you publish a new version of your app – it will be out there forever. I have done some “panic publishing” where it is just one fix on top of another to the point where the app is very stable. But, while the panic was underway, people installed the “bad versions” and never upgraded again.
Multiple app stores
This is probably easier now than it was in 2014. Back then, there were some viable alternatives to the Google Play store (to the point actually where a significant amount of my initial traffic was actually from a different app store). At some point, my app was on 6 or 7 different app stores. This might be slightly contributing to the number of older version of my app still circulating – over the years, app stores have changed named, sold on their inventories, closed down and I’ve found my app on app stores where I’m fairly sure I never published. Think very, very carefully if you are considering publishing to alternative app stores – is it really worth the effort? (At the time I thought it was, but it was a complete waste of time – if I were to do it again today, my Android app would only go on one, maybe two app stores).
Monetisation strategy
This is another one which has changed over the years. When I got started, most publishers who couldn’t sell a subscription service would monetise by having a free app and a “pro” version of the app. Thankfully, the problems introduced by having two app versions were not compounded by doing this on multiple app stores. I only followed the two app approach on the Google Play store.
I have had many people download the free version and I have good number of daily users. For my “pro” version (which is just a paid for version with the ads removed), the traffic is neglible. To the point where it would make absolutely no difference to my bottom line if I unpublished that app tomorrow. The problem with the “pro” version I have, is that people paid for the app out of loyalty, so I feel obligated to return that loyalty.
Having a free and paid for version also raises the question – do I launch new features to my paid customers first or to my free users? Usually, I end up using my free users as the guinea pigs to basically prove the app is stable first before rolling it out to my paying users, but is that really what they paid for?
Lately, I’ve been thinking more about paid for versions and how to monetise them better. I have come to the conclusion that in the app market, apps which are constantly being updated and improved, should not be sold, but subscribed to. A user who paid 0.79p in 2015 (to whom I am very thankful) are getting a really good deal 5 years later as they have a much better app and have paid very little for it. As a publisher, it feels slightly skewed that I could compete on price with another app, but it’s all about what we are delivering at that point with no promise of what is in the future. I want to look at moving to a subscription model – you sign up and pay for what you get at that point and if you are happy with what you get in the future, you can continue paying, otherwise you stop.
Crash reporting
Things really changed for me when I put in some crash reporting in my app. You can test all you want, but there are always the really strange devices out there or strange combinations of hardware and software. My app only started picking up when I put some crash reporting in place and I could see if users were experiencing issues.
User experience
There are many apps out there which simply seem like containers for ads and some incidental content. This is not sustainable in any way shape or form. I have seen these apps come and go – they might have made more income in the week or two they were on the app store than I did, but 5 years later, my app is still around and getting great reviews. Don’t fall into the trap. Design an app with really good user experience in mind and then add in the monetisation you want, but don’t let it distract from good user experience. You might not get the high RPM’s from having inobtrusive ads, but you will get loads more traffic if you have a good app, which will pay off in the long run.
Your users do not download your app for the ads – it is not a feature for them, don’t let your app just become a billboard.
Keep things up to date
I went through times where I neglected my app for long periods of time. Making even the smallest change would be such a headache because I would have to upgrade all my libraries and then everything would break. If I just kept up to date and upgraded as I went, it would not be so daunting. When GDPR came around, I had to spend a significant amount of time trying to upgrade libraries and see what would break where. I am going to try to at least do that this year!
Listen to your users
Read every single word your users write to you. Users who take the time to write feedback, whether good or bad are helping you out. By listening to their feedback, you could be making the experience better for others in future. One user’s feedback acted on could mean 500 fewer uninstalls next month. Don’t ignore your users – you created the app for them after all.