4 ms·
> The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React) Anecdote: I’ve worked
by Aqua_Geek 8y ago
> The only reason to not use it, is because some of those Apps are built with third party multi-platform frameworks and not UIKit (React)
Anecdote: I’ve worked on a few large iOS teams at well-known companies. At all of them, we have moved toward building UI in code and specifically banning the use of XIBs and Storyboards (we still use all of Apple’s frameworks — e.g. UIKit). Part of the reason is merge conflicts — in much the same way that merging Xcode project files requires every engineer to understand and be able to parse the syntax when looking at a diff, merging changes in XIBs and Storyboards is fraught with danger (at best).
- bunnycorn 8y agoWe don't have that problem, we have CI with UI tests.
- mpweiher 8y agoWow, your CI automagically fixes merge conflicts?
- jchb 8y agoWe use storyboards and xibs extensively for a pretty large app (50+ unique view controllers, hundreds of use-cases). Although I grant that our team size is pretty small (< 10). But even with a much larger organisation, I would expect different teams to be assigned to different features, so there shouldn't be more UI-related merge conflicts. Interface builder is very useful for previewing constraints with different size classes and device models, and also for previewing localisations (app localized to 20+ languages). With some exceptions, we only have a single view controller in a storyboard file. This, and managing UI tasks so that just one or two developers work in the same part of the UI makes us have very few xib and storyboard merge conflicts.