This was just a quick update to fix the reordering of favourites issue which may have occurred. It should all be fixed now.
• Bug fix: reordering favourites would not save on all devices – this has now been resolved 💾 • Additional functionality: added in the option to reset the database in case anything breaks and it needs to be reset (this may need to be done if route functionality breaks – a long term solution will follow soon) 🗑️
The other feature added is one to reset the database in case things go wrong. This can be found right at the bottom of the list in the settings menu (tapping it doesn’t give much feedback at the moment, but it definitely is doing something).
If you notice that you cannot access bus route information any more or if you favourite stops have turned into numbers in the settings screen, tapping this should resolve it.
I’m working on making sure the app looks after itself!
There are two inaccuracies in my title: firstly, Flutter is Android native, but we will be talking about developing Android native apps using Java versus Flutter app in Dart; and secondly, one isn’t really better than the other, but in my circumstances, one approach was definitely better than the other.
A brief introduction
The important information about my background which you should know:
I published an app in 2013 and I think it has been moderately successful. Not a Candy Crush, but it hasn’t died yet and people are using it daily.
I rebuilt this app and it has feature parity with the old one – it does exactly the same thing the old one did (I know, because I’ve had users point out to me where I have forgotten how the “old” app worked). From their point of view, it just seems like I updated the look and feel a bit.
Development is a hobby rather than a job (although I work with development teams, but not as a developer). Java and Dart were both self-taught and never used in a professional environment for me. (I learned C++ at uni and have a long history with languages like BASIC, Pascal, C and Visual Basic).
So my qualification to make these statements come from building the same production app in both Java and Dart with limited experience. Let’s dive right into some comparisons:
Java vs Dart
Both languages are very similar and I feel fairly comfortable using both. I was a bit hesitant with learning Dart, but it felt completely natural after being quite used to Java (I’ve dabbled a bit with Python and PHP and I found it much easier to quickly adapt into Dart comparatively).
Doing asynchronous work in Java is a bit more of a hassle compared to Dart. Dart’s syntax makes it very easy (except that in Flutter, you build methods cannot use the asynchronous syntax).
I also got into Dart and Flutter when Dart 2.0 was out, so the language was cleaned up for Flutter, so no annoying “new”‘s everywhere.
And then, Dart either seems to handle nulls a bit better or I have burned myself enough in Java to be handling it better myself. But it feels like Flutter protects you a little bit as you don’t have a mini-explosion every time you forget to handle a null.
The only negative point for Dart, but this more a Flutter thing, is that you end up with lots of brackets everywhere – more than usual. And maybe quite a lot of commas too.
As a language, I prefer Dart as it is a bit more to the point and feels like it is made for what I want to do.
Material design
I spent a good number of weekends implementing material design at the start of 2015. It had only been announced in June the previous year, so it was still relatively new and there wasn’t too much help available in terms of libraries. I remember having to style everything by hand, measuring margins and constantly referencing the material design specs.
Flutter basically gives you material design out of the box. I actually hadn’t realised how “not material design” my app was until I rebuilt it using Flutter. (Of course, I don’t know if you now get some better help in Android native, but it felt really good that the design system I wanted to use was immediately available to me rather than having to sit and figure out margins, padding, shadows, rounding and so on, on my own.)
Getting a material design look in Flutter was effortless compared to doing the same thing in Java.
XML vs code
When you work with Java, a lot of layouts, strings and random values will reside in XML instead of code. This should make scaling with large teams easier as there is a separation of concerns and a designer can pick up the XML files and edit them without having to know code. As nice as this is, I don’t like it for a smaller project. And then, you end up having to reference the XML in code any way, and you always wonder why you can’t just do it all in code (maybe you can?). It felt like things got messy having to work in XML and then use LayoutInflater to build the things I just build in XML to start with.
On the flip-side, I miss one thing: Strings.xml. This allows for easy translation and just having everything nicely in one place. I have seen a way to do it in Flutter, but it didn’t immediately make sense to me. I never actually translated my app, so it’s probably over-engineered, but equally don’t feel too happy with the strings just sitting all over the place. (I should probably at least just create a static class to put all my strings in…but that’s for another day).
Because I definitely prefer being able to have complete control over my layouts, I prefer the Flutter approach where it is all in code. The XML approach would have been more useful for WYSIWYG editors, but they never worked too well for me and I didn’t feel completely in control. And the fact that it would try and display even the smallest layout in the editor. It was just odd.
Hot reload
The lack of WYSIWYG layout editor in Flutter is made up for by having hot reload. It can do some strange things at times (or in my app if I change things which are done right at start-up, hot reload doesn’t work), but it is great for making layout changes and being able to see it immediately. This is not available when using Java and slows down the process a bit.
Fragments vs widgets
I’m calling out fragments here, but it really should be, “Widgets vs the Android kitchen sink”. Everything in Flutter is a widget – this makes it very predictable on how it will work and easy to move around and plug in somewhere else. It took me minutes to take my existing layout for phones and adapt it for tablets where I wanted side-by-side views of two different screens.
Adapting my app for tablets in Java was a complete nightmare. Again, things might have changed, but I had to use fragments. I had two fragments and it just felt awkward trying to deal with it differently between tablets and mobiles. Because everything is a widget in Flutter – this sort of thing is quite straight-forward to achieve.
This is the layout I tried to achieve on tablets with content on the left and a map on the right
It’s worth pointing out, that even after all of that work with fragments, the app stopped working on tablets at some point and I just never had the courage to want to try and fix it again. Until Flutter came along…
Flavours
I have three different flavours in both my set ups. The Flutter one would not have been as straight-forward to set up since I had to go and muck around in the Android code – but since I have done it before, it was pretty much copy and paste. If I was new to this, I can imagine it would have been pretty difficult to figure out as you have to change files you don’t normally deal with.
One of my flavours has a different applicationId which I can use in Flutter code to distinguish, but two of them don’t and I cannot easily and without some workarounds detect in code which flavour is which.
I would prefer it if there was an easier way to deal with flavours in Flutter, but it barely handles it at the moment.
Dependencies
For both Java and Dart, dependency management is quite straight-forward. Dart feels a little bit more light-weight and straight-forward – I have many more dependencies in my Java app for Android support libraries which I didn’t need in Dart (due to Flutter).
Due to not having to worry about the support libraries I prefer Flutter for dependency management, but I’m sure this might be why the APK’s are so big.
APK sizes
This was almost a deal breaker for me, and even though the production APK’s are quite a bit smaller than the debug ones, this is Flutter’s worst point for me by far.
The Java APK is 4.07MB and the Flutter one is 10.03MB.
Due to the large initial size of the Flutter APK (I started somewhere around 18MB), I had to be aggressive in terms of making images as small as possible, reducing the size of my static data database and be very careful with dependencies. Both APK’s are Proguarded/Minified. My Flutter APK is only that small due to a dedicated effort to try and get it as small as possible. If I put the same effort into the Java one, I’m sure I would get it to be a bit smaller.
Android Studio vs VS Code
I moved from Eclipse to Android Studio and liked it in the beginning, but it was quite heavy on the processing side. I’ve killed a laptop battery due to it and I’m fairly sure the heat Android Studio has generated in the past might have fried a few laptop components too. I now use a desktop, but Android Studio is still quite heavy-weight and it just feels too clunky.
Even though I use Android Studio from time to time due to wanting to use the layout inspector as an example, I prefer spending my time in VS code.
Maturity
We have to touch on maturity here. Because Java Android has been around for years, you have access to tons of libraries and many resources. Getting stuck shouldn’t happen for long and you’ll be helped quite quickly. All the libraries have had years to stabilise and shouldn’t give you problems (well, you’d think so at least).
On the other hand, Flutter is still fairly new. I’ve had specific issues with libraries crashing my app because despite claiming to be version 1.1+, version 1 just meant it was their first publication. I’ve also had issues with libraries being incomplete. It’s worth pointing out that in both cases, I found suitable solid alternatives, so I haven’t been left with nothing.
This is probably set to get worse for now as many libraries are still experimental or beta. As these libraries are upgraded, I’m probably going to have to rewrite large chunks of code. (Although, my Java code is probably in that situation now as I haven’t upgraded libraries for about 6 months).
Wearables
Neither app had a wearable version, but it was an option for me when I was working in Java. Flutter doesn’t support this yet, so if I had any plans to also have a wearable version, it isn’t currently possible.
I’ll mention it here only because it is also in the category of I don’t have it, but had the option and lost it – widgets. I believe that Flutter doesn’t yet support home screen widgets on Android, but this I cannot confirm.
Flutter’s best feature for me
So I’ve saved the best for last – Flutter gives me something I’ve wanted since 2013, but due to many issues, like time constraints, willingness and ability to learn, having to work on a Mac, I just never could build an iOS app. Flutter gave me this for free. Of course I had to set up a Mac in order to test it, but it just worked – pretty much out of the box with no code changes whatsoever (working is of course different to being usable – I’ve done a post on Flutter on iOS for Android developers about my lessons I’ve learned).
I’ve broken into a whole new market due to Flutter, so this is for me, the main reason that Flutter is better than using Java Android.
Summary
This is all my opinion based on my own use case, but hopefully you can find some useful bits in here if you are deciding whether to use Java for Android for Dart for Flutter. The checkboxes simply point out which is better at supporting the feature than the other – in most cases features are supported in both.
Feature
Android
Dart & Flutter
Language – both languages are very similar, but Dart makes asynchronous development a bit easier and handles nulls better
Java
Dart
Material design – I had to hand-craft material design when I worked in Java, it came out of the box with Flutter
✅
XML strings – having Strings all in one place and an easy way to translate them was useful in Java. It’s possible in Dart and Flutter, but not without some hand-crafting.
✅
XML layouts – I disliked having to manage my layouts separately in Java and prefer the control I get in Flutter.
✅
Hot reload – only available in Flutter and turns your emulator into an almost WYSIWYG layout editor
✅
Widgets – everything being a widget in Flutter simplifies things a lot and makes it clear and predictable how they will interact with other widgets
✅
Flavours – this isn’t completely baked in, but supported by Flutter. I would prefer the ability to know programatticaly which flavour is being used and not have to fiddle around the Android source to set it up.
✅
Dependency management – pubspec.yaml feels more lightweight than a build.gradle and I don’t have to worry about all the support libraries just to build an app
✅
APK size – based on what you get for it, I feel that the Flutter APK is probably still too bloated
4.07MB
10.03MB
Android Studio and VS code. I prefer VS code as it is more light-weight and doesn’t try and cook my processor, although I switch to Android Studio from time-to-time for things like the layout inspector.
✅
Maturity – it would be unfair to say that Flutter is incomplete, because it is possible to build a production-ready app with it, but some things will be a bit harder to do due to it still being relatively new.
✅
Wearables – not supported in Flutter yet, but I expect it will happen if wearables are still popular in a couple of year’s time.
✅
Ability to build for iOS – this is the winning point for me about Flutter. I no longer have to fear that I’ll have to learn Swift or Objective-C. It makes me sleep better at night.
This update was to bring back map views to the way in which they used to work, but also give you the ability to have new features (like a half-page view where you can also see the data in the bottom half).
I spent a little bit of time also trying to make file sizes smaller, make the app faster and use less data (it should already be pretty fast and using a small amount of data, but there’s always room for improvement).
Map views: you can switch between full screen and half screen. Some updates to make it work like the old version did. 🗺️
Update: updated wording and visuals for re-ordering of favourites in the settings page 🎛
Update: when re-opening the app, it should now refresh all of the data. 🔄
Bug fix: in rare circumstances, the app would crash on Android Pie (9) 🥧
Reduced the file size 📜
Speed improvements when loading details about routes 🏎️
Building a great app and making it a success on the app store, requires you to be much more than just a good developer. We often think that all you need is a good idea and some good development skills, but I can assure you, a successful app requires much more than that.
If you are considering publishing your own apps, here some of the things you might want to think about other than just the development aspect – together with good development, you need to also either learn these skills or source them from somewhere to make your app a success:
Market research: Are you building something that people will find useful? Are you just cloning something else which has already been done – in which case, what will make your app different?
Product management: A good product manager will tell you to focus your efforts on the most important things first and try to guide you to not waste time on things which are not important or not important immediately.
Testing: Do not underestimate testing. Especially as an independent developer, it is really difficult to test your own work, but it has to be done. There is nothing worse than a breaking bug making it all the way into production. You need to step away from the code and try and break your app.
User experience: When you develop an app, using it is quite easy, because you know how you made it. Have you considered what your app will look like to a user the first time they open it? I know my app exceptionally well and it always surprises me to watch other users use it.
Graphic design and UI design: This is something I struggle with a little bit, but I still give it a go (I do this so that I can get better at it). Publishing an app on the app store with an ugly icon or ugly user interface will immediately lose you points. As this is what a user sees immediately, I would even consider paying someone else to do it for me, but not before giving it a go myself first.
Marketing: Once your app works really well and you have published it, you are just waiting for people to download it. This really doesn’t happen by itself and you need to put effort in to get people to use your app.
Support: Things are going to break. You need the ability to look after your users and help them out. This can range wildly from code fixes, to explaining to them what they are doing wrong, updating your app to make it easier for users and so on.
Public relations: Once you are on the app store, you have gone public. Users are going to applaud you, they are going to criticise you, they are going to troll you. Especially when things go wrong, you need to be there for your users – this can be a tough one to do.
It is easy to think that all you need for a successful app is a good idea and some great development. These are definitely elements which will have a positive contribution, but there are so many other aspects you need to consider. It can be very daunting when you are the independent person and you have to do all these roles at once. But, in this, remember that you also have a competitive advantage – if users are not happy, or things change in the marketplace, you can change direction at the drop of a hat. You don’t have to ask someone’s permission or for through a bunch of bureaucracy to get things done.
As I continue writing, I’ll delve a little bit more into the various areas, specifically not focusing on development alone.
I was reading a post on Reddit which had some interesting statistics about Android OS versions and the speed (or tardiness really) of updating to the latest OS versions.
Of course the post is focused on individual phones, so it becomes difficult to get a sense of how many people are using the latest version of Android. So I decided, as I do, to check my own app for how version distributions have changed over the last four months. Here is a side by side comparison of the charts (the sample sizes are around 2500 users in both sets):
Of course – this doesn’t tell the full story either. It isn’t clear whether the shifts are due to software upgrades on the same phones, or whether users have just got new phones – or whether they are completely different users, but it paints a picture.
Something else to keep in mind when looking at this, is that my app is geographically biased towards London. So it isn’t representative of Android OS distribution across the world, or even Europe, it is very centred on London.
Here is the same data represented as a bar chart – just for a different perspective:
I’ve been looking around for interesting data points to share with other app publishers and found some data in a place I didn’t really expect to find it. After logging into my Google Analytics account for an entirely different purpose, I was taken to the analytics data for my app which I replaced with Firebase about 18 months ago. I don’t check it very often, but to my surprise, there is still a fair amount of action going on.
Users sessions in Google Analytics in January 2019
To give some context to the graph:
Version 2.1.1 – released November 2014
Version 3.1.3 – released 11 June 2017 and replaced on 24 June 2017 (Google Analytics was deprecated at this time).
This is amazing user retention for you! I don’t like the fact that I have data in two different places and that these users are mostly forgotten about, but I also cannot complain about it, since this is now just pure passive income. I actually cannot do anything to improve or remove it. Of course, it will also continually decrease as people upgrade phones, they uninstall the app and so on.
Why no upgrade?
At the point where I moved from Google Analytics to Firebase, I had to change my minimum SDK version from 14 to 15. This put me under the assumption that these users are probably unable to upgrade since they are using an old version of Android (4.0.2 or below). So I decide to validate it and check.
Checking which Android version my users are using
In fact, what’s not shown in the pie chart above (as you might think it’s hidden in “other”), is that I had 0 (yes, zero) users who were unable to upgrade to a later version.
Checking my Firebase stats confirmed a similar trend, some users are just very slow in upgrading their apps.
Apk’s lazing about on the internet?
I’ve found my APK’s all over the internet before and then had a look to see whether this is some new app store which I wasn’t aware of distributing old versions of my app. This pointed me to a really interesting installation source: com.sec.android.easyMover. Most of my users with old versions of the app, had this as their installation source. This is Samsung’s tool to move all your data from an old phone to a new one. Of course, this doesn’t point me to where these users initially got the application from, but it just points again at users who do not update their apps. (This also reminded me that I have a very small number of people using my app on the Amazon app store and I decided to upgrade it – it might actually work better for them, since I don’t use Google maps any more).
Architecting the enduring app
I did an earlier post on my app’s version history, where I walked through all the versions of my app from 2013 onwards. I was slightly surprised when I installed version 1.0.0 and it was still working exactly as it did the day I built it. This was mostly by design, but also with a bit of luck.
The external API which my application uses, hasn’t changed since 2013. This is the bit of luck which I had, because if the API (which is not in my control), changed even just a bit, all my old versions would break.
On the other hand, some of the design was deliberate. I had two options when I was designing my app – I could either stick a server between the mobile device and the external API or I could just call the API directly from the mobile device. (Incidently, I had already written much of the server-side code, as I had already done a web-version of the app before even starting the mobile version). I decided to cut out the server, mostly to keep costs down and also for speed considerations – I did not want to create a bottleneck or have to pay when it becomes really popular.
Option 1: Let the device get data directly from the APIOption 2: Put some middleware in place
Note that just because option 1 worked out for me, it doesn’t mean that it is necessarily the best option (in fact, in many instances it probably won’t be). There are pros and cons to both and you have to carefully consider them. Speed and cost were two important considerations for me. Not having to have a server in between means that I don’t have to pay for it when 10,000 devices all try to access data at once.
On the other hand, if the external API had to introduce a breaking change, my old versions of the app would all break irreparably and all the users who have been happily using my app for years now, would be really upset (this could be really damaging for my app at some unknown point in the future).
I had to take a bit of a gamble in terms of how to architect my app – as an independent developer, I simply didn’t have the resources to maintain a server and I ended up here out of necessity. Also, as an independent developer, I don’t necessarily want to maintain a server indefinitely just to keep my app running.
Summary
There are no right or wrong answers on what the perfect architecture looks like, but you have to keep in mind that people may continue to use your app for a long time after you intended them to do so. One version doesn’t simply replace another and as soon as you publish something, it’s going to be out there for a long time, so make sure that you plan for this. You wouldn’t want you users to give you bad reviews in 5 years time because of a decision you made today.
As a quick side-note, I have seen apps which force you in the app to upgrade to a later version when it becomes available. I don’t like this – in fact, I hate it as a user experience. A better idea might be to just let the user know every now and again that they might be using an out of date version and they should consider upgrading. Don’t force it, unless it is absolutely necessary.
I’m previously an Android developer who got started with Flutter and rewrote my Android app in Flutter to release it on iOS. During this process, I learnt a few things about implementing material design in iOS and generally things you might want to think about as an Android developer when you also work on iOS. (I flip-flopped between using Flutter or material design in the title as this post is about a bit of both).
As an Android user and a bit of a purist, I get pretty annoyed when I use an app and it looks like an iOS app. I want developers to respect the Android platform. In comes material design and this changes the thinking, material design is supposedly cross-platform and apparently should be fine for iOS too. Ok, so Google said that is the case and I believed them.
I took my Android app and developed it for Android and at the last minute, picked up the MacBook and built an iOS app from it. It surprisingly just worked! I put in no special code for iOS (the only exception for platform specific code was a check I had to do in order to support upgrading from my native Android app to my Flutter app (which I know is still native!)).
Never look back
When I ran the app on the Apple simulator, I realised that there wasn’t really an easy way to navigate back in the app. Since I used the Bloc pattern and I had a burger menu, I rely on the Android or hardware back button in order to go back in my app. I wrongly assumed (and I’ve had an iPhone before, so I realise how naive this was) that since Apple users don’t have back buttons, they think differently about navigation and would probably just find a different way of navigating to the thing they saw two screens ago.
I showed my app to a colleague on his iPhone and his very first reaction was – “how do I go back” – he was looking for a way to go back in the top left hand corner of the screen.
Luckily, since I was already handling the back navigation using the Bloc pattern, I could just provide a button on the page that would do the same thing and help the user to navigate back.
Show context
When I investigated “back navigation” in iOS, a pattern I noticed is that you generally want to see context of what you are navigating back to, rather than just “back”. So I also had to start keeping track of that too.
The back navigation which also shows the name of the previous page (Routes).
In the screenshot I did, I realised that my app bar is looking a bit crammed, but the general idea is there. I had to add in back navigation, since there would be no other way to achieve this.
The other thing I had to do for Apple devices, is to shift the burger menu to the right, since the left is now taken up with the back navigation. I have seen examples where the back navigation and burger menu would be below each other, but I chose to just have it on the right hand side instead for Apple devices.
Back ≠ exit
On Android devices, once nothing is left on the back stack, you just exit the app. This is not a pattern followed on Apple and you should not just quit the app. At the point that nothing is left on the back stack, I just remove the navigation button.
No transparency with Apple
A bit of an issue I had was with my launcher icons and also with my screenshots for the app stores. You are not allowed any transparency in these images. In hindsight, it feels like good practice, but it’s annoying when you have made a bunch of icons and a bunch of screenshots and have to redo them.
Build is different
It is worth mentioning here. Building an app for iOS is a bit different and there is a bit of a process. I had to get my hands on a MacBook and had to do a few weird things with certificates (I really have no idea what exactly I did!). I follow a fairly mechanical process in getting a build done and Xcode also automatically submits your app to the store. In there the process is also a bit different (and slightly slow).
Summary
It was a whole lot easier getting an iOS app out than I ever thought it would be. Apart from a few minor styling changes and a change in the way my users navigate back in the app, the app works the same on both platforms. I was really surprised at how easy it was – especially since I told my users about 6 months ago that I’m unlikely to ever give them an iOS app.
We finally have the ability to re-order favourite stops – hopefully this will make life a little bit easier for some people.
• New: you can now re-order your favourite stops in the settings menu ⭐️ • New: routes list of all the bus routes 🚌 • Updated: cleaned up the side drawer and made the links a bit better 🖌️ • Updated: nearby stops are now available without having to use the side drawer 🚏 • Updated link to privacy policy 📜 • Updated the splash screen 🌊 • A few small bug fixes 🐛
As I start a new year and trying to make a bit more revenue from my app, I’ve been thinking a lot about monetisation lately.
My current “strategy” for monetisation is:
Free app with a banner ad neatly placed out of the way. This is my main source of revenue.
Paid for app with the banner ads removed. I earn more on a bad day of advertising, than I do in a good month of sales.
Killing off the paid for version
My paid-for version is a bit of a thorn in the side. People have paid for it, and I am guessing it is mostly people who wanted to support me. I have fewer than 100 active installs, but they are active installs nonetheless. I have several issues with having this as a standalone app:
There are overheads in maintenance. It’s not massive, as my PC does most of the work, but it generates a separate APK, I have separate space in the app store, analytics and crash reporting apps have to be aware of this separate app. Just because it is easy to create a separate app without ads, doesn’t mean you should always do it.
As a standalone app, if I wanted my users to have the ability to easily port their data to the paid version, I would have to specifically write something to handle this and then support it.
As a separate app on the app store, I am competing with myself. I think there are some benefits to this, but I never look at the rankings for my paid for app, because it will always be lower than a free one with the same functionality. All those lovely 5 star reviews on my paid app don’t really matter, because my free app will always rank higher.
I consider users who have paid for my app as loyal supporters – and I want to return that loyalty. However, at what point does that loyalty run out? Do I have to indefinitely support a user who paid £0.79 back in 2015? (It sounds like I resent those users, I really don’t!).
Other ways to monetise
AdMob is constantly suggesting to me that I should move to more aggressive forms of advertising in my app (like interstitials and rewarded ads). I think that putting a 30 second ad in between a user and the information in my app is a really bad idea. My app is all about instant information and I have to be aware that no amount of short-term revenue will fix a really poor user experience. By looking at it this way, I think I may be able to find opportunities in my app where a user doesn’t want instant information and may have some opportunity for this.
Tip jars
I read somewhere about the idea of a tip jar in an app. I haven’t really seen any implementation like that, but I like it. I don’t really want to see how others have done it, because I think I can take my own spin on it. Basically, I want to allow users to contribute whatever they can afford in return for something. The way I want to implement it, moves more towards a subscription model, rather than a tip jar model, but I think from a user’s point of view, it might look the same.
Giving them something
Let’s talk about the “something” that they would get in return. I don’t want to put any of my core functionality behind a pay wall. Why would someone pay for it in my app, if they can get it for free plus a few annoying ads in another? So the general idea is that the something they would get, is probably the removal of ads and maybe some functionality which doesn’t form part of the core of my app or functionality which differentiates me from my competitors.
Subscriptions
In terms of the subscription model I was talking about, rather than making “premium” features available forever, it would be for a limited (but long) time period. I am thinking between 6 and 12 months at the moment, possibly dependent on the amount you tipped.
Rewarded ads?
Maybe I can credit a user with some “subscription credits” when they decide to watch a rewarded ad instead of paying. I would imagine that these credits should run out a lot sooner than it would for paying users, but you could get a “try before you buy” experience by watching a rewarded ad.
Putting it together
So my offering would change to look something like:
Only a single free app with in-app purchases
If you use the free app, you get all of the core functionality and some neat little banner ads which try and grab your attention
You can pay me to remove ads and gain access to premium features (prices and time periods are for illustration only – it probably still needs some balancing):
Buy me a coffee for £1.95 – gets you 4 months premium access
Buy me a pint for £3.95 – gets you 9 months premium access
Buy me a something which costs £4.95 – gets you 12 months premium access
You can watch a rewarded ad which allows you to gain access to premium features for a number of days (somewhere between 3 and 7).
Not just about money
Whilst the idea is to try and increase my revenue and make more money, I also want to protect the user experience as much as possible. I could just slap ads in the middle of everything and I could try and be sneaky by making ads appear in different spots on every page to really confuse my users, but this doesn’t work for me in the long-run. I need to protect the user experience as far as possible and for me, this way of monetisation feels like it could be a win-win for all. Obviously this is still an idea and still need implementation, but time will tell as with everything related to revenue in the app market.
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.
