让 Xcode 见鬼去

[Jat001]

为什么？

Xcode 的配置文件虽然是纯文本，但正常人基本看不懂。也没有一个工具可以在不丢失任何信息的情况下把 project.pbxproj 解析成人类可读的格式。

最近开发 Flutter ，发现官方提供的 macOS 和 iOS 模版都是基于 Xcode 的，也就是说如果想要查看或修改构建配置，必须打开 Xcode ，这显然是可以接受的 (unacceptable)。

如何拒绝打开 Xcode

Xcodeproj 可以把 project.pbxproj 解析成 YAML 格式，在 Flutter 的 macOS 模版上试了下，构建相关的信息基本没丢。

但 Flutter 自身仍要借助 Xcode 来构建，所以只能看是不行的，必须有工具重新生成 project.pbxproj。

XcodeGen 虽然可以通过 YAML 生成 project.pbxproj，但它的 spec 跟 Xcodeproj 解析出来的 YAML 完全不同。

目前只能通过对照 Xcodeproj 解析出来的 YAML 和 XcodeGen 的 spec 人工完成。

示例

我花了两天时间把 Flutter macOS 模版里的 project.pbxproj 解析成了 YAML ，简单改改就能直接用了。

https://github.com/jat001/ddns4cdn-aio/blob/main/src/macos/project.yml

另外还有一份通过 Swift 调用 staic library (.a) 或 shared library (.so) 的示例，仍然无需打开 Xcode 就可编译。

https://github.com/jat001/ddns4cdn/tree/main/src/cgo/swift

这个项目其实是 Go 写的，通过 cgo 实现了用 C, C++, Objective-C 和 Swift 调用 Go 。当然，入参只有一个字符串，毕竟类型转换很麻烦，复杂的调用不如直接用目标语言重写。

[musi]

如果用的是 swiftui 是不是就只能用 xcode 了

[weeei]

为啥不改成 bazel ？

[Jat001]

@weeei #2 因为 flutter 不支持，macos 和 ios 的构建过程强依赖 xcode 那堆鬼东西

[alexcding]

好久没有追 flutter 了? 现在 iOS , macOS 支持如何了. 听说 Flutter 和 Fuchsia 组被谷歌裁员了. 前途不明

[CodingIran]

为什么要抗拒 Xcode? Flutter 很多的功能都要依赖原生桥接，不可能完全抛开 Xcode

[Jat001]

@alexcding #4 支持度应该是能用，哈哈哈

@CodingIran #5 帖子一开头我就讲了，先给我一个人类可读的配置文件

[zongren]

啥意思，proj 改成 yaml ，然后修改 yaml ，然后生成新的 proj ？

[weeei]

@alexcding 裁员不是 2 月份的新闻了吗，到现在都过去 8 个月了，现在又裁了？

[Jat001]

@zongren #7 是的，新项目可以直接手写 yaml ，然后通过 XcodeGen 生成 pbxproj 。但已有的项目只能用 Xcodeproj 解析，然后人工翻译。最终目标就是不用打开 xcode ，也能修改 macos 和 ios app 开发的构建过程，进而完全摆脱 xcode 的 gui ，但 command line tools 还是摆脱不了

[alexcding]

@weeei 好像 7/8 月份又裁员了一次. 主要是 Fuchsia 代替安卓没戏了. 只有谷歌内部用, 第三方厂商不想被谷歌套牢. 宁可安卓用到底.

[alexcding]

@Jat001 我之前写了 5,6 年安卓和 AOSP, 如果现在让我写安卓, 宁可写 Flutter.

[LavaC]

@musi swift playground （

[debuggerx]

虽然不觉得 OP 这样做能解决多少问题，但是，只要你也想让 Xcode 去死，我们就是异父异母的亲兄弟🐶

@alexcding flutter 的前途已经和 Fuchsia 没什么关系了，我从一开始就不认为 Fuchsia 能有多大前景，而且是 Fuchsia 在沾 Flutter 的光而不是反过来 Flutter 要靠 Fuchsia 来起飞，很多人都没搞清楚两个东西各自的目的和思路就瞎扯。


@CodingIran 因为 Xcode 真的真的太恶心人了，能让我少碰哪怕一分钟都是谢天谢地，但凡能用三方库解决的问题我是绝不会自己去写原生桥接，而且其实很多需求和场景下，也确实可以通过使用三方库就可以解决问题，不会找库或者不愿用三方库非要自己写桥接的行为，我尊称之为自作孽不可活，往往接手和维护就变火葬场。

[Jat001]

@debuggerx #13 我觉得最搞笑的是，当我搜索 mac 开发相关的问题时，大部分答案都是在 xcode 里点点点，哪怕是 stack overflow 上的答案，满屏的截图是最恶心的，完全没心情看

[debuggerx]

@Jat001 然后不同版本可能截图不同，搜的时候还得看提问回答时间和对应 Xcode 版本，老版本的截图的东西新版本可能换了位置或者压根不对，最后还是得手动编辑 pbxproj 文件然后重开 Xcode 跑编译期待不出错……
汤师爷：就是一句话,恶心!

[lisongeee]

没有用过 ios 开发，好奇 xcode 是一个必须打开的 gui 软件吗？

ios 程序的编译不能直接通过 命令行 执行吗？

[Jat001]

@lisongeee #16 就 flutter 来说，官方的构建过程完全是基于 xcode 的，编译当然不用打开 xcode ，xcode 有自己 cli tools ，flutter 会直接调用。但 xcode 的配置文件不是人类可读的，要想修改编译配置，必须通过 xcode 的 gui ，在 gui 里点点点。
最大的问题是，这堆配置文件不仅不是人类可读的，还有一大堆冗余信息（大部分是 xcode 生成的用于编译的默认配置），但要想正常编译就必须有，所以要加到版本控制里，就很容易出现无法 merge 的冲突。

