Coding to keep the lights on

This has been a really busy year of coding for me so far – not that you’d be able to tell from looking at any of my own apps, which haven’t seen as much activity this year as I’d have liked. With ever declining App Store revenues, I’ve had to start spending a lot of my time doing contract work. The upside is this keeps the lights on and the rent paid, but the downside is obviously fewer updates to my own apps. They’re not forgotten of course, but I feel they’re all generally in a stable and mature enough state that they don’t desperately need monthly updates. Still I don’t wear “last updated in 2015” as a badge of honour, so things are in the works, however slowly they may come to fruition!

Despite the diversionary nature of contract work, I have been rather enjoying it. I’m lucky to have found a really excellent client that I’ve been working with for the last two years on a couple of apps. This year I built them a new app from the ground up and it’s been a great learning experience and a chance to dig into some new technologies and master others. For example this is the first time I’ve really dug deeply into the Facebook Graph API to get things accomplished that are outside the functionality offered by the SDK.

I’m still convinced Swift isn’t quite ready for prime time yet, and it certainly wasn’t when I started this most recent app, so it’s been a great exercise in writing the cleanest, most modern Objective-C code I can. If at some point a migration to Swift is required, it will be a less onerous task as a result. Whether it’s specifying the nullability of method parameters, using dot syntax as extensively as humanly possible, having everything be asynchronous and block based and trying to avoid some of the old design patterns that have fallen out of favour. That said I’ll take singletons to the grave with me! I’ve yet to be convinced that passing around endless model objects, which are only ever instantiated once during the lifespan of an app, is anything other than hair shirted asceticism for the sake of trying to look clever.

After inheriting a big project from another developer when I first started working with this client, I came to really appreciate the importance of good code documentation. Not that the code was bad, it wasn’t, it was just written in a different style to what I was used to and it was almost entirely uncommented, and where it was, often in unhelpful ways. There’s nothing like finding a nice “//TODO: fix this” comment where you’ve no idea what is broken in the first place! As such I took pains to make sure that every method in this new app had Appledoc formatted comments explaining what it was doing and how it should be used. This is incredibly handy with the Quick Help inspector open in XCode, as you can see what any method call is doing just by selecting it. Given the amount of time we spend reading and trying to understand code (even if we’ve written it ourselves), the extra minute or two it takes to document as you go is a drop in the ocean.

Something else I’ve done for the first time in this project was to create my own logging function to use instead of the venerable NSLog. In particular I was keen to log messages both into the console for my own debugging purposes, and into a log file that I could then display within a debug screen in the app and that testers could easily email to me. As the log will only contain things that I am specifically choosing to write to it, that helps cut down on the the inevitable noise you get in the standard console log. In an app that makes extensive use of web API calls it’s really useful to be able to clearly see the chain of events and any error return codes those may have generated. I think I’m going to adopt this strategy in all of my apps going forward because it’s just so much more flexible. It also makes it possible to completely turn off console logging of spurious debug messages in release versions of apps very easily using preprocessor directives.

Anyway I’ll leave it there, but in summary although I’m having to divert attention from my core apps at the moment, what I am working on is helping to make me both a better developer and expanding the technologies I know how to use. When you’re just working on your own projects all the time its very easy to get stuck in a technological rut and frankly it feels pretty good to get out of those once in awhile!