Category: London Bus Pal

Categories
Development London Bus Pal

Flutter on iOS for Android developers

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.


Categories
London Bus Pal

London Bus Pal v4.1.0

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 🐛

Categories
Development London Bus Pal

Ideas on monetisation

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.

Categories
London Bus Pal

Tips I wish I had when I started with Android apps

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.


Categories
London Bus Pal

How to show support

Many mobile app users (including myself in the past) think that there is only one real way to show support for a developer and that is by paying for, or buying their product. Whilst I don’t want to ever discourage anyone from passing me some cash, there are other ways in which to show appreciation and it is actually worth more than people think.

Let me just quickly explain – the only way to remain competitive on the app store, is to have a free app which either has ads in or some other form of in-app purchase. As I do not currently have in-app purchases, I only earn a (small) income from showing ads. It’s a simple game of numbers – the more people I have to show ads to, the more money I can make. So rather than money, I try to focus on getting more people to download and use my app. From my side, I do this by making the best app I possibly can that will cause people to come back. Here is how you get support me:

  1. Leave a rating and update it from time to time, even if it is the same. This is just a case of giving me a number of stars and you are done. It helps in two ways: firstly, I get a feel for how people are feeling about the app – this is really important to me as a point of feedback; secondly, it helps with ranking in the app store – a well-rated app will feature higher in the rankings and in an app market saturated with app about London Buses, this is really helpful to drive downloads.
  2. Leave a review and update it from time to time, even if it is the same. And not just any review – tell me what you like or how I can improve. I read all of it – I get notifications when reviews are written, so I get a view of what people want from an app. And if there is something you want, don’t be shy to ask.
  3. Fork out the money. This really is at the bottom of the list for me – points 1 and 2 are significantly more valuable to me than the money from app sales. They have a longer-lasting effect and if really constructive, can bring in more income than 3 alone. Of course, I don’t want to sound like I hate people buying my app, because I don’t – I just don’t want people to feel like the only option to support me is to part with their money.

Thank you for all the support so far!

Categories
Development London Bus Pal

Reordering favourites

Today was spent finally implementing something I have been meaning to do for probably years now. Up until now, there just wasn’t a way to reorder your favourites – probably the only control you could have would be to add them in exactly the right order.

I kept flip-flopping between doing it directly on the favourites screen, or doing it in the settings screen. My opinion is that it would feel more natural to just take a stop on the main screen and drag it to the position you want it to be. That is, until you realise that some users have 10 or 20 favourites. It would be very difficult to organise it – especially if you want to drag something all the way from the one end to the other.

One other thing I have to think about was the potential of breaking the favourites screen to add this. You wouldn’t want to re-order favourites all the time. So I settled for the idea to do it in the settings screen. It also gave me the chance to quickly reorganise the settings screen a bit.

Quick plan to reorder some of the settings

