From Barcode to Passbook

My prototype app based on the MakeMeAPass website is up and running. You simply select the card type, use the camera to scan the barcode and hey-presto, you’ll have a passbook pass to add.


The usual issues still apply, such as some scanners being unable to scan barcodes on Passbook.

I’m planning to add simple location awareness too, once I get version 1.0 into the store. It will be available to download for 99p.

Multiple Device Support with TestMDM

This has been a long time coming, but I finally added multiple devices support to TestMDM

MultipleDeviceSupportWhen you issue a command, you’ll now get the option to select the device you want the command to go to. This makes it easier to test your app on multiple devices.

I’ve also removed the Pay-As-You-Go option and replaced it with a single, 30 day unlimited access license. I’d like be able to spend more time working on TestMDM and I can only do that if I can generate some money.


Peopler now approved!

After more than one rejection by Apple, Peopler has now been approved for sale. If you want to check people’s calendars in MS Exchange without needing Outlook or messing with Shared Calendars, Peopler might be what you’re looking for! It’s free to download and can be upgraded using an In-App Purchase if you like it.

Please send me any feedback you have and share it around if you do like it!

PassVerse is for sale

After many months of soul searching, I’ve decided to sell my PassVerse product.

I’ve been working on PassVerse for over two years and it has changed from a SaaS product to a standalone software product. I’ve learned an awful lot about selling software and I’ve some happy customers who use PassVerse within their own businesses. As I’m focused on my freelance work at this time (I need to get a mortgage!), I don’t have the necessary time to grow and support PassVerse. I’ve placed it up for Auction and you can check it out at

If you’re interested in becoming the new owner of PassVerse and taking it forward, please check it out!

How to view your colleagues’ schedules at a glance!

I spent some time over the weekend tweaking the UI for Peopler. I think this version looks a little clearer and more distinct. I’ve also added a new feedback page to this version and I’m keen to see whether this makes a difference.

iOS Simulator Screen Shot 9 Feb 2015 10.16.26

Peopler lets you view the calendar’s of other people using Microsoft Exchange. You don’t need shared calendars or anything complicated, just the person’s email address.

Peopler is available to buy in the App Store

This new version, with the updated UI, should be approved within the week!

How accurate is accurate? GPS adventures with Android

Testing of my Job Tracker app continues in earnest and, I’m pleased to say, it is becoming a useful tool that my brother is beginning to integrate into his day.

While this is all very positive, there is a new issue that reared its head yesterday and it’s a doozie! One of the functions of the app is to capture the user’s location at appropriate times. The app will then analyse this location and take action using this information. One of the actions it takes is determining whether or not the user’s van has moved in between and entry and exit event (getting in and out of the van). It does this by comparing the current position (exit) with the last known position (entry). If the distance is greater than 100m, we assume the van has moved.

Yesterday, whilst on a job, the app determined the van had moved, in spite of the fact it hadn’t. It recorded two positions:

Screen Shot 2015-02-07 at 09.27.34

I then check the logging provided by the device (I use my own HTTP Logging module that sends the logs directly to an Azure web application). The first block of logs show the position being recorded.

Screen Shot 2015-02-07 at 09.29.20It clearly indicates the position has an accuracy of 36.0m and an age of 34 seconds, which is within the 50m /1min tolerance defined by the application. I read this as meaning that they are  36m from this position, at the very most. The user then returns to the van to get something and, as they walk away, an exit event is triggered and the application determines their location again.

Screen Shot 2015-02-07 at 09.28.42

This position has an accuracy of 26m and an age of 24 seconds, which is an slight improvement over the first and to be expected as the FusedLocationAPI gets better with time.

When I compare the actual distance between those locations, I get 0.11km, a distance of 110m. This is outside the 100m allowance and the system therefore creates a new record. This behaviour is throwing a spanner in the works!

Given the two accuracies of 36m and 26m, I believe the theoretical max distance between these two positions is 52m, well within the 100m. I just cannot see how they are 110m apart. I realise that the distance was 10% greater than the allowance, which isn’t really that much in GPS terms (10m is nothing!), but it’s enough to reduce the usefulness of this app, because the arrival and departure times are wrong.

I am going to reduce the location filter from 50m to 40m and see what effect that has. Lowering this could cause greater battery drain as the GPS radio needs to be on for a little longer, but I need to see what effect it will have.

Do you have any experience with Android and the FusedLocationAPI’s accuracy? If you’ve done anything in this space, I’d like to hear your experience.