© 2014-2015 by Zack Smith. All rights reserved.
Should you really be using IB?
- Anyone can build static GUIs quickly.
- If your task is to produce a quick, one-off app the UI of which is not complex IB may be sufficient.
- If the GUI will be not be totally static, you will end up laying out UI elements in code anyway.
- XIB files' contents change every time they are viewed, instead of when they are edited. This increases the number of check-ins in git but they are not meaningful check-ins.
- Inability to safely edit XIB files in a text editor. They are meant to be generated by IB.
- Inability to document the GUI in the XIB file because it is auto-generated by IB. This erodes maintainability.
- Source control problems such as single-line changes the meaning of which is difficult or impossible to ascertain because the data in a XIB file is not code. This erodes maintainability.
- Manual positioning and sizing of UI elements incurs errors e.g. objects ar accidentally placed 1 or 2 pixels off and the programmer is too lazy to fix it. It requires giving exact pixel positions and sizes within IB.
- While it may be easy to move or resize a button, it is tedious to make changes to details e.g. colors and fonts whereas these changes are quickly made to code.
- If a project will last any amount of time, it will eventually have to generate the UI in code anyway. IB leaves you with technical debt i.e. one or more XIB files that have to be converted to code. It is better to start with code to obviate such debt.
- A different Nib file is typically required for each platform e.g. iPhone 4s, iPhone 5 and iPad. In my experience, people who insist on using IB often have trouble supporting multiple screen sizes. In code, typically one layout routine can handle all platforms and if not, having multiple layout routines is not a burden.
- A different Nib file is required for each orientation, whereas in code it is a simple if (portrait) then ... else... and each layout is expressed in the same source file where comments and data can serve to clarify. In my experience, people who insist on using IB often have trouble supporting both portrait and landscape orientations.
- There have certainly been bugs in Interface Builder. If you become reliant on a buggy tool, your work is sometimes slowed or stopped.
- There have certainly been really bad design decisions by the team that created IB. You are at the whim of the IB team and their design decisions impact on you.
- Some Interface Builder nomenclature e.g.
File's Owner,does not exist in code and are inventions of the team that created IB.
- Some newbie hand-holding features are turned on by default and must be manually disabled.
- Porting of GUIs between platforms is nearly impossible e.g. the XIB files do not translate to Android XML or Windows XAML formats even though these platforms have analogous UI elements.
GUI builders are not a new invention by any means. They existed at least 20 years ago. Since their first appearance they have justifiably been met with skepticism:
- Why even bother, when code works and is most flexible?
- Why cater to the laziness of newbies at all, when they will have to learn how to hand-code GUIs anyway?
- Why cater to people who refuse to learn or cannot learn to create GUIs in code?
- Why accept the limitations of the GUI builder?
- Why accept the bad design decisions of the people who created the GUI builder?
- Why become reliant on the people who created the GUI builder and whatever bugs that IB contains?
At some point you will have to give up IB and auto layout. These are forms of hand-holding.
There's nothing new under the sun. Interface building programs will always be insufficient for any challenging UI, and consumers will always prefer apps that have challenging UIs over simplistic ones, to maximize personal delight.
There is no free lunch. Programming requires work and interesting UIs will ultimately have to be coded by hand. Use of IB incurs technical debt.
It's also a matter of values.
- Should organizations be held back by their laziest workers?
- An analogy: If one executive is too lazy to learn or use Bugzilla or JIRA, should engineering be barred from using it?
- Should organizations be held back by their least experienced workers?
- An analogy: If one executive doesn't know how to open an email attachment, should email attachments be banned?
- Should organizations be guided by bad argumentation, just because a manager believes such argumentation is popular?
- An analogy: Suppose some engineers decide that bathing in the bathroom or smoking in the office is a good idea. Should a manager accept such disgusting behavior, because he is timid to say no, or too eager to please?