确切地说，我已经不记得真正的第一个“坑”是哪个了，但这不重要。当我创建了一个窗体后，首先想到的是把界面分成两个区域，左边是导航，右边是工作区。

于是我找到了NSSplitView，于是我试图把它拖到窗体上，结果失败了。这与我之前在window下直接拖控件的体验可不一样，与在水果家的Start Developing Mac Apps Today里拖控件的体验也不一样，虽然不明就里，但它终归是告诉我了视图跟控件不一样，不能直接拖到窗体上，不拖就不拖吧。后来才知道要自己新建一个视图控制器，继承NSSplitViewController就好了，然后再加到窗体的contentView中去，这里遇到2个小问题，或者叫“坑”。

一开始我是通过这两行代码把我自定义的视图加入到contentView中去的：

mainViewController.view.frame = window.contentView!.frame window.contentView!.addSubview(mainViewController.view)

然后就在我自定义的mainViewController中拖了一个NSSplitView到IB中的Custom View中，一切都很好，我得到了我想要的东西。

后来在这里我发现了不一样的东西，讲解非常详细，而且有我想要的其他控件或视图的用法，比如NSTableView，这个在以后会用到，而且我发现了它自定义的视图加入窗体的代码竟然是这样的做的：

window.contentView.addSubview(masterViewController.view) masterViewController.view.frame = (window.contentView as! NSView).bounds

我以为又学到新科技，但可惜的是这段代码无法通过我的xcode 6.4的编译。它提示我说从NSView?到NSView的downcast没法搞，那怪我咯？我也好奇的是，这篇文章还被翻译成了中文，被我搜到了。代码一模一样，唯一的区别是那个as!去掉了!，我好奇的是，难道他们都能编译通过？

bounds算不算坑呢？其实我现在还不是太清楚contentView的frame和bounds具体有什么区别，反正都是内容区域的大小范围之类的吧。上面的那个代码改成这样就可以编译通过了(为什么要加个!我不清楚，整体感觉就是不明觉厉吧):

masterViewController.view.frame = window.contentView!.bounds

后来又找到一个方式：

window.contentViewController = mainViewController

直接指定窗体的contentViewController即可，多简洁是不是，又少了一行代码，缩减50%代码量，真的很欢乐。

第二个所谓的“坑”一开始我都没发现。因为我在IB中拖NSSplitView到我的自定义控制器里时，我没觉得有什么不妥，用得好好的，outlet也很顺利，成功地把窗体划分成了2个区域。在若干天后我偶然发现，当我在代码里引用NSSplitView的第二个子view时竟然报错了。xcode提示我，mainViewController的splitview只有1个子视图，这不科学啊？明明左边一个，右边一个，怎么会只有一个？

经过一番“科研攻关”，终于明白了，在IB里，我看到的那个Custom View就是继承NSSplitViewController时默认生成的，跟在.Net里不一样的是，IB没有给默认设置2个子视图出来，splitter也没有——说实话，我到现在都没掌握这个黑科技：如何在IB中设置让俺的NSSplitView能够默认有两个sub view，可以把splitter拖来拖去玩。

虽然也不影响使用，但逻辑上不是我要的那个，我承认我有点强迫症——这是追求完美的意思么？于是我删除了拖上去的那个NSSplitView，改由代码实现给我自定义的NSSplitViewController添加另外一个子视图——嗯，用代码来写界面，逼格果然高些。

于是又带出了后面的“坑”，之后再碎碎念吧。

结束本文之前，说一些题外话：不少比我还小白的新人都想知道进入开发领域要注意什么问题，作为一个“过来人”，我觉得一切问题都不是问题，确实没有什么问题可以阻止你去做一件事，如果你真的很想的话。具体地说，我觉得唯一的问题就是Google要好使。所以，我很感谢我的小伙伴给了我一个代理，可以无障碍使用Google，科学无国界嘛。当然，我也可以自由看各种匪夷所思的新闻，看美帝人民如何水深火热，看资本主义如何走歪路邪路。再也不用别人在那指手画脚说：这个不能看，那个不能看，这个有毒，那个有害。我想，有选择权应该也算是自由的一种吧。