iOS老工程里那些报错但能跑的 Pod,先分三档再决定换不换

CONTENTS · 目录

打开 Xcode，Pods 那一栏红了三十多条，按一下运行，App 该起来还是起来了。

这种状态最难办。说它坏了吧，功能一个不少；说它好吧，每次编译都有一屏红字从眼前刷过去。修，不知道从哪儿下手；不修，心里一直悬着。

老工程里这种情况特别多。Flutter 的老工程有，纯 OC 的老项目更多 —— 那些 2014、2015 年拉进来的库，作者可能早就不写代码了，它们还在你的 target 里一天编译三遍。

这篇不劝你全修，也不劝你全换。先花半小时把每个 Pod 的状态摸清楚，再决定动谁。判断有方法，找下家也有顺序，下面挨个说。

一个老工程能跑到哪一步，其实有四道关：

第一道，debug 能编译、能装到手机上。

第二道，release 能出包。

第三道，archive 能上传到 App Store Connect。

第四道，审核能过、能上架。

「报着错但还能跑」，绝大多数时候是卡在第一道门口 —— 编译器在喊，产物照样出来了。真正要命的是第三道和第四道，那两道不看你本地跑得多欢。

— 报着错但还能跑 ＝ 卡在第一道门口

所以第一个动作不是修，是确认自己现在站在第几道关。方法很土但有效：清一次缓存，换一台没跑过的机器，从头 pod install，再 archive 一次。

判断一个库还能不能留，第一个要看的不是它报什么错，是它上一次发版是什么时候。这个信息不用猜，CocoaPods 的库页面上就写着，字段叫 Last Release。

这三个我都在老工程里撞见过，摆一起看特别清楚：

同样是编译报错，这三个库的命完全不一样。

YYText 报错，你只能自己动手改，改完还得想办法让这个改动活过下一次 pod install（怎么让它活过去，上一篇有完整写法）。

SDWebImage 报错，去仓库提个 issue，等下一个补丁版本就行。

AFNetworking 报错，官方 2023 年 1 月就在 README 开头写了弃用，迁移方向指向 Alamofire。

— 三个信号合起来看，才能定档

所以看到报错的第一件事，是去查这个库上一次发版。三个月内动过、一年内动过、十年没动过，这是三种完全不同的处境。

苹果有一份公开列表，叫常用第三方 SDK。这份清单从 2024 年 5 月 1 日起有个要求：提交新 App 时带了名单上的 SDK，或者某次更新里新加了一个，就得同时带上隐私清单；二进制形式引入的还要有签名。老工程里早就装好的库，这次没新增就暂时不在这个要求里。

名单里有一堆我们熟得不能再熟的老家伙：AFNetworking、Reachability、MBProgressHUD、SDWebImage、FMDB、IQKeyboardManager、SVProgressHUD、Toast、SwiftyJSON、SnapKit。

YYText 和 Masonry 不在名单上。

这张表和「上游还活着没有」放在一起看，能得出一张四象限：

— 在名单上且停更，是四象限里最麻烦的一格

最麻烦的是在名单上且已经停更。Reachability 就是典型：它最后一个版本是 3.7.6，之后这个仓库基本就静默了，而它稳稳地在苹果的名单上。

这种库麻烦就麻烦在，它不会在编译时炸给你看。你的 App 天天跑得好好的，直到某天上传完，邮箱里躺着一封你没见过的 ITMS 邮件 —— 缺隐私清单是 ITMS-91061，二进制依赖缺签名是 ITMS-91065，用了需要声明原因的 API 却没写是 ITMS-91053。

同样是红字，位置不一样，性质差得远。

三个信号合起来看，每个 Pod 都能落进三档里。

第一顺位：系统原生 API。有官方替代的优先用官方的。Reachability 的替代就是 NWPathMonitor，iOS 12 起 Network 框架自带，不用引任何三方库，也不用担心隐私清单。

第二顺位：官方指定的继任者。AFNetworking 的 README 里写得很明白，后续走 Alamofire。官方自己指的路，迁移成本最低、坑最少。

