[TheRevoltingX]

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.

[mpakes]

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. :)

[wallflower]

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%.

[TheRevoltingX]

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.

[poutine]

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.