对于 ios 老手来说，漂亮的界面是用 storyboard 做吗？还是直接 coding？

[oukichi]

我在学 ios，油管上看了一些视频，有人用 storyboard，有人直接 coding 。 想问问老手，你们的漂亮界面是如何实现出来的？ 感谢回复。

漂亮的界面重点是界面，而不是漂亮，各位的热情我接收到了，但请不要跑偏了哈哈。

[JoJoJoJ]

漂不漂亮和 sb 还是 coding 有啥关系？

[hheng101]

都能做，大部分公司还是 coding 偏多

[xarthur]

是设计出来的……
还有不懂什么叫做直接 Coding，你是想说 Swift UI 吗？

[oukichi]

@hheng101 感谢！

[oukichi]

@JoJoJoJ 请仔细审题

[oukichi]

@xarthur 直接 coding 的意思是直接在 controller 里面调用相关的类并直接设置属性来实现界面。

[typetraits]

个人感觉 coding 比较好，storyboard 还得拖拽，太麻烦了；而 coding 我这一行写下去，UI 什么样我心里已经大概有数了

[oukichi]

@typetraits 就像我们写 CSS 。我理解了。感谢大哥！

[360511404]

老手是融会贯通的,不会告诉你 storyboard 还是 coding
两者各有优劣
storyboard 本质也是 xml 文件,而且编译出来载入内存更快,苹果也用,还是提倡的方式
用 coding 为了多人开发避免冲突
你可以习惯一种,但两种方式都要会用

[linhongye]

storyboard 已经没有后续支持了吧。 现在是 swiftui 了。教程看旧了？

[nieyujiang]

storyboard 自己玩挺爽的.多人协作,就很酸爽.

[nicevar]

storyboard 的本意是让 UI 设计师来做这一块，但是绝大多数情况都是让程序员来完成，所以它用起来真的不怎么样，很多公司都是 storyboard 还没出现的时候就在做 iOS 项目，对程序员来说跟 nib 没太大区别，如果连 nib 都不用 storyboard 也不会用了。

[Lin0936]

刚开始是 coding，然后用 storyboard，现在又回到了 coding 不过是用 snapkit

[iOCZ]

这个不是重点

[irytu]

关键看 design 水平 跟代码没啥关系

[oukichi]

@linhongye 因为我一直不喜欢声明式开发，所以我从 swift ui 回退到了你说的“旧的”那种开发。MVC 那种。其实我写前端也不喜欢 react，更喜欢 angular 。于是……就是你说的，教程看旧了。

[oukichi]

@Lin0936 你可太优秀了，幸好你回复了，让我知道了 snapKit 这个好东西，还有啥常用的吗？求推荐！

[Leonard]

好不好看是看设计，不过我个人不喜欢用 storyboard，coding 感觉更自在一些。oc 用 masonry，swift 用 snapkit 。swiftUI 还没怎么用。

[chiaf]

@oukichi 推荐一个 pinlayout，据说比 autolayout 性能高

[ooops]

界面漂不漂亮看 UI 设计，sb 和代码都能实现，没啥本质区别。你是想问大家都用哪种来实现？

[ciki]

swiftui 可以做出非常炫酷的 UI

[C603H6r18Q1mSP9N]

如果不知道就选择直接 coding 吧

[4074]

开始学的时候，也是跟着官方教程用 storyboard，拖来拖去很麻烦，还要在代码里进行关联。
后面全换成 coding 了，不追求极致性能的话，coding 方便很多。

[Lin0936]

@oukichi 主要还是看 UI/UX 设计吧，硬要说画 UI 常用的话还有个 RxSwift 吧，还有偶尔用 lottie 显示些动画。

[no1xsyzy]

@JoJoJoJ 我怀疑这里的「漂亮的界面」跟见人就喊「美女」「帅哥」差不多

[catfan]

Storyboard 的重要特性是能比较直观且无需编译的情况下看到界面在不同设备、不同布局、不同语言、不同转向、不同界面模式（默认 /黑暗）下的大致样式，方便进行适配和预览。

如果单纯手写界面，这部分的适配代码是非常复杂并且很难全部兼顾的，并且每次调整都需要编译后才能看到效果，开发效率可想而知。

而且 Storyboard 可以帮助理清整个应用各个界面之间的逻辑，一些界面之间的跳转只需设定好就能无需编写代码就能很好地运作。

简单来来说，Storyboard 可以大幅减少项目中那些界面设定、适配、跳转等的代码，从而让开发者更专注于应用逻辑的处理。

当然，无论哪种方式，对于复杂的界面以及动画效果，还是需要手动编写的。

[WildCat]

可以考虑纯 Code + https://nshipster.com/swiftui-previews/

[wupher]

大部分公司开发，都使用 coding 。storyboard 多个开发时那个配置文件有修改冲突问题。

Apple App 大多使用 storyborad

个人开发者看习惯了，用 storyboard 的也不少，因为出活快，也没有协同开发的问题。

[lujie2012]

? 老手回答，漂亮的界面是 UI 小姐姐做出来的，不是开发同学做出来的。
所以 coding 还是 storyboard 和 APP 的漂亮界面，动画效果没有任何关系，两者底层是用的一样的东西。两者都可以做出一摸摸一样的东西。
差别在哪里？差别很大。
新手怎么弄，新手 storyboard 先玩好吧，简单一点，之后你想办法吧 storybaord 的那个项目变成存代码的项目就是了。

