HMCL-dev
[Feature] 将 MacOS 编译产物打包为 app 并通过 dmg 进行分发
概述 | Summary
将 MacOS 编译产物打包为 app 并通过 dmg 进行分发
原因 | Reason
个人觉得在 MacOS 上 app 格式还是比 jar 更易用的，还能更好的支持 MacOS 的一些特性。 但打包为 app 可能会出现一些路径和权限方面的问题，如果弊大于利就算了吧。
详情 | Description
No response
打包成app后可以优先把游戏资源放在官方启动器目录，把配置和日志统统放进Application Support，这样在一定程度上可以避免部分权限问题，但是这也会损失HMCL的便携性
就是说我的电脑HMCL 有个BUG，就是启动 MC 之后，HMCL 哪怕选择在进程结束后打开，依然会在游戏退出后一起退出，除非时游戏报错，但是这样也只有个报错窗口。我开发的 Java APP 在和 MC 一起打开时也出现了这样的问题，后面是发现打包成APP之后就没有这样的BUG了，我觉得这应该就是 Jar文件的劣势吧，能不能采用看管理大大吧
就是说我的电脑HMCL 有个BUG，就是启动 MC 之后，HMCL 哪怕选择在进程结束后打开，依然会在游戏退出后一起退出，除非时游戏报错，但是这样也只有个报错窗口。我开发的 Java APP 在和 MC 一起打开时也出现了这样的问题，后面是发现打包成APP之后就没有这样的BUG了，我觉得这应该就是 Jar文件的劣势吧，能不能采用看管理大大吧
这个可能是配置的问题？实例设置与全局设置不一致？
概述 | Summary
将 MacOS 编译产物打包为 app 并通过 dmg 进行分发
原因 | Reason
个人觉得在 MacOS 上 app 格式还是比 jar 更易用的，还能更好的支持 MacOS 的一些特性。 但打包为 app 可能会出现一些路径和权限方面的问题，如果弊大于利就算了吧。
详情 | Description
No response
在我的 Mac 上使用 jpackage 命令生成 app，打开时遇到了问题：
直接运行
HMCL.app/Contents/MacOS/HMCL 就没这个问题🤔
而且，在 macOS 上运行未签名的应用（可执行文件或 .app）会被 Gatekeeper 拦截，只有用 Apple 开发者账号签名并公证后才能直接打开，但账号年费较高（688 元） 用户也可以在“系统设置 > 隐私与安全性”里手动允许 App 通过，但这样对新手不是很友好
而且，在 macOS 上运行未签名的应用（可执行文件或 .app）会被 Gatekeeper 拦截，只有用 Apple 开发者账号签名并公证后才能直接打开，但账号年费较高（688 元） 用户也可以在“系统设置 > 隐私与安全性”里手动允许 App 通过，但这样对新手不是很友好
apple开发者账号无所谓，在访达里直接打开就不会被拦截
而且，在 macOS 上运行未签名的应用（可执行文件或 .app）会被 Gatekeeper 拦截，只有用 Apple 开发者账号签名并公证后才能直接打开，但账号年费较高（688 元） 用户也可以在“系统设置 > 隐私与安全性”里手动允许 App 通过，但这样对新手不是很友好
apple开发者账号无所谓，在访达里直接打开就不会被拦截
任何方式打开都会（）包括在访达中右键打开 你能直接打开可能是由于关闭了 GateKeeper 或 这个 App 是你自己构建的
在我的 Mac 上使用
jpackage命令生成 app，打开时遇到了问题：直接运行
HMCL.app/Contents/MacOS/HMCL就没这个问题🤔而且，在 macOS 上运行未签名的应用（可执行文件或 .app）会被 Gatekeeper 拦截，只有用 Apple 开发者账号签名并公证后才能直接打开，但账号年费较高（688 元） 用户也可以在“系统设置 > 隐私与安全性”里手动允许 App 通过，但这样对新手不是很友好
对新手不友好确实是个问题。 但话又说回来了，Jar 文件也不见得有多友好，更何况都用 Mac 打 Minecraft 了，想必也不会是什么新手（至少概率不大），手动放行也不是什么难事。
PS: 其实已经有正在测试的 MacOS 打包版本了 ShulkerSakura/HMCL-MacOS
对新手不友好确实是个问题。 但话又说回来了，Jar 文件也不见得有多友好，更何况都用 Mac 打 Minecraft 了，想必也不会是什么新手（至少概率不大），手动放行也不是什么难事。
PS: 其实已经有正在测试的 MacOS 打包版本了 ShulkerSakura/HMCL-MacOS
不要觉得用 Mac 打 Minecraft 的都是大佬。 在某个 macOS 启动器的用户群，你甚至能看到不会截图的……
对新手不友好确实是个问题。 但话又说回来了，Jar 文件也不见得有多友好，更何况都用 Mac 打 Minecraft 了，想必也不会是什么新手（至少概率不大），手动放行也不是什么难事。 PS: 其实已经有正在测试的 MacOS 打包版本了 ShulkerSakura/HMCL-MacOS
不要觉得用 Mac 打 Minecraft 的都是大佬。 你甚至能看到不会截图的……
绷不住了......
但不会截图怎么就会运行java -jar hmcl.jar呢....
手动放行其实也就是点几下的事吧，我真感觉还好 （
对新手不友好确实是个问题。 但话又说回来了，Jar 文件也不见得有多友好，更何况都用 Mac 打 Minecraft 了，想必也不会是什么新手（至少概率不大），手动放行也不是什么难事。 PS: 其实已经有正在测试的 MacOS 打包版本了 ShulkerSakura/HMCL-MacOS
不要觉得用 Mac 打 Minecraft 的都是大佬。 你甚至能看到不会截图的……
绷不住了...... 但不会截图怎么就会运行
java -jar hmcl.jar呢.... 手动放行其实也就是点几下的事吧，我真感觉还好 （
啊？都什么年代了还有人用java -jar？
对新手不友好确实是个问题。 但话又说回来了，Jar 文件也不见得有多友好，更何况都用 Mac 打 Minecraft 了，想必也不会是什么新手（至少概率不大），手动放行也不是什么难事。 PS: 其实已经有正在测试的 MacOS 打包版本了 ShulkerSakura/HMCL-MacOS
不要觉得用 Mac 打 Minecraft 的都是大佬。 你甚至能看到不会截图的……
绷不住了...... 但不会截图怎么就会运行
java -jar hmcl.jar呢.... 手动放行其实也就是点几下的事吧，我真感觉还好 （啊？都什么年代了还有人用
java -jar？
恰恰相反，苹果早已放弃了对 Java Launcher 的支持。 直接打开才是 "都什么年代了"
另外请不要把这里当成即时通讯软件。请善用 Edit 功能。
干脆简单总结一下这么做的好处与坏处：
好：
- 更加符合macOS用户的直觉，避免使用
JavaLauncher.app来代替启动，防止因错误的JAVA_HOME配置导致的启动失败 - 便于权限的申请，从而使用Simple Voice Mod等需要额外的权限来运行的模组
- 可以单独维护一个类似于Windows下HMCLauncher的组件，实现Java的自动下载，或者实现其他进阶功能（我目前在尝试：WhatDamon/HMCLauncher-macOS，但是有重要的权限问题需要HMCL来解决）
- 间接达成修改顶栏应用名称的目的（现阶段为
Main， 前面提到的ShulkerSakura/HMCL-MacOS将它改为了HMCL） - 使用游戏模式 #3831
- 使用上Liquid Glass图标（上述HMCL-MacOS已添加） #4117
坏：
- 考虑到权限等问题，最好是要把配置与游戏全部迁移到
Application Support目录（虽然HMCL已经在使用该目录存储一些敏感的信息，例如账号），会丧失HMCL的部分“便携性”特色 - 签名问题，要一个可以无脑直接在所有macOS直接使用的签名非常考验经济实力，否则只能自签名甚至不签名，这样的代价是可能需要用户手动使用
xattr指令消除Gatekeeper隔离，或者到“系统设置”放行，小白用户不友好 - 额外的开发成本，当然这是看怎么实现的，例如前面提到的项目使用bash方式，搞起来难度是不大，但要维护一个类似于HMCLauncher的项目，就需要有会macOS开发的人员参与了（目前我自己在摸索着尝试）
[仍需补充]
干脆简单总结一下这么做的好处与坏处：
好：
- 更加符合macOS用户的直觉，避免使用
JavaLauncher.app来代替启动，防止因错误的JAVA_HOME配置导致的启动失败- 便于权限的申请，从而使用Simple Voice Mod等需要额外的权限来运行的模组
- 可以单独维护一个类似于Windows下HMCLauncher的组件，实现Java的自动下载或者JFX的补充，或者实现其他进阶功能
- 间接达成修改顶栏应用名称的目的（现阶段为
Main， 前面提到的ShulkerSakura/HMCL-MacOS将它改为了HMCL）坏：
- 考虑到权限等问题，最好是要把配置与游戏全部迁移到
Application Support目录（虽然HMCL已经在使用该目录存储一些敏感的信息，例如账号），会丧失HMCL的部分“便携性”特色- 签名问题，要一个可以无脑直接在所有macOS直接使用的签名非常考验经济实力，否则只能自签名甚至不签名，这样的代价是可能需要用户手动使用
xattr指令消除Gatekeeper隔离，或者到“系统设置”放行，小白用户不友好[仍需补充]
游戏无需迁移到 Application Support 目录。万一真有权限问题（App Sandbox 限制），也是迁移到 Containers 目录，但这种方式打包的 HMCL 没有该限制。
游戏无需迁移到 Application Support 目录。万一真有权限问题（App Sandbox 限制），也是迁移到 Containers 目录，但这种方式打包的 HMCL 没有该限制。
开启沙盒化使用 Containers 存放游戏，当然这不是说不行，只不过 HMCL 已经在使用 Application Support 这个目录了，官方启动器也会把游戏本体放在这个目录，说白了默认其实可以直接使用官方启动器的目录 ~/Library/Application Support/minecraft，如果依旧希望分开也可以在已有的 hmcl 目录中存放游戏（例如 ~/Library/Application Support/hmcl/minecraft），这样 HMCL 产生的文件也不会那么分散，如果要彻底卸载启动器也会方便一些，同时允许玩家自己在有读写权限地方创建新的游戏目录
虽然应用程序有权限在 App Bundle 中进行读写文件，但是这是在大多数情况都绝对不推荐的下下策，有时可能会出现签名失效或文件损坏还无法修复的问题
建议有关维护者将此问题转移到Discussion，此问题依旧需要进一步研究，毕竟macOS的GateKeeper、XProtect、隔离机制、TCC都不太好搞定（除非禁用系统完整性保护，否则连sudo都搞不定）
建议有关维护者将此问题转移到Discussion，此问题依旧需要进一步研究，毕竟macOS的GateKeeper、XProtect、隔离机制、TCC都不太好搞定（除非禁用系统完整性保护，否则连sudo都搞不定）
禁用的话一大堆萌新会觉得 HMCL 是病毒要威胁计算机:-(
建议有关维护者将此问题转移到Discussion，此问题依旧需要进一步研究，毕竟macOS的GateKeeper、XProtect、隔离机制、TCC都不太好搞定（除非禁用系统完整性保护，否则连sudo都搞不定）
禁用的话一大堆萌新会觉得 HMCL 是病毒要威胁计算机:-(
macOS的权限限制过于严格导致的后果 😂，为了实现这一目标，并尽可能减少用户的误解，唯一能做的就是尽可能顺着macOS的“偏好”来进行开发
macOS的权限限制过于严格导致的后果 😂，为了实现这一目标，并尽可能减少用户的误解，唯一能做的就是尽可能顺着macOS的“偏好”来进行开发
然后macos的偏好就是要你的开发者身份......
关于此问题我还意识到一个关键点：HMCL 本身可能无法更新整个 App Bundle（如果 Resources 目录变为只读，HMCL 本身也无法更新）
我目前有以下解决方法：
1. 只通过 Homebrew Cask 进行分发
此方案的实现的基础是 #4229 的完成
将 HMCL 以 hmcl、hmcl-prerelease、hmcl-nightly 三个包来分发不同的更新频道版本
但需要注意的是，Homebrew 即将收紧未签名的 Cask 安装，--no-quarantine 的移除让通过 Tap 添加的软件源也没法简单的绕过 Gatekeeper 限制，用户体验并不太好，而公证需要一个年费为 $99 的 Apple Developer Program，在签署合同时会要求提供真实姓名（四舍五入就是别人都知道你是谁的实名上网）
2. 引入 Sparkle
这代表着 HMCL 的启动文件不能使用 Shell，另外此方案需要解决 HMCLauncher 和 HMCL 本身的通讯问题，还有每次更新都需要单独维护 AppCast.xml
要集成 Sparkle 最好需要一个 Swift 开发的 HMCLauncher，例如我正在尝试的WhatDamon/HMCLauncher-macOS
但个人不倾向于此方案，因为 HMCL 程序的特殊性，我也不敢保证每次更新都能按照预期完成，并且用户界面可能会比较膈应
若有其他解决方案，可以提供以下
在签署合同时会要求提供真实姓名（四舍五入就是别人都知道你是谁的实名上网）
实际上，HMCL 官网的 ICP 备案信息通过备案号也能查到真实姓名，因此没必要专门为了不泄露姓名而不对 App 进行签名。
我认为可以在第一次启动时将 HMCL 本体移动或复制到 Application Support 目录中，更新时修改 Application Support 中的副本，这样（应该？）可以避免权限问题。
我认为可以在第一次启动时将 HMCL 本体移动或复制到
Application Support目录中，更新时修改Application Support中的副本，这样（应该？）可以避免权限问题。
此方法不能实现对App Bundle本身的更新，若我要更新HMCLauncher for macOS以尝试同步HMCLauncher for Windows加入的新功能，可能依旧需要引入Sparkle，但两个不同的更新总有些膈应，是否有更好的解决方案？