Mac 开发的神秘面纱：后娘养的嫡长子

本来，标题是「揭开 macOS 开发的神秘面纱」，可想想，以我目前对 macOS 开发的理解，还是去掉「揭开」二字吧 😂

本文不是系统性的文章，更像是 随笔。回想自己过去 1.6 年的 macOS 开发历程，挑些有意思的来说。如果想看完就去挖 macOS 这座金矿（如果是的话），你会失望的；且作佚事来读吧。

注：严格地说，应该叫作「macOS 开发」，因为去年起，苹果将 Mac 操作系统更名为 macOS；不过，苹果电脑依旧以 Mac 命名，如 MacBookPro，故而 Mac 开发也说得过去；再加上，以小写字母开头作为文章名，总觉得怪怪的，是以本文混用「Mac 开发」与「macOS 开发」

—– 长文开始警戒线；不喜请绕行 —–

0) Mac 是后娘养的嫡长子

说 Mac 是嫡长子，是因为 苹果就是做电脑起家的。虽说后来 iPod、iPhone 风生水起，但嫡长子的血统还是纯正的；而 iOS 正是基于 macOS 开发的。这里的故事很多，感兴趣可以读读《乔布斯传》之类的书或文章。

可惜的是，有了 iPhone 这棵摇钱树之后，Mac 电脑靠边站了，macOS 自然也被冷落，不到万不得已，不更新；即使更新，也像挤牙膏一样。

Mac 哪里被冷落了？多了去了。

比如，我每周都会收到一款苹果给开发者的邮件，本意是告知本周 App 的活跃程度。而我每次收到的邮件内容都是这样的：

因为我尚未上架 iOS 应用、只有 macOS App；而 在苹果看来，macOS App 岂能叫 App ？！是以，这里的数据是空的…

其它的，不胜枚举。

1) Mac 是个小市场

有多小？

先说说硬件，这是 2016 第四季度出货量对比：

设备	出货量	营收
Mac	537 万	72 亿美元
iPhone	7,830 万	543 亿美元

不论是出货量、还是营收，均是零头。

再来看看 App 的数量：

从 AppShopper 的数据来看，不足 3 万的 macOS App 数量，不到 iOS App 的 1%；对，是「百分之一」，零头的零头。

当然，这里主要统计的是上架 MAS (Mac App Store) 的应用，在 MAS 之外也有很多。不过，2 个数量级的差异，没跑。

现说说操作系统占比：

据 MarketShare 的数据，macOS 仅占 6.12%，仅有 Windows 用户的 6.7%.

其中，macOS 版本的分散程度，虽比 Windows 好很多，但也 不如 iOS:

看到这里，是不是觉得有些心凉，觉得 Mac 好可怜有没有…

不过，Mac 电脑确实是在慢慢增加的，知名度也在变高。比如，国内现代都市剧中出现的电脑，大多都是 Mac；苹果也刚刚宣布 全球 Mac 活跃用户有 1 亿。

2) Swift or Objective-C

我开发的应用 (Klib、iPic、iPic Mover、iPaste、iTimer、iHosts)，全部基于 Swift；不过，即使你也打算基于 Swift，还是建议对 Objective-C 有基本的了解。因为，毕竟 Objective-C 是苹果一直以来使用的开发语言，绝大多数的文档、教程，都是基于 Objective-C 的。

虽说可以很容易地改编为 Swift、或被 Swift 调用，但这就像是：你有一本英文词典，理论上就可以直接看英文文章，因为看见不懂的单词可以查嘛；但也知道，这不现实，毕竟你总不能每个单词都查吧？

所以：

• 如果你已经有 Objective-C 基础，就直接使用 Objective-C 开发 Mac 应用好了。要不要学 Swift？看你自己心情，我不提供建议；
• 如果你并没有 Objective-C 基础，建议你先学学 Objective-C 基础，然后再学 Swift，并基于 Swift 开发。

3) Mac 文档及教程

官方文档主要有这些：

