使用 Git 管理 iOS 项目代码，大家用 Storyboard 还是手写界面代码？

我的代码是一个人写一个人管理。我不使用SB管理VC，而是每个VC单独建立对应XIB文件。 XIB中的view大部分还是使用IB来制作。 但是维护起来比一整个SB要方便些。

也想听听其他人是怎么做的。

storyboard

做iOS开发要顺应趋势 ios 5的ARC,storyborad, ios 6的autolayout ios 8的swift
都是趋势 早顺应早省心

xib

storyboard弄好就不怎么动了，至于打开就会产生代码变化没怎么遇到啊，而且不是可以discard changes么，storyboard还是挺方便的，可以看到整个应用的大部分逻辑，还可以用来放置配置好的对象，不然光是配置一些选项就好多代码，但是有些逻辑不能通过storyboard实现，必须用代码控制。

如果担心冲突的话可以使用多个 Storyboard，各管各的。最近两版的 Xcode 对 Storyboard 做了改进，不会只要打开就产生变更了。

值得注意的是，倘使你们俩在界面上的耦合度很高，用 Storyboard 可能会带来不少麻烦。

最后，题外话。虽然 Apple 一直在改进和扶正 NIB，但它的使用成本对我来说还是比代码来得高得多。

@krafttuc 能不能说说成本主要在哪里呢? 感觉 Apple 提倡的这一套也有大大提高效率的地方.

一直xib

我用xib

把storyboard拆分开来就好了呗，各自维护一套，iOS 8的size class适配不同设备还是相当便利的。

sb, 甚至有时候, 把已写的代码重新整成sb

当然是Storyboard，省了太多时间了，时间就是金钱，并且一眼看完所有界面总比凭名字找xib要快得多，大部分push几乎不用写代码，点点鼠标就能设置弹出效果

@damngood 一般印象中 Storyboard 拖拖拽拽，打打钩就能弄出一个像样的界面。它不用写多少代码，而且 auto-layout 和 size class 在这种场景下也可以轻易设置。在开始阶段似乎能让代码减少，况且这一切都是 __可视的__ 。这些优点很容易让开发者感到高兴从而使用它。

不过我不觉得在 IB 里拖拖拽拽，在各个 tab 里钩划所花的时间会比我去写代码来得少。Xcode 补全那么好用，写代码真的按不了多少次键盘。鼠标/触摸板还涉及到微操的说。你知道小屏幕的痛楚吗？

其次，debug 和维护成本我觉得 IB 是比代码高的。你有时为了某个界面上的奇葩错误找了半天，后来发现是因为在 IB 里手一抖不小心把某个选项给漏掉了。由于 NIB 文件不是 human readable（当然，现在有所改善），这些细微的变化在版本控制和代码审查时是不容易察觉的。这一点不如代码来得好。最后，有时候你发现有关某个 view 的东西在使用 IB 时被分散开来了。一方面你用 NIB 文件定义了一个 view，另一方面你可能还会在代码里做一些额外的设置（比如在IB里没法设置的属性，或者要动态地调整一些值）。要修改时，你需要检查从代码到NIB文件等多处位置来确保不出岔子。一旦要修改的东西很多，那么问题就会变得棘手。要知道 NIB 文件是不支持搜索的。

最后，互联网上、iOS 社区里关于这方面的论战每天都在发生。各种派别各有优劣，根据实际情况选个适合自己的就好了。

RubyMotion + RMQ + PixateFreeStyle

以前用StoryBoard还是比较多。。。确实AutoLayout起来也很方便。但是facebook的pop在AutoLayout下性能不好，最终还是直接用的代码写。

@krafttuc 恩, 看起来和我以前一直坚持用代码写界面理由差不多
1)scm 不太方便
2) 处理 View 的部分散在代码和 xib 里面, 个人总是偏向在一个地方把一个事情做好, 但是大部分 view 并不能在 xib 中设置好代码中就可以不管了

但是确实用 sb xib 等 apple 推荐的方法又确实能带来很多方便.
特别是上次论坛里有个朋友说过, 如果用完全用代码来做的话, 当你离职的后, 你工作的继任者会比较头疼. 所以最近我认真的在考虑是否要切换到 sb 的方式中

@damngood 切不切看成本啊。如果团队承受得起技术变更的时间消耗以及所带来的优势和缺陷，那就换。反之就继续用着。

我们直接用storyboard，三个人开发无压力，每个模块一个storyboard，storyboard偶尔会有冲突，那就改源码呗，反正这种界面也是用XML描述的