其实理解一点逻辑后，没有想象的那么乱。

iPad 目前有四条产品线：iPad Pro 、iPad Air 、iPad mini 、iPad.

如果仅看每条线最新的产品，它们的区别是：

- 仅有 iPad Pro 有高刷（ ProMotion ）
- 仅有 iPad Pro 有两种尺寸（ 11/12.9 ），其他都只有一个尺寸
- 仅有 iPad Pro 有四扬声器
- 仅有 12.9 寸 iPad Pro 有 Mini-LED 屏幕
- 仅有不带后缀的 iPad 用 Lightning 接口，其他都是 USB-C ，也仅有它还有 Home 键
- iPad Pro 和 iPad Air 用 M1 芯片，iPad mini 用 A15 ，iPad 用 A13

如果不看最新款产品，那 iPad 变迁历史确实比 iPhone 复杂一点。因为 iPhone 无论是某代的 Pro Max 还是 mini ，它们都是同时发布的，除了 SE （所以叫 Special Edtion ）；而 iPad 每个产品线是独立的，iPad Pro 更新不代表 iPad mini 也要更新。

iPad Pro 一共有五代：

- 第一代发布于 2015 年，A9X ，有 12.9 和 9.7 两个尺寸
- 第二代发布于 2017 年，A10X ，有 12.9 和 10.5 两个尺寸，此代加入高刷
- 第三代发布于 2018 年，A12X ，有 12.9 和 11 两个尺寸，使用全面屏设计、Face ID 和 USB-C
- 第四代发布于 2020 年，A12Z ，有 12.9 和 11 两个尺寸，加入了激光雷达和超广角镜头，内存从 4G 升级至 6G
- 第五代发布于 2021 年，M1 ，有 12.9 和 11 两个尺寸，接口支持雷雳协议，蜂窝支持 5G ，12.9 寸使用 Mini-LED 屏幕，内存为 8G 或 16G

iPad Air 也有五代：

- 第一代发布于 2013 年，A7 ，9.7 寸
- 第二代发布于 2014 年，A8X ，9.7 寸
- 第三代发布于 2019 年，A12 ，10.5 寸，内存 3G ，开始支持 Apple Pencil 和 Smart keyboard
- 第四代发布于 2020 年，A14 ，10.9 寸，使用全面屏设计和 USB-C ，没有 Face ID ，而是在电源键上使用 Touch ID ，内存 4G
- 第五代发布于 2022 年，M1 ，10.9 寸，内存 8G

iPad mini 有六代：

- 第一代发布于 2012 年，A5 ，7.9 寸
- 第二代发布于 2013 年，A7 ，7.9 寸，内存 1G
- 第三代发布于 2014 年，A7 ，7.9 寸，加入了 Touch ID
- 第四代发布于 2015 年，A8 ，7.9 寸，内存 2G
- 第五代发布于 2019 年，A12 ，7.9 寸，内存 3G ，开始支持 Apple Pencil
- 第六代发布于 2021 年，A15 ，8.3 寸，内存 4G ，开始使用全面屏设计和 USB-C ，以及电源键 Touch ID

目前不带后缀的 iPad 是初代 iPad 的后继，共有九代：

- 第一代发布于 2010 年，A4 ，9.7 寸
- 第二代发布于 2011 年，A5 ，9.7 寸
- 第三代发布于 2012 年，A5X ，9.7 寸
- 第四代发布于 2012 年，A6X ，9.7 寸
- 第五代发布于 2017 年，A9 ，9.7 寸
- 第六代发布于 2018 年，A10 ，9.7 寸，2G 内存，开始支持 Apple Pencil
- 第七代发布于 2019 年，A10 ，10.2 寸，3G 内存，开始支持 Smart keyboard
- 第八代发布于 2020 年，A12 ，10.2 寸，3G 内存
- 第九代发布于 2021 年，A13 ，10.2 寸，3G 内存

配件方面：