拿来吃饭，什么都要懂的。拿来自己玩，storyboard 你能玩好了，什么 APP 你也都能自己做。

[imkerberos]

masonry + snapkit < pinlayout + flexlayout

[Elethom]

好不好看和用什么没关系，不过用 SB 的多半是不打算维护了。

[gggxxxx]

那么多贬低 storyboard 的。。。。真是搞笑。
几十年前计算机技术就在提所见即所得......那么多人捧纯 coding 图个啥？

[mxalbert1996]

@gggxxxx 因为 StoryBoard 的多人协作和版本控制做的实在是太烂了，你看有人问 Android UI 开发用 xml 还是纯代码么？

[iOCZ]

sb 的问题是不适合代码敲，xml 可以。sb 的源码很复杂。

[Cbdy]

漂不漂亮不是看设计师吗？

[Esioner]

原来 Android，最近在看 iOS 的感觉还是 coding 写起来舒服点，storyboard 用起来卡卡的，而且写起来说不出来的不习惯，哈哈哈

[Eagleyes]

@wupher Apple App 就没有冲突问题么？

难道说 Apple App 都是一个人开发的？

[cornetCat]

sb 还是小项目用着舒服，大点的项目感觉不如纯 code 。复用也不够方便

[oukichi]

@chiaf 我昨天看了 pinlayout 的文档，针不戳！

[Building]

@gggxxxx 用 code 基本上写的时候脑子里就知道最终的大概效果了，就好像熟练的前端看到设计图脑子里自动就能翻译成 html 结构和 css 样式，所见即所得根本多此一举，就是给在行人看的，Storyboard 优势是场景，纯 UI 声明是 nib 文件，就是类 xml 一样的东西，如果只是简单的几个页面跳转用 Storyboard 就显得非常直观，Storyboard 这东西实际上和 UI 就没多大瓜葛。

[wupher]

@Eagleyes 这个我真不故道。不过，以前有人通过反向工程分析了 N 多个 App 的实现方式，就是为了解答你这个问题。你可以上网搜索一番。Apple App 其实两者都有，但 stroryboard 居多，有的还接近 100+ view 。

Coding 也是有很多好处的，尤其是复用和拷贝代码。

布局哪个更方便就是见仁见智了。

[Eagleyes]

@wupher 那为什么 Apple 多人开发就用 stroryboard 就不会出现混乱的问题？

是 Apple 有什么私有的解决办法还是大家开发的姿势不对？

[wupher]

@Eagleyes 这个我也不知道，你可以在 WWDC 上询问一下。

我觉得其实更多的是开发习惯问题。coding 可能没有可视化那么方便，尤其在调参时的直观和方便。但是维护，分享，复用肯定强于 xib / storyboard 。

[Eagleyes]

@wupher 我是觉得一个方法，尤其是吹的特别好的方法，语言，比如 Swift，Storyboard，如果官方自己都不用，（假如说 apple 仍然用 oc 来开发）那么可以断定这个新的东西就是个噱头，自己都不看好。

反之，如果官方自己用的乐此不疲，那么大概率有前途

[phytry]

漂不漂亮是设计做的，开发只是实现而已。sb 相比 coding 更直观，而且做复杂页面的时候没那么难受，coding 主要是可控和复用性高。

[wiwby]

这都 21 年了，还以为是 11 年吗，玩不转就是菜，还大把人觉得性能和协作不行，代码烂，设计能力差，用啥方式维护成本和复用性都挫

这玩意儿能满足 98%的需求，节约 50%的时间，唯一的缺点就是学习成本大点，经验性要求高点

[CodingIran]

@wiwby IB

“玩不转就是菜”——大部分情况不是用 IB 不是因为“不会”，而是“不愿意”，做好 code snippet 和封装，纯代码效率不会比 IB 差很多。但纯代码配合 frame 布局的性能却比 IB 高很多（尤其在 iOS12 以下的设备）；另外纯代码对于控件封装和复用也比 IB 更有优势。你可以选择自己喜欢的 coding 方式，但不要轻易下“就是菜”的结论。

“学习成本大？——难道不是纯代码的学习成本才大吗：使用 IB 通常可以忽略视图的生命周期，我认识很多 3.4 年经验的 iOS，连 sizeToFit, sizeThatFits:, layoutSubviews, intrinsicContentSize, didMoveToWindow, didMoveToSuperview.. 这些基本的方法都不懂正确的使用。
一看到设计稿不思考着如何“优化性能”、“如何封装以方便复用”，而是直接打开 storyborad 或 xib 开始拖控件的话很难提高的。

[wiwby]

@CodingIran 你说这些和 IB 没啥关系，你要追求极限的布局性能，那就原始 frame，连框架都不要用，菜的人用啥都一样烂，支持 IB 的都能封装，纯代码封装好骗骗小白阔以，你认识的三四年经验的可能是三四年 UI 工程师，不是合格的编码人员，任何科技手段只是工具，最重要的是人，设计这玩意儿是建筑上沿用出来的，有能力的人都是从设计着手，能力不行用啥都是一坨翔。

[jackiecao]

@oukichi 你的标题就是这个意思啊