《「macOS」问题》存档

本贴是《「macOS」问题》一文的存档。

前:《「时间裂隙」问题》存档

1 个赞

可能有小伙伴发现,Koishi Desktop 的最新 v1.0.2 版本,没有 macOS 的任何包。

这是为什么呢?跟着小编一起来看一看吧。

1 个赞

Apple、Mac 用户、macOS 软件开发商之间,有一个默契的约定,那就是「使用最新版本的 Mac 和 macOS」。

曾经有人想要反抗这个约定。我们来看看下面的几个例子:

1 个赞

例 A:使用旧 Mac 开发 iOS 应用

你是一个普通的 Apple 用户,有一台 2017 年的 Mac,和一台最新的 iPhone。你想开发 iOS17 应用。

不行!

  • 要开发 iOS17 应用,需要最新 iOS SDK
  • 最新 iOS SDK 包含在最新 Xcode 中
  • 最新 Xcode 需要最新 macOS
  • 最新 macOS 已经不支持你的 17 年的 Mac 了

解决这个问题的唯一方法似乎是更换最新款的 Mac。

1 个赞

例 B:使用旧 Mac 安装最新 Adobe/Autodesk 软件

你是一个普通的 Apple 用户,有一台 2013 年的 Mac,想安装最新版的 Adobe Photoshop(2023-11)/Autodesk AutoCAD(2024)。

可以!

不过最新版已经是最后一个支持你的电脑的版本了。

  • 后续的升级需要更新的 macOS
  • 最新 macOS 已经不支持你的 13 年的 Mac 了
1 个赞

小伙伴们可能会感到疑惑:2013 年的 Mac 都能装最新 Photoshop,怎么就不能装 Koishi Desktop 了呢?小编也感到非常疑惑。

别急,让我们继续往下看。

1 个赞

例 C:使用新 Mac 编译软件

你是一家世界闻名的 macOS 软件开发商,你的工作室里摆满了大大小小的 Mac,从 2013 款到最新的 Mac 你都有。你想使用你的最新款 Mac 编译你的软件,使其能在 macOS 11 上运行。

可以!

不过:

  1. 你需要 降级 你的 Xcode,使其退回到支持 macOS 11 的版本。具体来说,是 Xcode 12.5.1 - Swift 5.4

你依稀记得前面说过,只有最新的 Xcode 才能编译 iOS 17 应用。你意识到你现在的电脑无法编译最新的 iOS App 了。

  1. 支持 macOS 11 的版本是你能降级到的最老版本。

更老的 Xcode 安装好以后无法启动,提示「更新 Xcode」。你意识到这台 Mac 完全无法编译 macOS 10.15 的应用了。


但问题不大,毕竟支持 macOS 11 也是支持!

1 个赞

Koishi Desktop 就曾经遇到了上面的问题:

该问题只要降级 Xcode 就可以修复,因此当时 Koishi Desktop 仍然能够继续支持 macOS 11。

1 个赞

例 D:使用旧 Mac 编译软件

你毕竟是世界闻名的 macOS 软件开发商,手边就有 2013 款的 Mac。可以拿这款 Mac 编译 macOS 10.15 的应用吗?

当然可以!

不过:

  1. 编译报错了,似乎 Xcode 不支持 Swift 5.4。这很合理,你改了改语法让代码支持 Swift 3。
  2. 编译好的应用在 macOS 14 上似乎无法启动。
  3. 这里的 Xcode 似乎没有编译到 Silicon 的选项,这也合理。

现在你得到了一份支持 macOS 11-14、支持 Silicon 的应用,和一份支持 macOS 10.15 的应用。

你不确定是否仍然应该每次发版都拿两个语法的 Swift 各写一遍,不过大公司估计肯定不会这么干了。

1 个赞

例 E:目标旧版 macOS 编译 Brew 软件

你仍然是世界闻名的 macOS 软件开发商,这次你要编译一个带 Brew 的软件,使其能在 macOS 11 上运行。

再怎么说 macOS 11 也不老了吧。可以在 macOS 14 上直接编译吗?

不行!

这也合理,毕竟两个大版本之间有变更也是正常的。那么,可以在 macOS 11 上直接编译吗?

不行!

虽然很奇怪,但 Brew 已经放弃了对 macOS 11 的支持。Brew 放弃支持后会尝试使用源码编译,而源码编译大概率会失败。(如果你体验过 node-gyp 的源码编译的话,可能对源码编译深有体会。


但不管怎么说,你已经无法把手里的应用编译给 macOS 11 的用户使用了。

1 个赞

那么 Brew 为什么要放弃支持呢?原因也很简单,因为 Apple 放弃了 macOS 11 的支持。这意味着如果遇到系统导致的漏洞或编译问题,Brew 将无法自行解决,于是只能同步放弃。

大公司解决这个问题的方法非常简单:给每一个版本的系统安装一整套对应时间的开发环境,然后储存一份系统镜像。这样,在目标旧版本和新版本系统的时候,就可以取出不同的系统镜像,进行编译。

而如果你没有可以随意更换系统的设备,或者你 忘记 了在对应的时间备份对应版本的环境,那么要想再找回旧版本的开发环境就十分困难了。

在没有备份旧版本开发环境的情况下,你很难在没有开发环境的系统上安装环境和编译,因为已经没有任何一方支持这种情况。

1 个赞

到这里,「macOS」问题就比较清楚了:


「macOS」问题:

任何一个版本都可能无法编译,因为编译依赖 Apple 的支持,

而 Apple 随时可能放弃对旧版 macOS 的支持

1 个赞

Koishi Desktop 就是这样的情况。Koishi Desktop 的构建运行在 GitHub Actions 上,因此并没有能够固定存放旧版本环境的设备。

因此 在未来,Koishi Desktop 将仍然会不定期出现发布版本中缺少 macOS 版本的情况。 我们目前也无法解决这一问题。

1 个赞

似曾相识

2 个赞

show show way

2 个赞

3 个赞