One of the biggest things that I stumbled over was whether or not I should code straight objective-c or use Interface Builder. In the end, I feel IB just gets in the way of being able to do cool things. I think if you're serious about making cool apps then stick exclusively to building apps with objective-c and avoid IB. (imho)
For normal interfaces XIBs are way easier to maintain and handle then a bunch of addSubView calls.
The only things that should be hard coded are interfaces that are too unique or exotic. Even then, XIBs allow you to place arbitrary UIView elements wherever you wish and you can get the best of both worlds.
How do you accomodate merging changes to XIB files within your VCS? It's already pain enough to deal with the Xcode project file. I ended up tearing out all use of IB in my large project after spending too many hours manually merging XIBs.
If I'm "doing it wrong" and there's a way to materially speed up my dev flow, please enlighten me. I can't wait. :)
Are you running into merge conflicts with other people?
Generally, we avoid any merge conflicts with XIB files. We have a small team so basically anyone who is dealing with it has an 'exclusive' lock until they are done.
That includes avoiding having a feature branch that makes changes to XIB files that might change in the main branch. Merging XIB file changes isn't for the faint hearted - and the likelihood of having a working XIB file at the end of a merge is not 100%.
Same as @wallflower.
Our team is really small (2) so we never really run into that.
I wouldn't want two devs working on the UI at the same time. It's kind of an unspoken rule because just merging anything UI related is a big pain.
Like from the web world, one dev would do the UI html and js, while the other would do the server logic and API.
I try to use the MVC model in my projects, where the XIBs and their accompanying .m files just have basic getters/setters and the xibs are rarely changed.
Indeed this is precisely how I do things as well. If I have a custom UIView subclass then I still lay it out in a xib in relation within it's superview. Doing it this way makes refactoring so much easier.
If you did this then in IOS 5+ you'll be missing out on storyboards which are a great productivity improvement. Not a good idea. Indeed you don't want to use IB all the time, but you should learn when to use it.
After a year of iOS dev, I have slowly moved away from IB as well. You'll start off implementig everything in IB and putting any sort of layout logic in your view controller. But eventually, you'll start doing more complex views, you'll find it difficult to handle rotation, youll find it difficult to create reusable modules which are expected to handle different environments correctly (ie, status bar bs no status bar, etc).
Then one day you'll strip all of the layout logic out of your view controller, delete your xib files, and instead create a set of uiview subclasses and override their layoutSubviews method. On that day you will be happy.
In almost every case I've encountered so far, doing this has cleaned up my code (removed kludges) as well as made my layout "just work" in all the situations where previously it was glitchy. viewDidLoad, viewWillAppear etc are a poor substitute for layoutSubviews.
I did this and deeply regret it. There isn't a good way to manually size and position elements in code. Doable, but not in a pleasant way. The real pain is doing all of that manual labor a second time over for an ipad version.
I've looked at reverse-engineering xib files in order to be able to produce my own, thinking it would make a pretty neat tool to use. It's a nightmare.
Monotouch seems to have pulled this off somehow.
For some reason, the boss insists we do everything using xibs. :(
