London Bus Pal

London Bus Pal v4.0.2

This version increased the speed of route searching significantly as it was terribly slow previously.

Bug fixes:

  • Fixed two minor issues which could cause the app to look like it is still loading more data when it wasn’t.

Platform: iOS only

London Bus Pal

London Bus Pal v4.0.1

This update contains just a minor fix as advertisements were not displaying correctly in the previous version.

Platform: iOS only

London Bus Pal

London Bus Pal v4.0.0

This is the initial release for iOS devices only. The app has been entirely rewritten from the ground up, but don’t worry, all the features remain (except for map views which will come shortly).

The iOS version can be found here:

London Bus Pal

History of the app so far

Back in 2013, I was a regular bus user in London and I remember having to use two different apps to get the information I wanted. The exact details have faded, but I remember that I liked the one app, because it was simple to use – you just open the app and it shows you the buses you want to see. The other app I used was to track progress once I actually got on the bus. Finding the right bus wasn’t always the easiest thing to do and having to use two apps was a bit frustrating.

By the end of July, I had put together an app using the technology I was familiar with (Google Web Toolkit) and I was delighted with the results. I remember feeling surprised that I made something which was better than anything I could find on the app store and my app did exactly what I wanted it to do. As I built the first version only for my own personal use, it meant that I could focus only on what was absolutely useful. All of the core functionality remains to this day (except for one unimplemented minor feature in the latest version which will be reinstated shortly):

  • Quickly see all the bus stop nearby and arrival information for each
  • Ability to select a specific bus and track progress
  • See the details of an entire route and where that bus would stop

I had been using the app on my own for about a month and I was happy with what I had built. I showed my partner who game me some great feedback about the app. Towards the end of September, I decided that I should share what I had built with the world! Of course I was going to use this as another opportunity to learn something new – so I threw myself into the world of app monetisation and I decided I was going to put a simple ad at the bottom of my app. Even though my original app obviously didn’t have ads in it, it was a good compromise to make to see if I could make a little bit of money with my creation. The rules were clear for me from the start – do not annoy users with ads.

By the end of 2013, I had accumulated less than £10 in total advertising revenue. But this wasn’t the point – it was a hobby and I was super happy with my app, because best of all, it was useful for me.

London Bus Pal

What a GDPR disaster!

May 2018 has been a really long and frustrating month in terms of updates to London Bus Pal.  I would never have imagined just how much effort I would need to put into my app when I thought that I was free from any GDPR requirements.