- 使用 USB-C 的 iPad 都支持第二代 Apple Pencil ，非全面屏的 iPad Pro 和上述提到的版本支持第一代 Apple Pencil
- Smart keyboard 中文叫「智能式键盘双面夹」，和妙控键盘不是一个东西，iPad Pro 也是一直支持
- 虽然妙控键盘发布于 2020 年，但第三代 iPad Pro 也支持妙控键盘，全面屏的 iPad Air 也可以用

购买建议：

- 决定 iPhone 和 iPad 寿命的因素就是内存，决定能否在未来获得新功能的因素是芯片，所以为了用得久一点，最少也要 A12 以上的机器
- 第六代 iPad mini 有「果冻屏」现象，建议去实体店感受以后再决定是否购买
- 即使不用新功能，从内存角度来说，iPad Pro 和 Air 都建议 M1 版本
- 不带后缀的 iPad 使用的是「非全贴合屏幕」，建议去实体店和 iPad Air 或 Pro 进行对比

作为参考，iPadOS 16 支持的硬件：

- 所有 iPad Pro
- 第三代及更新 iPad Air
- 第五代及更新 iPad
- 第五代及更新 iPad mini

醒醒，为了摄像头他们甚至能干出给笔记本加刘海这种天怒人怨突破底线的事，怎么可能再把它去掉？

iPhone 的「最近项目」和「所有照片」不也有这个区别吗

我遇到过更蠢的问题：系统短信把国内的手机号码（ 1 开头共 11 位）认成了带区号的美国号码（ 1 是区号，号码 10 位），系统地区是中国大陆。这个 Bug 在 iOS 13 时代通过分享菜单稳定复现，现在较小概率还会出现。

《战国无双》无限城模式

首先，拿 Java/Kotlin 或者 Objective-C/Swift 这类语言互转来说明复杂程度不合理，因为它们在设计阶段的要点就是和前代语言充分兼容。这里是 Swift 社区关于实现和 C++互操作的设计理念文档： https://github.com/apple/swift/blob/main/docs/CppInteroperability/CppInteroperabilityManifesto.md ，感受一下这个长度。并且 (1) 这个文档还没完成；(2) Swift 和 C++的互操作因为 ABI 原因，仅限于和 Clang ，而 Swift 团队很多人也是 Clang 团队的成员；(3) 语言要素上 Swift 和 C++并没有差特别多。其他语言恐怕很难有这些条件吧？

其次，因为编程语言抽象层次各不相同，高抽象层次容易转换成低抽象层次，反过来就很难。比如一段合法的 C++代码，可能就没办法转成（ safe 的） Rust ，因为违反了生命期和所有权约定；操作内存的 C 代码也不太可能翻译到 JS.

如果想在尽量保留高级语言信息的前提下在语言之间做翻译（否则可以说都编译到汇编也算相互翻译），那可能需要每个语言都限制用到的特性，保留一个抽象相似的公共子集，类似 asm.js ，在这个层面做相互翻译比较现实。这么做依然需要相当大的投入，但收益却一般。想到的一个例子是 Eclipse 曾经将 C++写的 Clang 翻译成 Java ，以集成到项目里做 C/C++语法分析。

Watch 想降级或者重置非常麻烦，而且 watchOS 一般可以向上兼容新 iOS ，但反过来不一定，所以通常不推荐追 watchOS Beta

@valuable
认为 Lightning 好用和认为换成 USB-C 是好事不矛盾。我觉得 Lightning 接口本身很稳固，但出门多带一种线就很麻烦了。

1. UTF-8 是变长的，UTF-16 在有代理对的情况下也是变长的，得 UTF-32 才行

2. 即使考虑了变长情况，UTF-8/UTF-16 编码的一个「字符」还不是我们理解里的字符，emoji 这里尤其复杂：比如国旗🇨🇳实际上是由两个从 U+1F1E6 到 U+1F1FF 的特殊字符拼成的。

3. 如果要在显示的层面考虑「字符」（ glyph ）就更复杂了，因为几个可以单独存在的字符挨在一起时可以拼到一块，比如某些特殊语言或者 ligature

所以用 UTF-16 算是一个相对折中的方案，如果你不严格要求从第 390 万个「字符」开始，可以先跳到第 390 万个位置上，然后根据当前位置是 Higher/Lower Part 做调整

