大家好，我是坤哥
今天和大家探讨一个话题：技术的稳定性到底有多重要
上周用三天的时间把原本预计至少一周才能改造完成的 iOS 项目在最新的 Xcode 15（iOS 开发 IDE）上成功跑起来了！
其实说实话这个 iOS 项目用两周的时间在 Xcode 15 上能不能跑起来我心里都没底，好在结果是好的
这个项目过去四年了，是我司的主要盈利产品（返利 app），不过技术栈还比较陈旧，一些依赖用的 swift 3.0 写的（最新的 swift 版本是 5.5），在最新的 Xcode 15 上跑不起来，也就无法打包，那还了得，万一碰到什么 bug 无法打包解决问题可就大了
其实五一前两周我们在迭代开发产品时就发现 4.29 日之后必须用 Xcode 15 打包，还好提前一周我们发现了这个问题，这样可以先降级到 Xcode 14 来开发打包，迭代的功能也顺利上线了
但是 app 不能在 Xcode 15 上启动打包的问题终究是要解决的，于是五一回来之后我又马不停蹄地迭代这个 APP，以让它能在 Xcode 15 上跑起来，好在运气比较好，经过一番魔改（之后会提到）终于跑起来了
四年对一个项目其实说长也长，说短也短，理论上像 Java 开发的项目，由于 JDK 通常设计为向后兼容的（兼容老版本），老项目通常能跑起来，为啥我们的这个 iOS 项目会有这样在最新版 Xcode 15 上跑不起来的问题呢
主要原因其实是因为这个项目的 Pod（iOS 项目中的 Pod 类似 Java 中 Maven 管理的第三方依赖库）不少是由 Swift 开发（苹果 2014 年推出的编程语言），这些 Pod 库中有不少引用 OC（Objective-C，苹果系之前的主流开发语言）的代码
在之前的 Xcode 中，工程是可以跑起来的，但是最新的 Xcode 15 对编译器等做了大量的的修改导致这些 Pod 都无法编译通过了，然后就跑不起来了，试了网上各种方法都不行
这事其实很要命，试想如果发现线上有个 bug 需要紧急修复（比如无法提现），然后你的 app 却无法打包导致短时间内无法修复，很可能导致用户流失，业务停滞甚至公司倒闭的严重后果
假使我们当时的技术人员统一在工程中都用 OC，而不是用 Swift 来写代码，那压根就不会出现这样的问题，如果一定要用 Swift，至少要等到 ABI 稳定之后再用
「这里简单解释一下什么是 ABI 稳定：想象一下，有一座桥，这座桥连接了两座岛屿：一个岛是 Swift 语言自身，另一个岛则是操作系统，比如 macOS 或 iOS。这座桥就像是一个协议，确保两边可以互相理解和交流。在软件的世界里，这座桥就是“应用程序二进制接口”（Application Binary Interface，简称 ABI）。
Swift 的 ABI 稳定性可以比作这座桥的结构变得坚固且不再改变。初期，Swift 还在不断发展，这座桥每隔一段时间就需要重建一次，这意味着开发者如果使用了新版本的 Swift，他们可能需要重新编译他们的应用程序，以确保它能在新桥上运行。」
Swift 作为一种新技术，其实还是存在不少坑的，手淘也是在 ABI 稳定后才开始在项目中引入 Swift 的，这就好比 JDK 22 出来了，但国内大部分还是使用的 Java 8
为什么会出现这种「你升任你升，我用 Java 8」的场景呢，还不是出于稳定性考虑
任何新技术的引入都要考虑以下几个因素：
一般我们考虑的重要性按上面三点是依次递减，但实际上第三点可能反而是最重要的
其实我们这个项目虽然还未等 ABI 稳定就引入了 Swift，但当时公司的发展如日中天，有几十号 iOS，也有好几位 iOS 架构师，所以工程一旦有啥技术问题，基本也能轻易解决
但后来公司业务急转直下，iOS 团队被裁或离职导致一个不剩，后来公司彻底转型，干掉了所有的技术，你没看错，iOS 开发全都没了（你说这种情况谁能想到）
那这时之前在项目中引入的 Swift 就成为了一颗随时会引爆的定时炸弹，后患无穷
所以现在回头看，Swift 如果未在 ABI 稳定前被引入，一直用的 OC，那压根不会有这样的问题
之前有人吐嘈银行技术栈太过陈旧，如相比于互联网普遍采用的 JSON, 银行的数据格式大都是万能不变的 XML 等
其实对于银行来说可以理解，毕竟是金融，要以稳定为主，重构几下代码是好看了，但由于历史遗留问题可能会有技术债，一不小心出现问题如金额对不了的问题就悲剧了，所以真的别炫技术，技术这东西够用就行！
最后，问题已经出现了，抱怨解决不了问题，那我们该如何解决呢
这里我想简单介绍一下我是如何修改以让老项目在 Xcode 15 上跑起来的
其实运行一个项目与大家熟悉一个项目或者说业务的思路都是相通的，抓大放小, 抓主线，跑通主流程，细枝末节之后再看
老项目无法在最新的 Xcode 15 上跑主要原因是 Pod 中的 Swift 引用了 OC 中的类，那我可以先注释这些逻辑，等跑通后再看看怎么优化
再比如有个防反编译的第三方库，发现它的存在也会导致项目无法启动，怎么也绕不过去，于是直接把它干掉，安全，相比于 app 不能启动这事不是那么重要，这问题可以等 app 跑起来后再想办法补
碰到难题，不要想着硬碰硬，可以绕过去的，千万不要在细枝末节上死磕，捡了芝麻，丢了西瓜
此外碰到问题千万不要慌，要冷静分析，比如项目在 Xcode 15 跑起来后，我发现几个 weex（一种跨平台框架）页面的展示有些错乱，如下
图片
看到这个页面第一眼我想的是得用 H5 来重构了，但用 H5 重构，工作量比较大，有没其他的方法？
我发现这个页面其实并不是每个 UI 都是错乱的，只是少数几个 UI 的渲染有问题，那就可以分析一下这几个出问题的 UI 和其他正常显示的 UI 在 weex 的写法有哪些区别，于是经过分析发现是三元运算符还有 text 的写法有区别，经过改造，问题就解决了，相比于使用 H5 来重构的时间，这点时间几乎可以忽略不计