[winterbells]

我尝试 KMM 项目也是的，非要打开 Xcode 配置，完全复制粘贴按照文档里的截图设置完了，Xcode 编译还是报错。把报错的 gradle 命令手动执行又是正常运行的。最后还是直接 clone 了项目

[luck66]

@debuggerx 你喜欢用第三方，也没必要贬低不用第三方的人，往往很多第三方库都是由这些人贡献和编写的

[konnnnn]

反过来想，ios 原生开发的 bar 挺高的:你要掌握各种坑的 workaround...

[chihiro2014]

最近接了一单需要写 ios ，ios 的开发环境太逆天了…装了 macos12 黑苹果以及能支持的最高版本 xcode ，然后插上我的 13pro max 表示不兼容，插上我淘汰的 6s 和 5s 也不兼容。草，太逆天了妈的。

[debuggerx]

@luck66 你没懂我的意思，我当然感激和佩服维护三方库的人，我说的是因为“认知问题”而不用成熟三方库，而自己写“脆弱且不可维护的”原生桥接代码把项目搞得难以维护，还以自己“同时精通”跨平台和原生而沾沾自喜的人。

我接手过包括 Flutter 在内的很多项目，很多明明有成熟的第三方库可以用，但是之前写的人可能就是从不知道哪里复制来一段 just work 的代码，或者自己造了一个当时在他环境下可用的轮子，结果上线后发现很多用户的设备没考虑到出现各种问题，如果用的是成熟的三方库就很可能已经覆盖了这些设备差异；有时我们接手后随着系统更新各种出错不可用，如果是活跃的三方库可以通过升级依赖的方式快速解决，或者可以通过 issue 和别的开发者讨论找到方案。

[Leonard]

@chihiro2014 iOS 版本和 Xcode 版本绑定，Xcode 版本又和 macOS 版本绑定

[CareiOS]

了解一下 tuist

[Jat001]

@CareiOS
都说了 xcode 的配置文件不是人类可读的，也没有任何第三方工具可以解析

Can I generate the manifest files from my Xcode projects?

While we can generate Xcode projects from your manifest files, doing it the other way around is not possible. It's possible to implement such feature in Tuist, but since we wouldn't be able to do it reliably considering how Xcode projects can be, we opted for not doing it. Moreover, going through the process of defining the manifests helps you spot issues in your current projects that otherwise would go unnoticed.

[shellcodecow]

很难接受吗? .... 很难吗?

[Jat001]

@shellcodecow 无脑果粉？要是 android studio 不用 gradle 而是自己搞个封闭的构建工具不知道会被喷成啥样。不过也不奇怪，apple 自己连个从 cli 里安装 ios app 的工具都不愿意提供

[zongren]

那是不是把这两个项目 Xcodeproj 和 XcodeGen 修改一下，使用相同 yaml 格式，就可以摆脱人工修改 yaml 了

[shellcodecow]

@Jat001 #27 没经历过社会毒打才会傻 x 一件毫无意义的事情. 硬件不够的升级硬件, 有洁癖的洗手

[dohaeris]

然后未来某次 Xcode 升级之后你的 YAML 就不能用了[doge]

[chihiro2014]

我只能说只是什么傻逼逆天生态

@Leonard

[Jat001]

@zongren 不行，前面说了，没有任何一个工具可以在不丢失信息的情况下解析 xcode 的配置文件，这包括 Xcodeproj

[Jat001]

@shellcodecow 没经历过社会毒打才会傻 x 一样在网络上发些没有意义的风凉话，不喜欢就尝试去改变，只会抱怨解决不了问题

[Jat001]

@dohaeris 有这个可能，所以最好的办法还是摆脱 xcode 那套封闭的生态链

[ostholz]

为什么不用 Tuist

[Jat001]

@ostholz 25 楼有写

[ostholz]

@Jat001
sorry, 没看到那楼

[IgniteWhite]

@shellcodecow 你把人笑拥了我给你说。开发者要是都懒得做所有事，一切都遵从傻瓜配置，GitHub 不得倒闭了。

[zeromake]

实际上有很多工具可以跳过 xcode 直接编译应用了，但是到了 debug 还是得回到 xcode……

[zongren]

@zeromake debug 能不能直接调用后端？使用 vscode 作为前端？

[zongren]

@Jat001 可以接受丢失一些信息呢？或者说在解决了 Xcodeproj 和 XcodeGen 的 yaml 格式不匹配的问题后，是否能丢失一些（不影响构建）信息的情况下完成 1 、转 yaml ； 2 、编辑 yaml ； 3 、生成 proj ； 4 、命令行打包的工作流？

[Jat001]

@zeromake #39
swift 可以 debug 啊
https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang
vscode 最大的贡献就是发明了 lsp ，只要按照协议开发对应的插件，就不需要编辑器专门支持

@zongren #41
1 就会丢，丢啥不确定，毕竟是封闭的配置文件，没有文档告诉你有什么参数
3 有可能随着 xcode 更新，有些参数废弃了，或者有些参数新增了
我觉得你还是自己试试看，装下也没多少时间，

[zeromake]

@zongren @Jat001
metal 在 xcode 里调试方便啊，直接可以看到 shader 的输入和输出

[snowasnow]

@musi 可以使用 vs code+bazel https://github.com/bazelbuild/rules_apple/blob/master/doc/tutorials/ios-app.md

[zoharSoul]

@lisongeee #16 新版本必须打开 xcode