Fuel Collective

When you start developing a 2.0 version of your app, it’s like your kid graduating from high school. Either nothing really changes and the kid just goes to work, or you send him to college and then receive him a few years later, nearly unrecognized by his own mother by how much he changed.

As we love our apps we want the best for them, so we send them to college. For Swatch this meant starting with a completely new Xcode project, using 0 lines from the previous one. No matter how experienced a developer can be, when he comes to his project a year later (or even less), he sees immediately where he’s done some internal-design mistakes, what could be done better, etc. He evolves, learns new techniques, his coding style changes a little.

Since we started this company, over 100,000 lines of code went into our projects, which, of course, tought me a few neat tricks. 

First of all, don’t be afraid of the paper. I’ve seen many developers scared of this, nowadays, weirdly looking white sheet, however, use it. Draw it out. Draw bubbles with class names, link them with arrows and write the functionality above the arrows. Write rough method names to the class bubbles.

Then let it sit on your desk and come back to it after a week. You’ll see that there are better ways to do it, forcing you to reorganize it and redraw. That’s fine, actually it’s brilliant. Now wait another week. The changes you make then will be less radical. If not, take another week, otherwise settle with your plan.

Now that you have your plan, get to coding. Here I have some tips, too. Even though you don’t immediately need all the methods, declare them, implement them with a #warning statement that doesn’t just say ‘implement me’, but is more descriptive about what the method’s supposed to do. Believe me, when you get back to the method in a few weeks, you’ll have no idea what it was supposed to do and what special conditions should be taken into account. I have had less success using the #TODO’s and #FIXME’s as for the release builds you (should) almost always make a clean build which makes the compiler compile all sources, and if you’ve forgotten to implement the method, the compiler will give you a warning.

If you decide to use unimplemented methods, add logging to them. Something simple like NSLog(@”-[MyClass myFunction:] argument: %@”, arg0);. This way you’ll be able to do some fixes even before there is a bug. Imagine you’re asumpting some method won’t get called too often, therefore may be complex, but in early alpha testing you might find out it gets called too often, which would mean lags and high CPU usage. Rethinking the way it should work now is less work then later on, which would most likely break a lot of functionality in your app.

Sometimes you need to reinvent the wheel - it’s better than to start making a square out of a circle. This is a really hard part to decide. For example Swatch 1.x had some issues with  picking a color from a screen. Generally the issue was with the colorspaces - device RGB and calibrated RGB. In Swatch 2.0 we use our own FCColor instead of NSColor. FCColor has, just like NSColor, the -set method, +whiteColor, etc. Note that FCColor’s superclass is NSObject, not NSColor. However, remember you need a really good reason to do this. Reinventing everything is time-consuming and probably won’t work well.

These are a few tips I can give devs thinking about going 2.0, 3.0, or 4.0, etc. During my early developing I had an app, which I then moved to 2.0 later on and now have moved to 3.0. And even now looking at an app that I was writing from the scratch a year ago, I can see some mistakes I’ve made. Don’t get scared. This how you learn.

Krystof Vasa
Software Engineer