iPhone SDK and Interface Builder – Less is more
So I’ve been tasked with maintaining an iPhone app that my company built on contract over the summer. At the time, the guy who built it (let’s call him Ray) didn’t know anything about iPhone or Mac OS development, and neither did I. In fact I’d never even owned a Mac before a few months ago when I purchased the MBP I’m typing this on. We’re a .NET shop here, and although we consider ourselves pretty progressive and open to new things, developing software in the Apple ecosystem is radically different to anything we’ve done before.
Ray left the company at the end of 2009, leaving me to carry on in maintenance mode until our support contract is up. While I was never involved in the project during the initial development phase, I did hear some interesting stories from Ray about how complex the app had become – among other things: 20000 lines of code! For a piece of software with modest functionality, and built with modern tools from the company who prides itself on user experience above all else, it seemed like an awful lot to me!
I reluctantly set out to learn the ins and outs of the app, and of course iPhone dev/Xcode/Objective-C and all the other fun stuff that comes with it. At first, I just accepted the fact that the app was complex and went about fixing bugs without really giving it a second thought. That was until earlier this week, when during our weekly status call with the client, one of the issues that was brought up was the fact that certain screens in the app don’t meet the interface guidelines set forth by the client. Things like colours or fonts not matching what’s in their PSDs can be a lot of toil and drudgery when all those colours and fonts are defined throughout the app in a lot of repetitive code. While we were discussing it, the client wonders why Interface Builder wasn’t used to create all the UI screens. I’m wondering the same thing myself.
Some developers view WYSIWYG tools as lazy, inefficent, and less flexible than “doing it by hand”. In some cases, I believe this to be true. I’ve never used a HTML WYSIWYG tool such as Dreamweaver in my life, and I intend to keep it that way. On the other hand, writing Windows desktop software in Visual Studio with .NET or even MFC is miles ahead of the drudgery of the Windows SDK stuff I remember doing in school. ASP.NET web apps have been the bread and butter of my company (and my career) since it’s inception, so we’re used to writing UIs in HTML by hand.
What is the recommended approach in iPhone world? Well, after some googling around I came across this: Don’t Fear The Interface Builder. I think this quote sums it up nicely:
If you’re writing tons of code to implement your user interface, that’s lots of code you have to write, maintain, and debug.
This is exactly the feeling I got when I started going over the endless lines of code doing things like instantiating buttons or table views and placing them on the screen – that’s a lot of code to debug and maintain! Things that don’t really have anything to do with the core functionality of the app. Now that I’m up to my neck in a sea of code, much of which serves no other purpose than rendering widgets, I’m feeling the pain. Before he left, I had the sense that Ray was too, although I’m not sure what prompted him to take the route he did, or if he realized the implications of writing all that UI code. If he reads this, I hope he doesn’t take it the wrong way, hindsight is 20/20 and I can’t say for sure if I wouldn’t have made the same decisions he did.
For now, I’ve decided to take the positive view that it’s an opportunity to learn about the innards of how iPhone (and to some degree OS X) apps are created. In the future, when I get the opportunity to work on a new iPhone project from the beginning, I’ll be sure to take this all into careful consideration. After all, when it comes to software and lines of code, I truly believe that less is more.
-M