I was on holiday and I saw some emails from Google and then also saw an article on The Register ( which pretty much made it clear that I would have to do something.  Upon return from my holiday, I immediately got on the internet and started reading all kinds of horror stories of people building entire consent databases and having to come up with really intricate ways to obtain and store consent.  It felt like it was overkill and like it was completely against what I thought the spririt of GDPR was (less data, not more!).  The panic started to set in as it seemed like this was a much bigger beast than I had anticipated and I started studying the regulation itself, rather than just reading blogs based on third-hand information.  At least it turned out that I was right and that GDPR was meant to limit and reduce the amount of data we process, not process more data because of it.

After reading the regulation and no consent SDK being available yet from Google, I decided to build my own pages to manage this in the app.  I settled on the following requirements:

  • Location permission – I already had to obtain these due to Android requirements and my app works fine without it.  I decided to still build a screen to tell users about it and that they can revoke permissions if they want.
  • Ads – this was the main reason I built this, because it felt like Google was willing to stop us from using AdMob if we did not do something to gain consent.  To be honest, I understand where they are coming from as they would be held responsible if they didn’t insist on us doing something.  The consent isn’t to consent to ads or not, it was basically to use personal data to personalise ads or not.  More on this later!
  • Crash reporting – as I didn’t consider capturing crash reports as a legitimate enough reason to keep my app going, I decided that I had to gain consent to store crash reports.

There is very little else that I do with data – I just take a location or bus route or bus stop request, get the relevant data and show it back to the user.  I really have no interest in obtaining data I don’t need.

So I built my GDPR consent screens and I ran into a bit of trouble.  My crash reporting and analytics tools are bundled together really.  If I switch one off, I have to switch both off.  I then decided to change the wording for crash reporting to something along the lines of tracking expected and unexpected behaviour (the former being analytics and the latter being crash reporting).  I had some issues with the analytics, so I then had to go and find each use and check if I could use it or not before posting something as I didn’t use standard methods everywhere.

Due to the GDPR consent screens being one of the first screens and having to test with different permutations, I decided to just do some manual testing instead of expanding (and fixing) my automated tests.

I changed my AdMob settings to select my own technology providers and I published version 3.2.6 on Wednesday morning, two days before GDPR was due.  Things sort of looked normal, my ad revenue seemed unaffected and even though I could see a bit of a drop in users reported through my analytics tool, the users who still opted to keep crash reporting and analytics on, still had a 100% stability rate.

Over the next two days I noticed some 1-star reviews, two of them were removed before I could get to them and it just looked like someone trolling the updated GDPR screens.  But there were some legitimate ones too and I started to investigate.  I noticed on the Play Store that my app stability had decreased since the GDPR release and I found some specific pieces of code I missed!  If someone had chosen to turn off analytics, I still had some instances where I was trying to track events and it would crash the app.  I asked the users to contact me to give me more detail to help my investigation.

Rushing to get a fix out, I made sure I found all of the uses, fixed it and I released version 3.2.7 on Saturday morning.  I received another 1-star review saying that the app was broken – this review was left for version 3.2.7 and I also received an email from one of my users who confirmed the same.  Frustrated, I decided to take the nuclear option and remove all of my GDPR updates (by reverting the code back to version 3.2.5) and then just serving non-personalised ads.

I have now scrapped the idea of requesting consent for crash reporting and analytics since I believe that this is actually crucial information for the app to work based on the nightmare I had.  I was trying to stick to the “letter of the law”, rather than the spirit of the regulation.  The data I am collecting does not contain enough information to personally identify anyone and I’m happy to have it go under scrutiny.

Today I watched as my revenues plummeted.  This is either due to only serving non-personalised ads or the fact that it’s a bank holiday in the UK.  It’s probably a combination of both – I can see my click-through ratio has gone down and so has my CPC.  So I made another attempt at implementing a quick consent request so that I can at least get personalised ads back on for some of my users.

Effectively, all of the work I have done to implement GDPR in version 3.2.6 and 3.2.7 had to be undone and I started from scratch.  This time also, I have taken a softer approach and just made it a pop-up where you can choose Yes, No or Later – similar to my rating pop-up.  (I still used all of the saved consents from version 3.2.6 and 3.2.7 if it worked, so at least people won’t be annoyed with more pop-ups!).

I’m going to package version 3.2.9 now and publish it to all the app stores.  I am hoping that this is the final version for GDPR and that I can finally get onto other things.  If you are a user who was impacted by my GDPR disaster, I can only apologise!!!

London Bus Pal

Map views are here!!

I was hoping to get this out there quicker, but rather late then never!

This week I added some map views of all the data to London Bus Pal.  There are four “distinct” views of data in the application, but only three maps are interesting (seeing a single bus stop isn’t the most interesting view!).

Multi-stop view

If you switch to the map view from a list with multiple bus stops on, you will get a view similar to this.  It shows you markers of all the stops near you with their “letter” indicators on, it there are any.  This is a really useful view to see any bus stops in the area or near somewhere else you might be going (try searching by post code).  Tapping any of the markers will give you the name of the stops and where it goes – if you tap on the information box that appears, you will then be taken to the screen to see the estimated arrival times for all buses serving that stop.


Bus prediction view

The next view that is possible is one showing you a list of all stops for any specific bus over the next 30 minutes and the number on the marker indicates how many minutes the bus is expected to take to get there.


Bus route view

The last view I want to show you, is the bus route view.  This is a calculated route based on all buses for that route over the next 30 minutes showing their stops.  Red markers indicate one direction and blue markers indicate another direction.  The pins are also arranged so that you can get an idea of which way the bus is going (I will add some arrows soon!)


If you don’t have London Bus Pal yet, you can download it from the Google Play Store:


London Bus Pal

Racing the bus by tube!

I travel between Angel and Waterloo on most days. Most of the time, I take the 341 bus, because it always seems quicker than the tube and it’s also a whole lot less fuss. The strange thing is though, when I’m running late, I choose to take the tube, because even though the bus feels quicker, my logic tells me that the tube must be quicker. So I put it to the test this morning.

First, some ground-rules: I always walk as fast as I can without running or being rude (no pushing people out the way). I walk up any moving escalator, and I know my route very well, I take the shortest route to each platform and take the first available train.

  • 09:21: Arrive at Waterloo station. Check the bus will be at stop F in 1 minute – if I want to make it to the bus, I need to get there now, but today, I’m racing the bus instead of taking it.
  • 09:24: I get down to the Waterloo & City line platform with a train ready and waiting for me.
  • 09:29: Arrive at Bank station. At the point I begin to even wonder why I bothered – it all seems to be going quite quick. Unfortunately though, because I jumped straight on the train at Waterloo, I am right at the back of it, so have to fight my way through people to get to the Northern Line.
  • 09:33: I get to the Northern Line platform and I can see the train coming into the platform. Timing has been great this morning for trains, because usually I end up waiting for a few minutes.
  • 09:40: I arrive at Angel station and I am thinking that I am probably way ahead of the bus. Unfrotunately there is only one up escalator, so “traffic” is a bit heavy, but I still make it up in the end.
  • 09:43: I walk out of Angel tube station and open up my app to check where the bus is. I look across the road and think “No! This only happens in movies and documentaries.” – I’m assuming this will be a different bus, but I check the registration number and it is – the bus beat me to Angel station!

The benefits of the bus far outweigh taking the tube every day. Firstly, I’ve just proved that it’s faster for me to get across central London by bus (obviously, there are many tube routes which are faster – possibly if I tried doing the same starting from Vauxhall, results would be different), I have mobile signal when I’m on the bus – the wifi access on the tube works, but only in stations and I couldn’t pick up any signal at Moorgate station. And then there’s all the stairs and walking, which might be good for some trying to stay healthy, but I really hate getting to work all sweaty and red in the face. And the bus has a view of London! That’s probably the best reason to take the bus.

The above experiment was done using bus times from the London Bus Pal application for Android. You can download it from the Google Play store here:

Take the bus!

London Bus Pal

Just how accurate is TfL’s countdown system?

Just how accurate is TfL‘s countdown system

When I started developing London Bus Pal, the one thing that was always going to be completely out of my control was going to be the actual prediction data. I did some investigation as to how it all works and it’s really interesting, but probably worth a blog post of it’s own (so watch this space)!

There are a number of bus routes which I take frequently and I have definitely noted a pattern of “lateness” compared to the estimated times for specific buses at specific times.

I decided to take a small sample of buses and compare their estimated arrival times in 30 minutes to how it changed after 15 minutes and then to when they actually arrived.  The results were interesting (but not a big enough sample to draw any conclusions):

  • 341 to Angel Road Superstores.
    • First estimate: 28 minutes
    • After 15 minutes: 28 minutes
    • Final time to destination: 30 minutes (2 minutes later than initially predicted)
  • 19 to Finsbury Park Station
    • First estimate: 27 minutes
    • After 15 minutes: 27 minutes
    • Final time to destination: 27 minutes (exactly the time it estimated 27 minutes before)
  • 152 to Pollards Hill
    • First estimate: 29 minutes
    • After 15 minutes: 32 minutes
    • Final time to destination: 37 minutes (8 minutes later than initially predicted)
  • 55 to Bakers Arms
    • First estimate: 29 minutes
    • After 15 minutes: 30 minutes
    • Final time to destination: 35 minutes (6 minutes later than initially predicted)
  • 3 to Oxford Circus
    • First estimate: 28 minutes
    • After 15 minutes: 28 minutes
    • Final time to destination: 25 minutes (actually arrived 3 minutes earlier than initially predicted)

The times measured for the 341, 19 and 55 were all on parts of their route through central London.  The 152 and 3 were both for parts outside central London.

Obviously, when measuring and estimating bus times, there are loads of variables.  My experience in general however, is that the estimation is quite accurate up to about 20 minutes.

When I put together the above list, several things sprung to mind as to why some buses are seemingly more accurate than others.  Traffic, bus spacing (time between two buses on the same route) and route controllers are in my top list of what could affect it.  For instance, the 152 might have been made deliberately late because of another bus running late to maintain an even spacing (or it could just have been stuck in traffic).  I have a theory that it’s probably easier to predict bus times for high frequency routes compared to lower frequency routes, but I will probably have to prove that later!

I used London Bus Pal to compile the above data.  It’s an Android application  and has access to all the bus time prediction information for all London buses.  You can download it here:

London Bus Pal

London Bus Pal launched – the ideas


My first Android application was launched on 6 September 2013.  It’s called London Bus Pal.

I’ve had the idea for quite some time, but just never got around to doing it.  Finally, over the summer, I sat down and gave it a go.

The idea was for a bus time predication application which you could just open and it would know what you were looking for without complicated set ups.  It should just load it up and it show you what’s nearby.

I went off and built much of the application which can be seen today.  You could see all stops near you and then drill through items to see specific buses, stops and even routes (the route functionality only came later).

One issue I had, which took a while to sort out, was that the way in which I calculated distance, did not take into account roads, so in my case at home, my nearest bus stop, wasn’t the quickest one to walk to.  So I decided to calculate the walking route for each stop near me and then show the closest ones to me in that way.  Unfortunately, this ended up being a really slow process and I actually had to remove this feature.  It was definitely going to add to the cool factor for this application, but sometimes you just have to make a call and say, it’s not worth it!

So what did we end up with:

  • Stops near me – when you open the application or tap on the home button, the application tries to find your location and shows you all the bus stops in the area with all of their arrival times in the next 30 minutes.  (This does not work if your location could not be determined – there are many reasons for this).  You can expand and collapse all the stops and if you tap on a bus, you get taken to the bus view (see below).
  • Specific bus view – when you tap on a bus in the stops near me or bus stop view, you get taken to the specific bus view which will show you the route details and bus registration number at the top.  You then get a view of the expected time of arrival at all the stops for the next 30 minutes.  This is a useful view for me to keep open and refresh from time to time once I am on the bus, just to check progress.  (A slightly hidden feature is when you see a bit of a thicker line between two stops – this means that the bus changed direction between these stops and it will be heading back to where it came from).
  • Bus stop view – this is similar to the stops near me view, except you only see a single bus stop.  It simply shows you the next buses for any stops for the next 30 minutes.
  • Bus route view – this is a fairly unique view which I haven’t seen available on many other applications.  First, to access it, tap on the bus route details on the top of the specific bus view or enter a route number in search.  This gives you an overview of all the stops on the route, in route order and it shows you when the next bus is due at each of the stops.  It’s quick to see if there is a gap in the service anywhere between stops using this view!
  • Search functionality – this acts as a “short-cut” to many of the views mentioned above.  By entering a post code, or GPS co-ordinates, you will get the stops near me view (but for the entered location), enter a bus stop number (which you can see on the side of the bus stop) for the bus stop view of that bus, enter a bus route number for the bus route view and enter the bus registration number to find a specific bus (I have to point out that this does not work on customised number plates and I believe that some of the New Buses for London have custom number plates).

I decided to stick with this core feature set for now and get the application out there.  There are still many features which I think would make the application truly great, but these will have to wait a while as I only have ten fingers to type with!  As it stands, the feature set is very usable and I use this application constantly and very seldom use any of my competitor applications.

Some of the features I will be working on in the coming weeks and months include (if you are reading this in the future, be sure to check out the latest feature set of the application as this would hopefully not always be work in progress):

  • Bus stop notifications – sometimes TfL puts out alerts or notifications for specific bus stops or routes.  London Bus Pal doesn’t currently display these, so it’s difficult to know if there are any issues affecting your local stop.
  • Map view – being able to see bus stops on a map, especially for the stops near me feature would really add great value to the application.  Sometimes I am also on a bus and I wonder if I could get off early or I am just on a strange route and I want to see which stop I should use.  Being able to see that on a map would be a lifesaver!
  • Strip-maps (maybe) – this would just be a cool feature to have – to see buses on a strip map.  I’ve got some really cool ideas for this.
  • Bookmarks or favourites – most applications have this and they tend to be useful.  We all have our favourite stops and it’s always great to have these ready.  Hopefully the “stops near me” facility partly fulfils the requirement for this feature until it is actually implemented.

If you came across this blog and don’t know what I am talking about, you live in London (or sometimes travel to London) and you have an Android phone, then why not download London Bus Pal:

Looking forward to loads of downloads 🙂