Programming to the rescue – saving my YouTube favorites

During a recent visit to I was prompted with the question whether I want to have a YouTube channel (which longtime users have by default) or if I wanted it removed. With 14 days until the channel would be removed automatically I’d normally just postpone the decision and carry on browsing but this time my mind was pretty much made up: as I only use my YouTube account for favorites I really don’t need a channel – so that was the answer I selected.

Sadly what followed wasn’t what I expected. While subscriptions remain available, all features related to playlists aren’t accessible anymore – including my highly valued list of favorites collected since early YouTube days. Every way of accessing them and several other features leads to the following prompt:

So in summary if I want to access a lot of the features I had before making the fatal decision I would have to create a public YouTube channel and also a Google+ profile. Obviously this is a smart move on Google’s side but at the same time it’s incredibly annoying and also difficult to understand why a basic feature like favorites requires having a channel and Google+ profile.

That wasn’t an option for me but I didn’t want to lose my favorites either.

I noticed that my favorites remained available through the YouTube app for iOS but saving them from there would be a lot of manual work. This is where programming came in handy as the favorites also remain available through the YouTube API and according to this a simple call to

would return a list of a user’s favorites in xml. By default it only returns a limited amount of favorites at a time but by adding a few parameters and incrementing the parameter startindex until all favorites are returned (and the api returns 0 entries) one can get all favorites.

With this and a simple case of coding (in my case in Java) I was able to retrieve all my 257 favorites and save their title and URL to a file. So while it is sad to lose the favorites functionality on YouTube I was able to rescue something which was important to me at relative ease –  a good example of programming being a handy tool, not only for dedicated software developers.

AppStore Review mentality and surprising flexibility with Apple’s expedited Review

On Thursday morning (7:41) we released an updated version of the HAW DMI App which introduced a lot of new features as well as improvements. Sadly a minor change caused the app to crash on login for several students with a specific account setup making most of its many HELIOS-service related features unusable. This was first brought to our attention at about 1pm.

This led to users rating the app which had prior only been rated with four and mostly five stars with the dreaded “one star”. To us as developers this seemed highly unfair and caused some frustration as the app is free and has successfully been providing a lot of functionality to users. Looking at it from a less emotional perspective this seems to be the norm throughout the AppStore and tends to be the typical user reaction towards any major or minor problem (or even lack of a specific feature) regardless of how successful or liked the app had been beforehand.

ratings after bug fix (number of one-star reviews was higher before)

At this point we thought that even if we fixed and updated the app on the same day users would have to wait for at least 1-2 weeks due to Apple’s review times. Fortunately after some research I found out about Apple’s expedited Review program, which lets you apply for a quick review in the event of serious bugs which require an urgent update – a glimpse of hope!

In a matter of minutes and with the help of a crash log sent to us by mail (which is far more useful than a one star review saying that the app is great but the crash has to be fixed) we were able to find the culprit – as usual a minor code change introduced shortly before deployment hadn’t been thought through fully and caused a memory issue under specific circumstances. As we don’t have test accounts for all account configurations we didn’t experience this bug in internal testing. Either way the exception should still have been caught to prevent the issue.

At 3pm we fixed the bug, submitted it to Apple and applied for an expedited review by filling out a simple form. Luckily enough our request was granted at 6pm and much to our amazement the app was ready for sale only 4 hours later at 10pm. After lots of criticism about Apple’s restrictive AppStore policies this was an unexpectedly flexible and user-friendly way of dealing with a problem. Apple states that expedited reviews are a “[…] one-time exception” and “[…] are provided on a limited basis”, which is understandable. In any way it helped us and our users in a situation where we as developers had made a mistake which otherwise wouldn’t have been resolved until much later. Also the fact that we were able to solve the problem so quickly seems to have caused people to change their previous rating which is very much appreciated.

To sum everything up: Introducing a fatal bug in an app update is bad and users react accordingly, which has to be accepted without taking it personally – a lesson learned. Furthermore Apple’s expedited review program saved the day – hopefully we won’t make use of it again anytime soon.