用了跨平台的方案开发App，自然享受不到苹果亲儿子XCode开发带来的便利。
比如打包发布等一系列的操作需要我们手工来操作了。
苹果的安全性与隐私中对于程序分成3类：
1、Mac App Store;
2、Mac App Store和被认可的开发者;
3、任何来源。
一般用户的设置都是1或2,选3的话安全性就很难保证了。
针对第1,2种的App, 苹果的证书对应分为2类，一个类Developer开头的开发者证书，一类是3rd开头的App Store发布证书。
如果不准备上架，或者使用了苹果的私有Api，那么就只能使用开发者证书给App签名了。
项目中用到了NSOutlineView,所以就在苹果的官网找了相关的Demo了解其具体的用法，代码下载链接：
SidebarDemo。
熟悉了代码后，依葫芦画瓢，顺利完成了自己的代码编写，可是运行后的效果，和demo中的效果竟然完全不一样，尝试了各种方式均不能解决。
通过比对NSOutlineView的每个属性，终于在一个不起眼的位置发现了一个重要的属性：Highlight。这个关键真的是有很大的误导性，要是取成Style什么的也不会让我纠结那么久了。
背景
一般的认识是这样子的：
1、当我们所写的程序里没用用Nib文件(XIB)时,用代码控制视图内容，需要调用initWithFrame去初始化1234567- (id)initWithFrame:(CGRect)frame{ if (self =[superinitWithFrame:frame]) { // 初始化代码 } return self;}
换了一台用来开发的Mac【就叫Mac A吧】，程序运行一切正常。
可是仔细一看，发现程序中某个界面的表格区域竟然默认显示了滚动条，很是奇怪。
因为我明明设置NSScrollView的属性是Automatically Hide Scroller，如图。正常情况下我鼠标放到表格区域才会出现滚动条的。
File’s Owner以及Objects在设计界面中的设置虽然大大地方便了程序开发，可以用更少的代码，实现复杂的功能。
但是对接触不久的开发者来说，会增加很多的迷惑性，学习成本相对高了。另一方面对于这些的理解和使用很多资料中也只是一笔带过。
File’s Owner
File’s Owner只是设计时的占位符，只有程序运行时，谁加载了此xib文件，谁才是其Owner。
可以在加载的代码initWithWindowNibName:Owenr:中指定其owner，也就成了运行时的File’s Owner。
在设计界面中File’s Owner的Custom Class可以随意指定，但指定的Class不符合outlet连接规则时，会有如下图的提示，
苹果基本上每年都会有一次大的系统升级，开发工具当然更需要提前一步。不过每次的更新换代，或多或少会带来很多诡异的问题。
我的项目原先是在Xcode6.4上的，很顺利的升级到了7.0，编译运行都很正常。
可是总是会在固定的代码位置自动停下来，和下了断点的效果是一样一样的。提示：Thread 1: breakpoint 3.1
情景重现：
难道是代码有异常？注释掉这回代码就正常了，但是@try @catch并没有捕获任何异常。
真的是奇了怪了。
整个项目clean后问题依旧，然后各种捣鼓……
搜了一圈有人指出是更新开发环境引起的症状，[%>_<%]，废了半天时间找代码问题，最后竟然是苹果的事情。
题记：任何一款优秀产品的背后都是一群为此呕心沥血的程序猿，前方多坑，注意避让！
注意事项
1、真机测试的时候最方便的应该是使用adhoc证书，这个是苹果推送的要求。
2、手表一定要戴在手腕上！手表一定要戴在手腕上！手表一定要戴在手腕上！重要的事情要说3遍。我曾傻傻地把手表放在桌上等通知，结果半天都没收到通知，通知全在手机上显示了。
3、手机需要处于“黑屏状态”，只要屏幕亮着，消息都会出现在手机上。
4、推送服务器的JSON Payloads格式一般需要重新调整。原先只有手机的时候alert只要有内容即可，现在需要分为title和body两部分了。如果要在手表中显示自定义通知样式，增加交互按钮，还需要定义category，value要和Watch中的Storyboard通知界面中的identifier一致，否则将显示苹果默认的通知样式，只有一个关闭按钮。
新结构如下：
{
“aps” : {
“alert” : {
“title” : “新通知”,
“body” : “OS X El Captain正式版今天推送……”,
},
“category”:”respond”,
“badge” : 5,
}
}
第一次在Mac中配置好了hexo,发布的时候却一直提示：Error: Permission denied (publickey). fatal: Could not read from remote repository.
分析这个错误提示大致可以推断出是公钥配置的问题引起的。
但是github中我已经配置好了当前的公钥信息了，再次检查公钥。
0、github中公钥重新配置了一遍
1、git clone可以正确执行。
2、ssh -T idealife@github.com
也提示：Hi defnngj You’ve successfully authenticated, but GitHub does not provide shell access.
说明配置的公钥没有问题。
就是在执行sudo hexo deploy的时候报公钥问题。
Github是一个神奇的网站，简直就是一个超级大的宝库，
接触越多就越能发现它的价值！
因此在这个平台上分享也是一件非常有意义的事情！
Leg’s go!
在CSDN断断续续经营了几年的博客最终还是会被现有的Github Pages所取代,虽然它的SEO已经做的非常不错了，但是这几年来的排版一直让我很痛苦。最近也增加了Markdown语法的支持，那也无法阻止我来到这片干净的乐土！