@ecnelises
另外我好奇楼主说的「往用户目录拉坨屎」指的是读写主目录的 Documents/Downloads/Photos 这些目录呢，还是在主目录~下面创建点开头的隐藏目录，或者是~/Library ？

1. 从之前和 Epic 打官司期间，苹果高管的言论来看，他们对 Mac 可以 side-loading 这个现实的态度，基本类似父母对待自己眼中不争气的孩子，躺平了。当然不排除他们真的在未来某个版本这么高，但鉴于只允许从 App Store 安装这个选项已经存在多年，而且真的要搞，Big Sur 那么好的机会没搞，可能就是没这个打算。

2. macOS 上有大量脚本程序、仅命令行的程序、用户自己编写的程序，这些怎么办？好，可以说允许用户自己签名，那跟现在不是没有区别了吗？ M1 上本来每个二进制可执行文件都要签名才能运行。

3. 现在发布一个 macOS 上用户可以直接打开的软件，你需要：一个 Apple Developer 订阅+用这个订阅相关的密钥签名+发到苹果服务器自动化跑一遍查毒 (notarize)，理论上如果一个软件出了大问题，苹果可以给所有 Mac 远程发指令撤销该开发者的签名以让其打不开。这个流程和 App Store 就差一个人工审查。

4. iOS 的封闭软件生态工作得很好是因为它从一开始就这么运行的。苹果迁移到 ARM 都快两年了还有很多软件没适配，短期内整个这个限制对 macOS 生态就是灾难。而且 iOS 不可控的下架行为已经让人意识到禁止 side-loading 就是有两面性的，禁止了对属于生产力设备的电脑伤害更大。

5. Mac App Store 限制本来就比 iOS App Store 松，JIT 权限也是放开的，Slack 等软件也是 Electron 做的，上架 MAS 一点问题没有。所以这些倒不是障碍。

GCC 的主要扩展 Clang 都支持，其余的 Clang 处在一个随缘状态：不保证一定支持，但你要实现也没什么人反对。

滥用编译器扩展的确会影响可移植性，但两害相权取其轻，GCC 扩展的可移植性比起内联汇编和各种指令集 /操作系统强相关的自带函数还是好多了。Mac 迁移到 ARM 算是在这方面敲醒了一些人。只要把这些特定编译器的扩展封到宏 /函数里，然后对不支持的编译器加上#error ，问题不大。

Sigh.. 网站把我 List 的缩进吞了。

然后在上面提到的统一数据库基础上，提供一套 CRUD 接口，每个应用对应一个私有子库，也可以通过认证获得其他库的权限。并且这套接口不只是服务端可以用，客户端也可以用（本地数据库），因为它更像是点对点之间的 sync 而不是全靠请求获得资料的 B-S 模式。

但在客户端，这样有一个问题：数据库对客户端而言非常大。我们可以按需下载那些 Blob 文件，并且不下载过往的操作日志，剩下的数据库不会很大，还可以辅以压缩。（ V2EX 全站的用户和贴子数据装 Sqlite 里应该也只有几个 G ）

有了这套协议，我们就可以实现真·前后端分离的系统了。说简单一点，就是在本地实现了一套类似 LeanCloud 的东西，前端和客户端只需要假设本地或服务器有这个模块，连同步都是由这套实现自动完成。

OP 在那个贴子里提到的存储在用户本地的信息集合，有些类似 Tim Berners Lee 搞的 Solid ( https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) )？不过它更强调的是不同节点之间的互联。

---

有关同步的问题，我有过类似的想法：定义一种协议，它可以描述确定两个节点 A 和 B 之间的数据可以如何同步，并且

