本来，标题是「揭开 macOS 开发的神秘面纱」，可想想，以我目前对 macOS 开发的理解，还是去掉「揭开」二字吧 😂。
本文不是系统性的文章，更像是 随笔。回想自己过去 1.6 年的 macOS 开发历程，挑些有意思的来说。如果想看完就去挖 macOS 这座金矿（如果是的话），你会失望的；且作佚事来读吧。
注：严格地说，应该叫作「macOS 开发」，因为去年起，苹果将 Mac 操作系统更名为 macOS；不过，苹果电脑依旧以 Mac 命名，如 MacBookPro，故而 Mac 开发也说得过去；再加上，以小写字母开头作为文章名，总觉得怪怪的，是以本文混用「Mac 开发」与「macOS 开发」。
说 Mac 是嫡长子，是因为 苹果就是做电脑起家的。虽说后来 iPod、iPhone 风生水起，但嫡长子的血统还是纯正的；而 iOS 正是基于 macOS 开发的。这里的故事很多，感兴趣可以读读《乔布斯传》之类的书或文章。
可惜的是，有了 iPhone 这棵摇钱树之后，Mac 电脑靠边站了，macOS 自然也被冷落，不到万不得已，不更新；即使更新，也像挤牙膏一样。
Mac 哪里被冷落了？多了去了。
比如，我每周都会收到一款苹果给开发者的邮件，本意是告知本周 App 的活跃程度。而我每次收到的邮件内容都是这样的：
因为我尚未上架 iOS 应用、只有 macOS App；而 在苹果看来，macOS App 岂能叫 App ？！是以，这里的数据是空的……
其它的，不胜枚举。
有多小？
先说说硬件，这是 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 亿。
我开发的应用 (Klib、iPic、iPic Mover、iPaste、iTimer、iHosts)，全部基于 Swift；不过，即使你也打算基于 Swift，还是建议对 Objective-C 有基本的了解。因为，毕竟 Objective-C 是苹果一直以来使用的开发语言，绝大多数的文档、教程，都是基于 Objective-C 的。
虽说可以很容易地改编为 Swift、或被 Swift 调用，但这就像是：你有一本英文词典，理论上就可以直接看英文文章，因为看见不懂的单词可以查嘛；但也知道，这不现实，毕竟你总不能每个单词都查吧？
所以：
官方文档主要有这些：
实际上，由于我们一般是「面向 Google 编程」，一般遇到问题都是先搜索，不太需要记录这些网址。只是，如果你想系统性、深入地学习某个点时，可以正向地从官方文档入手。
不过，对于 苹果的开发文档，友情提醒：并不怎么好。如果套用这句话：「为什么懂得这么多道理，却仍过不好这一生？」
便是：「为什么我看了所有 Mac 文档，却仍无法开发 Mac 应用？」
文档更多是偏向对某个具体知识点的介绍，而如果想系统性地入门 macOS，最好是通过一本好的书，以及自己的练习。由于 iPhone 的热销，市面上 iOS 的书，可谓汗牛充栋。而 macOS 的书呢？呵呵。
我自己是看《Cocoa Programming for Mac OS X》这本书入门 macOS 开发的，这几乎是我在 2015 年能找到的唯一一本基于 Swift 的 macOS 开发教程。另外一本是 Swift Development with Cocoa，跟这本书没法比。
其他 macOS 的书，我看的不多，也没什么好推荐的。如果你有觉得哪本书不错，欢迎留言告诉我。
首先要说的是，虽说是 macOS 开发，但实际上很多基础的东西都是通用的，比如 JSON 格式、MySQL 数据库等等。
另外，macOS 和 iOS 相比，像 TouchBar 这种独有的东西，并不多；更多的是通用的，或者说是并行的两套。
使用 plist 文件存储数据：
UserDefaults 管理默认的 plist 文件。注意：沙盒模式和普通模式下默认的 plist 文件的位置不同defaults 命令来管理 plist 文件中的数据序列化后存储：
NSSecureCoding 协议后，可使用 NSKeyedArchiver 转换为 Data 格式Core Data:
CloudKit:
注：数据持久化存储方式有非常多，也要视具体的需求而定；这里仅提及一些常用的方式。
我们所说 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 等等。建议的学习步骤：
我一般的开发步骤：
随着程序变得复杂，代码变多，也很容易交织在一起。对于进一步开发和维护，是非常头痛的事。
怎么避免这样的情况呢？其中一个思路是：解耦。
抽象的说，就是 把复杂的东西拆成一个个独立的模块，然后通过一些方式让这些模式有机地组合在一起。
有哪些方式呢？顺着这个思路，我列出一些概念。
MVC模式 (Model-View-Controller)
Delegate
Callback
Notification
自己辛苦开发的程序，通常是愿意让更多人来用的。如果能赚点小钱，当然更好啦。
对于简单的程序，可以复制到别的电脑上运行，但最好还是要对程序进行签名。尤其是使用 CloudKit 等一些苹果特性的程序，必须签名。
怎么签名呢？前提是交钱。也就是，必须每年交给苹果 $99 的人头税，才能成为苹果开发者，进而给应用签名。
在 MAS (Mac App Store) 上提交的应用，必须运行在沙盒模式中。
沙盒模式有诸多限制，比如，默认不能访问用户的任何文件、一些接口无法使用等等。和 iOS 的沙盒模式相比，macOS 的沙盒模式还是宽松很多的。以访问文件的权限为例，应用可以申请访问如 Downloads 等指定目录。向谁申请呢？苹果，而不是用户。一旦通过（虽然并不容易），便可直接访问该目录，无需用户授权。
事实上，沙盒模式确实限制了程序的发挥空间，一些应用（如屏幕取词翻译、截图工具）干脆无法上架，或者额外开通「Accessibility」权限才能正常工作。而据说苹果已不再放行需要此权限的应用上架。
苹果支持多种内购方式，要想通过应用收费，最简单的方式是：设置程序必须付费才能下载。这样，程序内无需区分免费版与高级版，无需做任何功能限制，代码简单。苹果系统保证了，使用哪个 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
}
}
})
之前苹果与微信怒怼的打赏分成事件，想必让更多朋友知道了：凡是应用从用户收到的钱中，苹果均要收 30% 的拔毛费。
MAS 的诸多限制，以及不菲的拔毛费，让很多知名的 macOS App 纷纷下架，如 Sketch、Dash 等等。
不过，要在 MAS 之外发布，还是要做很多事情的，比如下载、支付、退款、激活码等等。对于小程序，还是挺繁琐的，并不划算。另外，毕竟 MAS 还能带来一些自然流量。
如果在 MAS 之外发布，还有一点需要注意：.app 程序本质上是一个文件夹。如果需要在网络上传送（如作为邮件的附件），最好是进行压缩，甚至是制作 .dmg 文件，我使用的是 create-dmg 这个小工具，非常方便，生成的样式也简单大方。
基于上面的原因，目前我的应用全部在 MAS 上发布，尚未在 MAS 之外发布。
macOS 开发的话题还有非常多，比如 Storyboard、绑定、动画、并发、Undo、Pasteboard、Drag & Drop、本地化、单元测试等等，本文不可能全部提及。并且，写起来也好累，毕竟必须对这些点有完全的掌握，才可能写出来。暂时先挖坑放着，以后再填。
对 macOS 开发感兴趣？欢迎留言交流。
原文：「自在开发」公众号 (ID: IndieDev)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。