Building the app – The First Version

The app you see on this site is a redesign of the original one. That initial version was written back in 2010 when I first decided I wanted to finally learn how to develop for iOS. That meant learning Objective-C at the same time. Which you soon discovered should be more accurately called [[[[[[Objective-C] the] one] with] all] the] brackets]. Since the best way to learn is to actually create something I decided to combine it with my other love of Les Mills group fitness programmes.

Being honest the first version was a little flaky. The Cocoa frameworks weren’t at the level of stability and polish that they are today. Especially the audio playlist one which was a bit of a problem since the app used it heavily. A helpful instructor used it in a few classes that I attended and we discovered issues such as switching on airplane mode before class prevents her mother calling and interrupting a series of jump kicks in the middle of a track. Phones then had nowhere near the level of ubiquity they do today so it was also learning about how best to use them in the environment of the time.

Eventually I put it out for public use and was surprised to get even a few downloads. I made it free because I wasn’t completely happy with how it turned out. Despite that it picked up a bit of traction through word of mouth. I could tell that because I was getting a few support emails. That was mostly split between “it’s not finding my music” and “it stopped playing during class”. The latter was the most serious and came from trying to use the built-in AudioPlayer class. While it worked for most things it had trouble working reliably with the continual checking I needed to do to track things during a class. So I ended up rewriting that component using AVMutableComposition. That turned out to be far more reliable and the problems playing in class tailed off.

The matching was an issue in the early days and it remains one with the current version all these years later. The problem was how to detect which song on a user’s device matches the one in a Les Mills release. Back then phones had nowhere near the processing power they do now. That meant you couldn’t do the obvious way of today in generating a SHA256 hashcode on each file as that would have taken an unacceptably long time and chewed through the phone battery very quickly. So I decided on ‘fingerprinting’ a CD (there were no music downloads at that time) which involved getting the running time and order of the tracks then comparing that data layout against the albums in a user’s library to see which ones matched. In most cases it picked up quite a lot. The advantage was that as long as the same album title was on all tracks and they were numbered consecutively it didn’t mind what the song titles or artists were. That naming was a major concern back then as no-one used the same format for those fields when ripping from a CD.

There were a few issues because most people simply let the ripping software pull the data down from the internet and it wasn’t always correct. Even today I still get BODYBALANCE 50 albums that state they are BODYATTACK 50. Getting clean data from lots of people is not an easy task so there’s a fair bit of pre-processing that goes on before I can add it into the system.

The matching had two sources of problems. The first was when two releases had the same fingerprint. This was something that became increasingly common as the number of releases increased with time. It was affected by the need to have a 5-second leeway on each song as CD-ripping software back then varied with some adding a few seconds before and/or after a track. So the matching had to be a little fuzzy. Around that time there was a fight between the gym and music industries in Australia which led to a lot of gyms switching to use cover music (see here for the full details). That now meant two versions of a release could easily have the same fingerprint. It meant adding in a workaround where the user had to select which album matched against a release if there was a conflict. It did work but I still remain unhappy at the implementation.

The second and main issue with matching was that it checked against the music in the iOS Music Library. Most people already had their music in there and given that devices then had storage space that was still very small you couldn’t really add more data such was music files into your own app storage area. Assuming people put the whole album into the music library things worked fine. But some people only put a few songs because they’d never be teaching the others again. So my support emails were mostly explaining this to them.

It was at this point in 2013 that I had a bad day and having got another support email decided to put a price on the app just to stop too many more people using it. Bizarrely this increased the number of downloads. I can only assume it was on the basis that if it costs something then it is viewed as having a greater inherent value over something that is free. I wasn’t going to knock back the income even though this does show that as a businessman I’m a reasonably good developer.

Things ran fine after that. Some Les Mills staff even gave me a mention which helped with sales. Then Apple stepped in with their cloud music. That product was a complete disaster with how they handled people’s music libraries. Many remember their live albums were suddenly half-filled with studio versions. It was even worse for group fitness instructors as their purchased versions which had been specially remixed to fit the choreography were replaced by something which had the same name but didn’t have the required extra bridges and chorus. Which made it useless to be played in class. So I had to find out what was happening, add features into the app to minimise the issues it generated, and then communicate it to all the affected users. While the severity of it has reduced over time I’m still having to occasionally do this today – eight years after the issue first started.

Despite the problems I see it continues to do the most important role of all which is providing users with a product which helps them in their life. These are some of the reviews that have been added to the App Store over the years:

It was always my intention to produce the next generation of the app because like most people who have built something and see it every day we can spot the flaws and where it chafes most for the user. So I finally started doing it.

A discussion of the new version of the app can be found here.