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