• macOS 开发者中心
• API Reference
• Programming Guide
  • 主要是对具体知识点的详细介绍，如 Table View Programming Guide for Mac
• 历年 WWDC 视频
• Guides and Sample Code
  • 这里提供了一些示例项目。比如，想学某个控件的实际用法，可以到这里搜搜看。

实际上，由于我们一般是「面向 Google 编程」，一般遇到问题都是先搜索，不太需要记录这些网址。只是，如果你想系统性、深入地学习某个点时，可以正向地从官方文档入手。

不过，对于 苹果的开发文档，友情提醒：并不怎么好。如果套用这句话：
「为什么懂得这么多道理，却仍过不好这一生？」

便是：
「为什么我看了所有 Mac 文档，却仍无法开发 Mac 应用？」

文档更多是偏向对某个具体知识点的介绍，而如果想系统性地入门 macOS，最好是通过一本好的书，以及自己的练习。由于 iPhone 的热销，市面上 iOS 的书，可谓汗牛充栋。而 macOS 的书呢？呵呵。

我自己是看《Cocoa Programming for Mac OS X》这本书入门 macOS 开发的，这几乎是我在 2015 年能找到的唯一一本基于 Swift 的 macOS 开发教程。另外一本是 Swift Development with Cocoa，跟这本书没法比。

其他 macOS 的书，我看的不多，也没什么好推荐的。如果你有觉得哪本书不错，欢迎留言告诉我。

4) macOS 数据结构及持久化

首先要说的是，虽说是 macOS 开发，但实际上很多基础的东西都是通用的，比如 JSON 格式、MySQL 数据库等等。

另外，macOS 和 iOS 相比，像 TouchBar 这种独有的东西，并不多；更多的是通用的，或者说是并行的两套。

使用 plist 文件存储数据：

• 默认仅支持简单的数据结构；此方式仅适合保存少量数据，如偏好设置中的 On/Off 选项
• 可使用 UserDefaults 管理默认的 plist 文件。注意：沙盒模式和普通模式下默认的 plist 文件的位置不同
• 可在命令行中使用 defaults 命令来管理 plist 文件中的数据
• 可使用 Xcode 打开 plist 文件进行管理

序列化后存储：

• 对于自定义类型，适配 NSSecureCoding 协议后，可使用 NSKeyedArchiver 转换为 Data 格式
• 进而，可存储在普通文件中，也可存储于 plist 文件中

Core Data:

• Core Data 本质上是对数据访问方式的封装
• 对于简单的数据结构，使用 Core Data 会带来额外的复杂度，并不划算。对于复杂的应用，Core Data 可以显著减少代码量
• 持久化方面，Core Data 提供了对象-关系映射 (ORM) 的功能，不编写任何SQL语句，即可将数据保存在 SQLite 数据库文件中，也能还原到内存中

CloudKit:

• 存储方面，CloudKit 本质上类似于云端的关系数据库
• 除了存储，CloudKit 更有用的场景，是在多设备、macOS 与 iOS 间同步数据。比如，系统自带的 Notes 等应用，均是通过 CloudKit 来存储、同步数据。其中，通知机制可以最小化需要同步的数据量
• 再有，就是提供基于 CloudKit 的共享功能

注：数据持久化存储方式有非常多，也要视具体的需求而定；这里仅提及一些常用的方式。

5) macOS 界面开发

我们所说 macOS 开发，通常默认指开发「有界面及交互的、能运行在 macOS 上的应用」，其核心，就在于界面及交互。

我们也常听到 Cocoa，那 什么是 Cocoa 呢？援引《Cocoa Programming for OS X》中的介绍：

Cocoa is your application’s interface to the window server to receive events and draw to the screen. At the same time it has access to the Unix layer where it can make lower level calls.

也就是说，Cocoa 是这样一个中间环节：负责衔接你的应用与窗口系统，同时也可直接操作系统底层。

界面的开发，是个无底洞；可以是个简单的单窗口应用，也可以是 Pages、iMovie 这样复杂的应用。

