Я собираюсь разделить ваш вопрос на два: NIB и раскадровки.
Что касается NIB, проблемы с управлением источником могут быть болезненными, но управляемыми, главным образом потому, что у вас обычно есть один файл NIB для каждого контроллера представления. Вы можете представить себе ситуацию, когда у вас есть два разработчика, работающие над двумя различными разделами вашего приложения NIB без каких-либо проблем с объединением. Раскалы разные, так как у вас есть один файл, который описывает большинство (если не все) пользовательского интерфейса вашего приложения. Очевидно, что здесь существует гораздо больший потенциал для урегулирования конфликтов.
NIB могут быть чрезвычайно полезными и экономить время при правильном использовании. Вот пример: iPhoto App на iPad имеет очень сложный интерфейс. Подавляющее большинство этого пользовательского интерфейса представлено программно. Однако приложение также использует NIB для загрузки графических элементов, которые затем выкладываются в коде. Так работает панель кистей - все кисти создаются в NIB. Это означает, что Apple не должны иметь десятки идентичных изображений/изображений, выделяющих/инициализирующие фрагменты кода. Все создание может произойти в NIB (это было подробно обсуждено на сессии WWDC 2012 на iPhoto UI - это стоит того, чтобы отслеживать).
Таким образом, НИБ - иногда это хорошо, может сэкономить много времени, и в то время как являются проблемами слияния, которые они могут во многих случаях легко управлять и обрабатывать.
Затем мы приходим к раскадровки. Раскадровки интересны. С одной стороны, они чрезвычайно полезны и полезны для простых приложений и разработчиков, новых для платформы. Я только что конвертировал приложение с UINavigationController из NIB в раскадровки и обнаружил значительную экономию времени (особенно вокруг табличных представлений, поскольку с помощью раскадровки вы можете использовать прототипные ячейки).
Однако, если вы работаете над крупномасштабным проектом с несколькими разработчиками, я не уверен, что раскадровки - это выгодно. Есть, как вы говорите, большие проблемы с конфликтами слияния, и в отличие от NIB, решить их непросто, поскольку этот единственный файл раскадровки контролирует все вашего пользовательского интерфейса приложения.
Вот что я предлагаю (и не стесняйтесь игнорировать меня!) - если вы в настоящее время разрабатываете приложения и делаете свой макет/UI полностью в коде, подумайте, могут ли NIB сэкономить ваше время. Они могут не так - они не для всех, но это стоит, по крайней мере, рассмотреть. Вы можете быть удивлены тем, сколько больших приложений на самом деле используют NIB (iPhoto, как я уже упоминал, а также множество встроенных приложений, предоставляемых Apple, а также многие популярные сторонние приложения большими командами). Я, вероятно, не хотел бы рассмотреть раскадровки, если вы не были единственным разработчиком, работающим над приложением с довольно простой навигацией. Это никак не значит, что нужно делать раскадровки - я люблю их использовать - просто они не подходят для сотрудничества.
Кто отправил этот комментарий в ответ на ваш вопрос - я хотел бы обсудить это:
Там нет ничего, что вы можете сделать в раскадровке и не может сделать в коде. Объекты, жест распознования, перетекает, даже ограничения - все доступны для вас, чтобы построить программно
Это технически верно, но на самом деле есть вещи в раскадровке/NIBS, которые гораздо проще, чем код. Хорошим примером этого является автоматическая компоновка. Несмотря на то, что вы, безусловно, можете полностью управлять контурами автоматического макета в коде, суровая реальность заключается в том, что представление автоматической компоновки ASCII намного сложнее, чем визуальное представление, которое вы получаете в IB. Это , в особенности true на XCode 5, где есть значительные улучшения в автомаркете в IB (я не могу детализировать его слишком сильно, поскольку он все еще находится под NDA, но Apple публично говорит немного о changes here).
В раскадровке вы ничего не можете сделать и не можете делать в коде. Объекты, распознаватели жестов, segues, даже ограничения - все доступны для вас, чтобы создавать программно. – nemesis
@nemesis относительно segue, например, они не используются только в раскадровках? Я в основном использую '[self.navigationController pushViewController ...]' или просто 'presentViewController' –
Segues создаются намного проще в раскадровки (как и все остальное), но вы также можете создавать их программно. Лично я никогда этого не делал, но в документации [UIStoryboardSegue] (http://developer.apple.com/library/ios/#documentation/uikit/reference/UIStoryboardSegue_Class/Reference/Reference.html) говорится, что вы можете использовать 'initWithIdentifier: source: destination:' для создания segue. – nemesis