- A 和 B 不一定要相等，可以是 A 的子集和 B 的某个子集进行同步
- 比如 A 是一个人手机上的各种类型数据的集合，B 是一个服务器，那 A 只需要把照片这个子集和 B 里面属于 A 的部分同步
- 这个模式已经很常见了，但还没有发现有通用协议去规定它
- 同步当然要是增量的，但基于文件的同步不太靠谱，因为我们没法假定同步工具支持增量同步，也没法假定数据库到底是以何种方式存储的
- Event Sourcing 是个思路：每次修改会产生一条记录，当前数据是所有记录执行后的一个快照。这个设计类似 Flux 或者 Git ，所以很自然地，如果同步双方的记录日志分叉了，还可以尝试 merge
- 继续从 Git 思路出发，客户端和服务端是多对多关系，甚至没有服务端的概念，因为服务端本身也可以作为中继，同步到上游数据库
- 如何避免环出现呢？
- 不知道 OP 用不用 iCloud ，其实 iCloud 就像时刻连接着的一根线，把设备的数据和苹果的服务器做 iTunes 同步。这里同步的是数据库而不是文件（ iCloud 云盘是后来才有的），所以后来它们还开放了 CloudKit 这个东西
- 苹果的自带软件和若干第三方软件都偏好用 iTunes 风格的数据库而不是文件夹存数据。我喜欢这种方式，因为数据库比文件要结构化得多，能存更多元数据，读写同步效率也都更高
- 但并不是所有数据都能放到数据库里，比如很大的照片或录像，它们适合存放在单独的文件里作为 Blob. 如果把这些数据库和 Blob 打包并规范化（开发一个统一 API 操作），那会十分方便，并且可以和第一点提到的协议结合，软件的各个小数据库其实是系统大数据库的一部分（有点像 Windows 注册表了？）
- 某些文档数据库已经自带了管理 Blob 到文件的功能
- 由于数据结构高度统一，快照、备份、回滚这些功能都变得很容易，可以用类似 zfs send/receive 的方法轻松备份和加密

- 苹果公司标榜隐私是一种营销手段，但是营销不代表不做事。小米是不是标榜性价比？是。小米的性价比有没有代价？有。但小米依然有性价比。除了少数手机厂商，你很难看到互联网公司出来在隐私保护上内卷，打苹果的脸，这本身就能说明点问题了。
- 反对苹果的人最爱举的例子是 2014 年 iCloud 照片泄露事件以及和有关部门的合作（喷棱镜门的和喷云上贵州的建议先打一架），支持苹果的人最爱举的例子是 iOS 14.5 反广告追踪功能。但在楼上说的房间里的大象面前，这些事是否……太片面了些呢？举个例子，居民身份的数据泄露了，这恐怕比京东广告精不精准的负面影响高了几个数量级，但它和你用什么手机，有关系吗？
- 不要试图在网上和人就这些话题吵架：你说隐私保护，他说 iCloud 泄露，你说那是撞库，他开始复读一百块的布。

联想到了吗，对 HTTP 是否应该使用状态码来表达业务状态的争议，其实颇像「使用异常还是错误码」这个同样老生常谈的问题。有些人大小事都要抛异常；另一些人尝试 catch 一切异常，并永远使用错误码。而当代码要接入一个现有模块时，事情变得更复杂了。

HTTP 通用的错误码（ 4xx, 5xx ）很有限，就像系统定义的异常类型，必然无法涵盖所有错误的情况。但我们不必做二极管，始终在上面提到的两种人间反复横跳：尽管很多错误码是和 HTTP 协议强相关的（比如 411 ），至少常用的 401/403/404 语义可以完美对应项目中一定会出现的几种错误情况；除此之外，简单用 400 表达请求有问题，500 表达服务端有问题，搭配自定义的错误代码即可。

另一个和是否使用 HTTP 错误状态码相似的争议，是「是否要以 REST 方式组织 API 」。是的，生搬硬套的 CRUD 语义没办法定义现实中的所有复杂情况，但也不该因此就彻底抛弃这套被广泛接受的代码组织思路：GET 不应有副作用，PUT 相比 POST 有幂等性；实在不行把一些操作都抽象成某个 Action ，然后所有有副作用的操作一律 POST 也比一团乱麻来得整洁。

https://gist.github.com/ecnelises/c16af59384772e4548ac4e59e13b810f

稍微改了一个，不完美，可以加到自定义 CSS 里