对于初学者，建议从菜单栏程序入手。可以暂时绕开窗口、控件这些复杂的话题，又可以创建出能解决实际问题的一些应用。比如，iPic 主交互即位于菜单栏：

这部分，可参见我之前写的教程：Status Bar App 教程是 16 年 4 月写的，现在来看有些可能已经过时，比如当时是基于 Swift 2.2；不过整体还是可以参考的。

回到界面的开发。首先，要理解 App 的整体生命周期。尤其是 App 启动时，都做了哪些事、先后顺序及依赖是什么。

然后，实际的工作，就是搞定界面布局，以及熟悉一个个控件的用法，如 NSButton、NSTextField、NSTableView 等等。建议的学习步骤：

• 先随意玩玩，能让控件跑起来；一些控件复杂，跑不起来也不用觉得沮丧
• 如果官方有 Programming Guide，认真读一遍
• 如果官方有示例程序，学习之，熟悉正确的用法
• 过一遍 API Reference，了解控件所有的可能性和局限
• 解决自己实际的问题，真正用起来

我一般的开发步骤：

• 想清楚数据结构
• 堆 UI
• 完成业务逻辑

6) macOS 设计模式之解耦

随着程序变得复杂，代码变多，也很容易交织在一起。对于进一步开发和维护，是非常头痛的事。

怎么避免这样的情况呢？其中一个思路是：解耦。

抽象的说，就是 把复杂的东西拆成一个个独立的模块，然后通过一些方式让这些模式有机地组合在一起。

有哪些方式呢？顺着这个思路，我列出一些概念。

MVC模式 (Model-View-Controller)

• 这一模式在界面开发里大量使用，比如你经常看到的 XXViewController，就是其中的 Controller 部分
• 简单的说，就是 把界面与逻辑分离。界面部分，如布局、样式等。通常，代码量最多的，都是在 Controller 中。View 与 Controller 之间，通过引用、绑定来传递数据，即将数据显示在界面中、从界面读取用户产生的数据

Delegate

• 有两个角度来理解代理。以 NSWindowDelegate 为例，可理解为 Window 本身有丰富的可定制性，程序可选择性地实现某些功能、特性
• 另一个角度是，同样对于 NSWindowDelegate，对事件（如窗口即将关闭）的响应，Window 本身是不知道的，或者说是具体的业务相关的。Window 自己做不到，只能委托给自己的「代理」去决定。比如，当窗口即将关闭时，程序提示用户保存未保存的数据

Callback

• 对于非实时的操作，可以使用 Callback 回调的方式，来解耦调用者和执行者之间的等待
• 比如，程序在从网络下载图片时，可能需要 1ms，也可能需要 2s，程序总不能傻等着。于是，程序告诉下载的模块：我去忙别的事了，你下载好了告诉我。怎么告诉？就是通过 Callback 回调机制实现
• 与之关联的概念，如代码块

Notification

• 对于「如果…就…」这样的逻辑，比较适合的是通知机制
• 这里的通知，不止是从网络上推送下来的通知，也可以是程序内部的通知
• 比如，用户在偏好设置的界面中完成账户升级后，在程序内发出账户类型变更的通知；程序的主窗口之前注册以监听这一通知，便可根据账户类型实时调整界面

7) 发布 macOS 应用

自己辛苦开发的程序，通常是愿意让更多人来用的。如果能赚点小钱，当然更好啦。

7.0) macOS 应用签名

对于简单的程序，可以复制到别的电脑上运行，但最好还是要对程序进行签名。尤其是使用 CloudKit 等一些苹果特性的程序，必须签名。

怎么签名呢？前提是交钱。也就是，必须每年交给苹果 $99 的人头税，才能成为苹果开发者，进而给应用签名。

7.1) MAS 与沙盒模式

在 MAS (Mac App Store) 上提交的应用，必须运行在沙盒模式中。

