其实官方还是宣扬了一些优点的，其中最显著的莫过于可以上架 mac app store，但这点优点实在是无法弥补他的弱鸡。他能做的事情几句话就可以说完，开发一个这样的插件是极其的简单。简单说吧，一个插件能做下面的事情：
获取 xcode 正在编辑的文本
获取所有的选中区域
替换 xcode 正在编辑的文本
选中 xcode 正在编辑的文本
在 xcode 的 editor 菜单里面给你的插件生成一个子菜单，用于调用插件
可以在 xcode 的 key binding 里面给插件分配一个快捷键
没了，这就是他全部能做的事情，下面我通过一个选中文字转换成 base64 编码的例子来简单介绍一下。
你需要在一个现有的或者新建的 macos 项目里面新建一个 xcode source editor extension target，然后理论上这个时候已经可以有插件的效果了，但是今天我试了很多次就是不行，其实没有什么特别的原因，就是因为 xcode 目前的阶段极其不稳定，我没写错任何东西。
有几个核心的观念要介绍一下，首先，实现了 xcsourceeditorextension 接口的类，用于管理插件的生命周期或者对 command 进行动态配置，说的很牛逼其实一共两个方法。
分别是在插件成功加载后调用和动态配置 command，但是 command 也可以静态的配置在插件的 plist 上面，我的例子里面其实就是这么一个结构：
没什么好解释的，指定了实现类的名称和菜单的名称。
xcsourceeditorcommand 是另外一个核心概念，其实就是当插件被触发之后，你有机会在代理方法里面拦截到这个消息（xcsourceeditorcommandinvocation），做出处理之后将内容返回给 xcode，仅此而已。
xcsourceeditorcommandinvocation 里面会存放一些 meta 数据，其中最重要的是 identifier 和 buffer，identifier 就是用来做区分的，buffer 则是整个插件中最最重要的概念，但是他其实也很简单。
xcsourcetextbuffer 最重要的环节有两个，
在菜单或快捷键触发插件
xcsourceeditorcommand 拦截了消息
从 invocation 中拿到 buffer
在 buffer 中根据当前行，获取到你要的数据
把数据替换后塞回去
所以这个 base64 的例子，最后就只有这么几行代码（只处理一行文本的情况下）
最后把插件编译运行到 xcode 8 beta 上面，会出现一个被调试的 xcode，是黑色的：
然后随便选个项目跑起来，菜单里面就有了插件了
我说的轻巧，其实现实中（目前 beta1），出现菜单的概率非常的低，这让我非常恼火。
当然这个插件开发模式的确能拿来做一些事情，比如代码的格式化，或者是编解码，总之都集中在 文本的处理体验上面。但他的局限性也是非常的明显，例如：
没有 ui 相关的接口，纯粹只能做文本处理
没办法直接绑定快捷键，还得到 xcode 的设置里面去设置
就目前而言，调试的成功率实在是太低了，很郁闷
只能通过菜单或快捷键调用
只能处理编辑区域
这些和第三方的 xcode 插件比起来要差的很远，不过这还算是一个不错的开端，希望在日后可以把更多的接口开放出来，让 xcode 这个本来就让人恼火的东西变得更好用。