When developing for iOS on a team of several other iOS devs, the way you approach and architect the overall project should be different from the way you would personally build an app. Neither approach is “better code” but each method simply allows for time to be saved in each situation.
When developing an app on your own, it may be beneficial to use storyboards and .xib files in your project. The reason you want to avoid using these graphical files in a team setting is mostly version control. Since these graphical files automatically create large XML files that then compile into interface code, merge conflicts often occur when several people touch the same interface files. When you are working by yourself, since you will likely be the only person working on the file at one given point in time, merge conflicts should not occur. Additionally, writing all code for the interface may give more flexibility and allows for more customization of interface elements.
When creating the overall flow of the app and figuring out a good code organization pattern, be sure to make code as modular as possible in a team setting. Although this is always a good practice even when working on your own private project, it is essential when on a team. Over this past summer, while working at Path, I quickly learned the benefit of modular code. One of the other iOS engineers on the team and I were working on the same view, and we needed the ability to easily delegate tasks on the feature we were working on. Since we were not using Interface Builder, and making sure to use modular code, he worked on one aspect of the feature as a subview, while I built the rest of it. Since we were not sure how exactly we wanted to implement the UI, by creating a View Controller that looked for the same properties on a subview, we could easily test and swap out different implementations. This saved us a massive amount of time and allowed us to effectively accomplish tasks.
Andrew Rauh 