I had the plan to use chips (if you don’t know what they are, there is a screenshot below) and allow users to reorder using them. I’ve never used them before and I had haven’t used drag and drop in Flutter before either. It took a couple of hours due to a silly little issue which had me stumped (thank you Stackoverflow – https://stackoverflow.com/questions/53585711/dragtarget-onwillaccept-and-onaccept-not-firing/53621273#comment94954839_53621273). At one point during the struggle, I was going to give up and use lists instead and maybe even “move up/down” buttons, rather than fancy drag and drop, but I wanted to have my chips! I persisted and got it to work.

Chips which allowed reordering of favourite stops by using drag and drop.

It worked okay on the simulator, but it felt a little bit fiddly. I got it to work really well and then decided to test it on a real phone. I’m not happy. It is pretty awful. It’s difficult to get the chips to land where they should and the chips are much bigger on the real phone, which meant that each one was on its own line any way. This would not really help a user very much and probably frustrate them.

I’m going to do it over again – I’ll probably just use a list view with up and down buttons. It is unfortunate, because I liked the look of the chips in general, but it’s just not practical.

Back to the beginning for me now…

Categories
London Bus Pal

The many hats I have to wear

If you thought I was just an app developer who wrote a bit of code and published it to Google Play, you’d sadly be horribly mistaken. Doing this all on my own, means I have to wear many, many, many different hats. It’s a lot of fun trying my hand at all the different thing, but it also means that I can become spread thin trying to manage everything else together with my day job.

Here are some of the fun things I get to try my hand at while I work on my apps:

  • UX researcher and designer: I am a firm believer in good user experience and following good design patterns. When I built version 3 of the app, I spent hours upon hours reading the material design specifications. I had to carefully sit and work out margins and colour schemes and figure out how to get the material design concepts working before all the tools were built.
  • Graphic designer: Or something along those lines. I had to draw the icon for London Bus Pal myself – I know, it looks like an amateur made it – that is because an amateur did! I also did the “swoosh” image (the one in the menu bar when you swipe left) myself and as much I would hate to admit it, I also did the splash screen (it needs serious work, but I have to focus on other things for now). All of the artwork in the app stores were also made by myself with free tools I could find.
  • Marketeer: I have to find ways to get people to download my apps. I have to create campaigns and I have to, at some point, put that graphic designer hat back on if I want to make them more eye-catching.
  • Sales person: When it comes to sales, the main thing I am selling is advertising space to other companies. It almost feels rude to say it, because I don’t necessarily like ads, but it is the most effective way to monetise a free app. I have to keep my eye out to make sure that I sell the space well and for a good price. Much of it is automated and out of my hands, but it is a role I have nonetheless. (Don’t worry, my UX designer would never allow me to just litter my entire app with ads, it has to remain functional!).
  • PR management: I feel like some times when doing development, I cannot just do things right the first time. I always make a mistake and have to go back and fix it. With my PR hat on, I have to make sure that I keep my users in my good books and that they stick around.
  • Support: I always have to be on top of the latest issues. Especially around big releases, this takes up a large chunk of my time – I have to constantly monitor logs and check user behaviour to see if things run as I expect them to. When they don’t, I have to figure out why – with GDPR combined with some limiting tools I use, this can be a massive challenge at times (https://www.londonbuspal.co.uk/blog/the-helpfulness-of-reviews-even-bad-ones/).
  • Product manager: I have to always be on the lookout for the next big things or how I can improve my app to the benefit of my users. This is mostly what my day job is, so doing it for my app can become tedious or feel a bit fake, but it is really useful to make sure I build the right thing and not just what I feel like building today.
  • Accountant: Even though I just make a bit of pocket money from the app, I still have to count all those beans – one benefit of it being a simple setup is that things are pretty easy to count!
  • Developer: This is my favourite part of it all – I get to sit down, be a bit creative, solve some problems and see what I built once I am done. I also get to experience a little bit of what the developers I work with every day experience, so it even helps me in my “real” job. I also use this as an opportunity to learn about things where I might want to see for myself how it works (automated testing and repository management being some of my interests).
  • Tester: You would not always say so, but I try and do this as thoroughly as I can. But when you develop something yourself and you look at the same things all the time, it can become quite challenging to do this thoroughly. I am always hopeful that this is where my test automation helps me out, but for that I need to invest more time in it.
  • User: I love using my own app. It does what I want it to do and that makes me happy. I know what I want it to do next and that frustrates me – because in order to do all that, I need to do all those others things!

I love doing this and being able to experiment with all these different things. I would love to have more time to devote to this, but at the moment it is just my spare time I get to use for it. When things start picking up, I will have to look at how I make more time, but it’s always a question of economics!

Categories
London Bus Pal

London Bus Pal v4.0.9

Really small change in this one with a drastic improvement in load times when trying to find nearby stops. In the past, it could take a really long time if your phone was “starting from cold” – this should be fully resolved now.

Categories
London Bus Pal

The helpfulness of reviews (even bad ones)

Last week I posted on here after I felt really frustrated about a number of bad reviews I had received. I want to please every single one of my users and when I hear that they are not happy with my product, it often gets to me.

That said, despite making me feel frustrated (or maybe devastated as I put it during a frustrated post), reviews are also endlessly helpful. Especially when they say why they like or dislike my app – it gives me a really good insight into what users want. Quite often, I just see the numbers, 5,4,3,5,4,5,4,5. Whilst I like seeing the numbers and it higher numbers make me really happy, they can, quite easily just become a bunch of numbers.

This week I have continued to get less than perfect reviews, but the contents were quite helpful. I could sit down and read each review and try to put myself into the shoes of the user. I addressed each review (not only with a reply, but with some real code change) one after the other. I dealt with it and my app is better for it. Also, the users who gave me the input now have an app which behaves more like they want.

Don’t ever feel bad for leaving constructive feedback for developers. For those who care about what they give their users, this is infinitely helpful.

Categories
London Bus Pal

London Bus Pal v4.0.8

Some user feedback required additional updates which I wanted to get out before it affects and frustrates too many people:

  • Bug fix: “Unexpected errors” when trying to find location would happen more frequently than it should. This updates tries to address this – it might just take a couple of seconds for the location to be found.
  • Usability issue: The “favourites” star was too close to the expand and collapse arrow, which made it easy to accidentally add or remove favourites. I moved this to be out of the way to reduce accidental pressing of this button.
  • Usability issue: I also added in a prompt to validate the removal of any favourite.
  • Update: I removed the “experimental” tag from the map views.
  • Feature: For iOS only, I updated the app so that it is possible to navigate backwards (Android users already have this). This meant that I had to move the menu to the right hand side to make sure that I had space for the navigation button.

Thank you for all the feedback you have provided, it is helpful to make sure that the app is as stable as possible.