冲动的惩罚

自从有那段使用beta版本的Mac OSX系统，导致机器时常开机卡死的经历之后，就尽量不敢在第一时间使用苹果的beta版系统。但是，由于自己是名iOS开发者，当Xcode出了beta版本无疑是需要第一时间体验一下的，即使Xcode beta版本可以不体验，但是出了第一个Release版本却是不得不更新。接下来讲的就是在使用Xcode8.0所遇到的坑。

坑与填平坑

Storyboard

对于Storyboard相信大家对它都不陌生，自从iOS5之后就开始支持了，是一种可视化开发组件。本人使用过Android、Windows Phone以及iOS的可视化组件，可以说Storyboard是这三个平台中最流畅、最好用的可视化开发组件，采用StoryBoard虽然会比纯代码写UI效率上会有那么一点损耗，但对于一般的应用，在开发之初它确实可以大大的提高开发效率、也易于维护（可以想想当年那些不采用Storyboard编写的代码，即使更改一个坐标位置都是极其痛苦的），可以说是利大于弊。但是就在最近升级到Xcode8之后，发现StoryBoard有如下几点变动（坑）。

所有UI控件的宽高设定了同一个初始值：1000。

在Xcode7的时候，StoryBoard生成的UI控件的默认宽高都是3.5英寸的宽高。采用自动布局时，在load完Storyboard之后，读取到UI控件的宽虽然不正确，但是大部分情况下高却是我们想要的，并且由于宽是320，是小于等于任何尺寸的宽，所以在UI渲染上并没有可见性的问题。
但是对于Xcode8则不同，只要是通过Storyboard生成的UI都是统一给定一个固定值：1000。在load完Storyboard之后，自动布局计算完高度之前，读出来的宽高都是1000。这就导致原先所有依赖于bounds计算位置宽高，没有任何问题的UI展示逻辑，采用Xcode8一编译就乱套了，比如会看到：图片无故拉长后再恢复原状，原先好好的布局出现了UI重叠在一起，有的UI甚至刷新不出来等。解决的办法主要有两个：

将Storyboar的打开方式选择xcode7.x（在右侧Show the file inspector->interface Builder Document->open in）。但这么做的缺点是：当你再次打开Storyboard，Xcode又帮你自动选中打开方式为Xcode8.0。而且为了以后着想，还是采用下面这种方式吧。
在代码要使用UI宽高做些计算之前，调用一下layoutIfNeeded。这样就能获得在Storyboard设计的宽高（当使用4.0英寸来设计获得就是在4.0英寸下的宽高，采用的是3.0英寸来设计获得的就是3.0英寸的宽高）。

cornerRadius

本人在开发过程中还遇到了这么一个问题：明明之前显示得好好的控件，为什么采用Xcode8编译之后，就消失不见了呢？并且采用Capture view Hierarchy工具查看又能看见这个控件，但是在模拟器或者真机上就是死活渲染不出来。经过各种调试最后发现是因为cornerRadius设置了一个比自己宽高还大的值（类似bounds.size.width / 2这样的逻辑，由于默认宽高为1000，因此计算出来的cornerRadius就是500了，比我的控件的宽高都大），导致了控件渲染不出来。这种情况采用上面的第二种方法，在使用bounds之前layoutIfNeeded一下，就基本跟以前一样了。

TableView static cells

当采用Taleview的的静态cell之后，如果header的高度是动态变化的，不管你如何reload data，底下的cell的frame都不会发生改变，除非你自己手动设置目标cell的frame。

不支持iOS7，却可以提交iOS7应用

Xcode8之后就不支持iOS7设备的调试了，但是Apptore却可以提交iOS7系统的应用。当在iOS7设备上遇到bug的时候，调试就成了困难。你不得不再下载一个xcode7来进行iOS7的调试，并且前提是你没有升级macOS为10.12，否则你连xcode7都打不开，更谈不上调试了。虽然现在确实iOS7的用户量很少，可对于一个步入正轨的app，只能是慢慢的放弃。开发工具虽不支持调试，但却可以提交Appstore，这对于开发者来说，对老板，用户都不好交代。既然想要放弃iOS7，为啥不干脆整个入口都封死呢？