Since starting iOS development I have been somewhat reliant on Interface Builder for setting up views within most of the apps I’ve developed. More and more I feel as if I’m committing a sin and should be hand crafting each view programatically.
I’ve been planning to rewrite the code behind the composer within the Buffer iPhone app. As I continue working on making the application Universal to bring in iPad support it feels like a good time to refactor/rewrite. It also feels like a good time to put a hold to my love affair with Interface Builder and brush up on creating user interfaces programatically.
The Interface Builder version of the Buffer composer is somewhat limiting to what we can achieve on iPad without any major restructuring. We obviously don’t want to have to compromise any aspect of the composer because of limits within Interface Builder. It needs to be intuitive so that all of our iOS users are able to use it with ease and it’s not just a blown up version of our iPhone composer on the iPad, which it is in the current development version.
The current composer originates from the very first version of Buffer for iPhone back in 2011. Some of the composer interface remains the same despite the redesign for version 2.
Over the years I’ve read many posts detailing the reasons for and against using Interface Builder. It’s taken me a while to actually decide to take the plunge and go for it. In fact after starting to write this I have gone ahead and kicked off rewriting the Buffer composer without a nib.
Why i’m moving away from Interface Builder
I have a couple of reasons I want to push myself to do this from now on…
I’ve recently started to use compiler flags within the iPhone app to allow us to enable and disable features with ease. Facebook do this in their iOS apps also, it allows for features to be developed in the background and if they are incomplete or buggy then they can simply be turned off before pushing an update out. Using this within code and Interface Builder is fairly easy but relies on hiding or removing UI elements from the interface, where as if I wrote the UI in code alone it just wouldn’t get added in the first place if the compiler flag was off.
At Buffer we are continually working on bringing new features to our users, which means we have alot of branches for web and our mobile apps. Having interface tweaks across these branches nearly always results in a merge conflict which then takes a while to resolve. If the UI was solely built with code then these would mostly be a thing of the past.
Having relied on Interface Builder for a while I feel as if moving away from it is the next step in the long learning process. It’ll hopefully allow me to pick up new techniques and knowledge I have skirted around through the use of Interface Builder.
Along with this I also want to brush up on my code organisation, something i’m sure we could all improve in some form or other. Having the extra UI code visible to me (rather than hidden away in XML) will hopefully push me to find nicer ways to layout code.
The composer within the iPhone app and our iOS SDK uses alot of the same code. Although not cleverly shared between the two yet. The hope after this refactor is to use the same composer from the iOS app within the iOS SDK. Bringing more functionality to the SDK and making maintenance a breeze.
I’ll no doubt still be using Interface Builder as it remains a big part of Buffer & Magic Bean, but for new projects i’m going to try relying on it only for quick prototyping.