沙盒模式有诸多限制，比如，默认不能访问用户的任何文件、一些接口无法使用等等。和 iOS 的沙盒模式相比，macOS 的沙盒模式还是宽松很多的。以访问文件的权限为例，应用可以申请访问如 Downloads 等指定目录。向谁申请呢？苹果，而不是用户。一旦通过（虽然并不容易），便可直接访问该目录，无需用户授权。

事实上，沙盒模式确实限制了程序的发挥空间，一些应用（如屏幕取词翻译、截图工具）干脆无法上架，或者额外开通「Accessibility」权限才能正常工作。而据说苹果已不再放行需要此权限的应用上架。

7.2) MAS 付费方式

苹果支持多种内购方式，要想通过应用收费，最简单的方式是：设置程序必须付费才能下载。这样，程序内无需区分免费版与高级版，无需做任何功能限制，代码简单。苹果系统保证了，使用哪个 Apple ID 下载的应用，只能在使用哪个 Apple ID 上登录的电脑上使用。比如，你自己购买了某个付费应用，直接把 .app 复制到朋友的电脑上，是无法运行的。

不过，这一方式也有局限：用户在付费之前，无法体验到产品的所有功能，也就很难决定是否要付费。对于这一局限，一些程序的做法时：在产品官网提供一个全功能、但仅能运行一段时间（如 7 天）的 体验版。这样，用户可以在体验所有功能后，决定是否购买。

再进一步，就是 免费版 + 内购的模式。用户可免费下载应用，但应用仅开放基础功能，需要内购才能使用高级功能。这样，既能最大化地获取用户，又能适时地收费，我的所有应用都采用此方式，相信也是未来一段时间的趋势。

对于内购，又分为一次性购买和订阅制。一次性购买容易理解；订阅制可以有按月、季度、年等不同周期。对于订阅制，又分为自动续订和手动续订。目前，苹果对于订阅制、尤其是自动续订的订阅制，审核较严。

另外，还有 消耗型内购，这种在游戏中较为常见，比如花钱买装备，或者为账户充值等。

对于内购的开发，还是比较繁琐的，比如要处理展示、购买、用户购买后退款、恢复、订阅续订、订阅未续订导致过期等等逻辑。好在，我封装了 IAPHelper，可以很方便地处理这些逻辑（如下代码为购买部分）；开源，可以 Pod 方式集成，已经在我的产品中应用多年，大家可放心使用。

 IAP.purchaseProduct(productIdentifier, handler: { (productIdentifier, error) in
	if let identifier = productIdentifier {
		// The product of 'productIdentifier' purchased.
	     
	} else if let error = error as? NSError {
      if error.code == SKError.Code.paymentCancelled.rawValue {
		// User cancelled
        
      } else {
		// Some error happened
      }
    }
})

7.3) 不完美的 MAS

之前苹果与微信怒怼的打赏分成事件，想必让更多朋友知道了：凡是应用从用户收到的钱，苹果均要收 30% 的拔毛费。

MAS 的诸多限制，以及不菲的拔毛费，让很多知名的 macOS App 纷纷下架，如 Sketch、Dash 等等。

不过，要在 MAS 之外发布，还是要做很多事情的，比如下载、支付、退款、激活码等等。对于小程序，还是挺繁琐的，并不划算。另外，毕竟 MAS 还能带来一些自然流量。

如果在 MAS 之外发布，还有一点需要注意：.app 程序本质上是一个文件夹。如果需要在网络上传送（如作为邮件的附件），最好是进行压缩，甚至是制作 .dmg 文件，我使用的是 create-dmg 这个小工具，非常方便，生成的样式也简单大方。

基于上面的原因，目前我的应用全部在 MAS 上发布，尚未在 MAS 之外发布。

尾巴

macOS 开发的话题还有非常多，比如 Storyboard、绑定、动画、并发、Undo、Pasteboard、Drag & Drop、本地化、单元测试等等，本文不可能全部提及。并且，写起来也好累，毕竟必须对这些点有完全的掌握，才可能写出来。暂且挖坑，以后再填。

对 macOS 开发感兴趣？欢迎留言交流。

---

原文：「自在开发」公众号