第三顺位：社区活跃的 fork。有些库作者不维护了，但社区接了过去，补了隐私清单、修了新 SDK 的编译问题。用之前先看两件事：最近半年有没有提交，有没有人正经发过版本。

第四顺位：自己收编。源码拷进工程，或者做成内部 pod。这是最贵的方案，因为维护成本从此归你。

— 顺位越往后，维护成本越归自己

Flutter 的老工程好歹还有条迁移路 —— 虽然插件底下那层原生 SDK 还得等上游，但至少官方给了工具，跑一次能自动改掉一大半。

纯 OC 的老项目没这个待遇。它的依赖树是一层一层长出来的，很多库当年是手动拷进工程的，后来才包的 pod，现在想动一个，牵出来一串。

老 OC 项目的实际做法，我建议三步。

第一步，先做一次体检，别急着改代码。pod outdated 看一眼哪些落后了，再逐个去 CocoaPods 页面抄下 Last Release 的日期。十个库大概二十分钟，做完你对整个工程的健康状况就有数了。

第二步，按「能不能用系统 API 替」排序，不按报错数量排。能用系统 API 替的排最前面，因为这类替换是净减法 —— 少一个依赖，少一份隐私清单，少一个升级时要盯的东西。

第三步，换不动的，用 post_install 收口。上一篇讲过这个思路：不改三方库源码，也不改业务源码，把该压的诊断、该关的开关、该补的括号，全写进 Podfile 的钩子里，让每次 pod install 自动生效。

说到底，红字只是症状。真正该问的是，这个库上游还有没有人管。

编译器的红字其实算客气，它趁你还来得及的时候喊一嗓子。真等上传完收到那封 ITMS 邮件，就不是改几行代码的事了。

那些报错但还能跑的 Pod，不是没问题，是问题还没到期。

平时写点移动端踩过的坑，也顺手记记奶爸的时间账，偶尔聊点别的。

你们项目里活得最久的那个 Pod 是谁，最后一次发版是哪年？评论区报个数，我看看哪个工程的岁数最大。

我是码蜂奶爸，写的都是自己踩过的坑。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

#iOS #CocoaPods #老工程 #Pod #技术债 #OC #Flutter #踩坑记录

参考资料

[1] Apple《Third-party SDK requirements》（常用第三方 SDK 清单；隐私清单与签名要求自 2024-05-01 起，适用于提交新 App 或更新中新增的清单内 SDK）：https://developer.apple.com/support/third-party-SDK-requirements/。AFNetworking、Reachability、MBProgressHUD、SDWebImage、FMDB 等均在名单内；YYText、Masonry 不在。

[2] AFNetworking 官方弃用声明（2023-01-17，含迁移到 Alamofire 的建议）：https://github.com/AFNetworking/AFNetworking。原文「As of Jan. 17, 2023, AFNetworking is deprecated and there will be no further releases」。

[3] YYText 在 CocoaPods 上的库页面（1.0.7，Last Release 2016-09）：https://cocoapods.org/pods/YYText。

[4] SDWebImage 版本记录（5.21.7，2026-02-26；5.21.1，2025-06-10，标题为 Xcode 26 Compatible）：https://github.com/SDWebImage/SDWebImage/releases。

[5] Apple《Network framework》中 NWPathMonitor 文档（iOS 12 起可用）：https://developer.apple.com/documentation/network/nwpathmonitor。

[6] CocoaPods《Podfile Syntax Reference》（post_install 钩子语法）：https://guides.cocoapods.org/syntax/podfile.html。

[7] CocoaPods 官方博客《CocoaPods Trunk Read-only Plan》（2025-05 更新，计划 2026-12-02 起 trunk 永久只读）：https://blog.cocoapods.org/。

[8] Apple Developer《Privacy updates for App Store submissions》（2024-03-13 起邮件提醒、2024-05-01 起需提供批准原因）：https://developer.apple.com/news/?id=3d8a9yyh。