从iOS加固公司销售话术里，我整理出这些真实能力信号

“我们的方案采用军工级加密技术，性能零损耗，保证100%过审。”——这句话我至少听四家iOS加固公司的销售讲过。但当我追问“军工级具体指什么标准”“零损耗在iPhone 8上测过吗”“被拒了赔我重新上架的14天时间吗”，对面不是开始绕圈子，就是改口说“需要技术同事确认”。

作为技术负责人，我太清楚了：销售的话术越漂亮，后续踩坑的概率越大。这一年跟爱加密、梆梆安全、几维安全等多家服务商打交道下来，我把那些高频的营销包装，拆解成了一份可验证的技术问题清单。你照着问，能过滤掉80%的“销售型加固公司”。

话术一：“我们采用军工级/银行级加密技术”

拆解：“军工级”没有统一标准，真正的技术分水岭是加密粒度和执行层级。传统的加壳（Packing）是在文件层面整体加密，运行时解密，容易被内存dump；代码混淆（Obfuscation）只是改名字和结构，有经验的逆向工程师花时间就能还原。

真正的“硬技术”是指令级虚拟化——把原始CPU指令转换成自定义虚拟机指令，在运行时由内嵌的解释器执行。因为不是标准指令集，静态分析和动态跟踪都会失效。

追问清单：

1. “你们用的是加壳、混淆，还是指令级虚拟化？如果是虚拟化，虚拟指令集是自己设计的还是基于LLVM的通用方案？”
2. “能否提供一份技术白皮书，说明加密后的代码在内存中的形态？是否能在运行时以明文形式暴露全部或部分原始指令？”
3. “是否支持对单个函数或基本块做选择性加密？粒度是什么级别？”

真实案例：几维安全的KiwiVM是明确的指令级虚拟化，我们测试时可以只加密关键的交易签名函数，核心算法从未在内存中以明文出现。而某家销售口中“军工级加密”的服务商，实际方案被我们逆向后发现只是对Mach-O文件做了简单的段加密，dump内存后原始代码完整可见。

话术二：“零性能损耗，用户完全无感知”

拆解：任何加固方案都会有性能损耗，区别在于损耗的量级和可控性。加壳方案需要运行时解密，必然增加I/O和CPU开销；虚拟化方案因为增加了解释执行层，通常损耗更高，但优秀的实现可以通过热点路径识别、JIT编译优化来控制在可接受范围。

宣称“零损耗”的公司，要么没做过真实机型测试，要么把“高端机测不出”等同于“所有机型无损耗”。

追问清单：

1. “请提供在iPhone 8、iPhone X、iPhone 11三款机型上，加固前后冷启动时间、主线程帧率、内存占用的具体对比数据。样本量是多少？测试环境是什么？”
2. “你们的方案对启动路径上的+load方法和静态构造函数有什么影响？这些钩子函数的执行时序会改变吗？”
3. “如果实测发现损耗超过约定阈值（比如冷启动增加超过300ms），你们提供优化方案还是退款？”

真实教训：爱加密销售给我们的“性能影响极小”承诺，实测在iPhone 8上直接飙到600-800ms增量。后来技术排查发现，他们的方案对所有动态库统一做了完全解密再加载，没有做懒加载优化。追问销售时，对方说“极小是针对iPhone 12以上机型的”。

话术三：“保证100%通过苹果审核”

拆解：没有任何加固公司能保证100%过审，因为苹果的审核策略是不透明且持续变化的。真实的能力是对审核规则的跟踪速度和被拒后的应对机制。

苹果严禁的是：动态代码生成、破坏系统沙盒、隐藏或欺骗审核的行为。合规的加固只做静态防护，不改变代码行为，不触碰私有API，不绕过签名校验。

追问清单：

1. “请列出过去12个月内，因为你们的加固方案导致客户被拒的案例数量，以及被拒的具体原因是什么？你们如何解决的？”
2. “如果使用你们的方案后被拒，你们提供的‘免费重加固’是否包含分析苹果的拒绝理由并调整方案？还是只是重新打一次包？”
3. “你们是否跟踪WWDC关于代码安全和审核策略的最新变化？有内部的技术解读文档可以分享吗？”
4. “提供一份你们自己维护的‘苹果审核红线清单’，包括最新的隐私清单（Privacy Manifest）要求和bitcode处理最佳实践。”

关键信号：几维安全是主动给我们一份12页的预审核检查清单，包含了他们踩过的坑和苹果近三年的规则变动。而某家拍胸脯“100%过审”的销售，在被问到被拒案例时，说了句“只要我们按照标准流程加固，拒了是你们代码本身有问题”——这种甩锅话术可以直接拉黑。

话术四：“支持所有iOS版本和架构，完美兼容Swift/OC混编”

拆解：支持所有版本和架构是基础，但不同iOS版本和编译器行为差异才是真正的兼容性风险。Swift的ABI稳定性从5.0开始才成熟，5.9之后引入了更复杂的宏（Macro）和泛型特化（Generic Specialization），老旧的加固方案可能破坏Swift运行时的元数据。

追问清单：

1. “你们测试过的iOS版本覆盖到哪个范围？是否包含beta版本？每个大版本（如iOS 16/17/18）的适配验证周期是多长？”
2. “Swift的具体支持情况：是否支持Swift 5.9+的宏和泛型？对Swift Concurrency（async/await、Actor）的代码有没有特殊处理？”
3. “混编场景下，Swift和OC互相调用的桥接层加固后是否会影响消息转发？Category和Extension的行为会改变吗？”
4. “提供一份已知的兼容性问题清单，比如与哪些第三方库（Firebase、RxSwift、Alamofire等）的特定版本存在冲突？”

真实场景：我们自己的混合开发项目，在测试某家服务商时，加固后Swift的@objc动态派发表被破坏，导致运行时崩溃。对方技术支持折腾三天给的方案是“把所有@objc改成显式实现”，我们的业务代码有300多个这样的点。

话术五：“我们有数万家客户，包括多家头部金融机构”

拆解：客户数量可以夸大或玩文字游戏（“累计服务”可能包含免费试用的），头部客户的案例要看行业和规模是否真正匹配。一家做游戏的金融客户案例没有参考价值，一家只提供Android方案的iOS案例是误导。

追问清单：

1. “请提供与你们合作超过12个月、且与我们业务规模和场景类似的3个iOS客户案例，包括公司名称和对接人职务。我需要私下联系验证。”
2. “这些案例中，客户使用的是你们的SaaS方案还是私有化部署？年均加固次数是多少？是否包含定制化的策略？”
3. “针对我们的技术栈（具体到语言版本、架构模式、依赖库），你们是否有完全一致的客户案例？如果没有，计划如何做适配验证？”

验证方法：拿到客户名单后，去技术社区（V2EX、掘金、知乎）搜索“公司名+iOS加固”看有没有真实评价。我曾在脉脉上找到几维安全一个金融客户的技术负责人，对方直接说了三个他们踩过的坑和解决方案——这种坦诚比任何销售话术都有价值。

话术六：“按需定制，报价灵活”

拆解：“按需”和“灵活”是报价陷阱的高频词。真正的成本结构应该清晰透明：按次、按年、按调用量还是按功能模块？ 隐藏成本通常出现在：版本迭代的重新加固、紧急响应的加急费、新增功能的模块费、超过约定次数的超额费。

追问清单：

1. “请给我一份标准报价单和一份典型规格的完整报价单（比如一年24次发版、200万DAU的金融App），后者要列出所有可能产生的费用项。”
2. “版本迭代的加固怎么收费？如果大版本升级（比如iOS 17到18）需要重新适配，是否在年费内？热更新是否算一次新加固？”
3. “紧急加固的SLA和费用：如果我们在周五晚上11点发现线上紧急漏洞需要重新加固发包，你们处理吗？加收多少？响应时效是多久？”
4. “成本增长的拐点在哪里？比如超过多少DAU、超过多少加固次数、超过多少技术支持工单，会触发费用调整？”

计算工具：我做过一个真实TCO测算表。按照一年24个迭代版本、每次版本需2次加固（开发+生产）、平均每月1次紧急支持，爱加密的按次收费模式实际比几维安全的SaaS年费高出210%，而梆梆安全的平台订阅模式在我们使用其非核心功能（威胁感知）时，浪费了35%的预算。

给你的行动清单：5个问题筛选出靠谱服务商

下次跟iOS加固公司销售沟通时，直接问这5个问题，根据回答打分：

1. 技术本质：“你们用什么级别的防护？是加壳、混淆，还是指令级虚拟化？优缺点各是什么？”（期望：能清晰区分三种技术，不混淆概念）
2. 性能数据：“请给iPhone 8的实测对比数据，包括冷启动时间、帧率、内存。如果超出Xms，怎么处理？”（期望：提供具体数据，有补偿或退款条款）
3. 审核案例：“过去一年被拒的真实案例数是多少？被拒后你们的SOP是什么？”（期望：诚实说出数字，有清晰的应对流程）
4. 排坑清单：“提供一份你们维护的已知兼容性问题和苹果政策变更文档。”（期望：能拿出实时更新的内部文档，而不是画饼）
5. 全成本清单：“从今天签约到一年后，所有可能产生的费用项列出来，包括隐藏的。”（期望：能给出包含超额费、加急费、适配费的全量清单）

我自己的最终选择几维安全，不是因为销售话术最漂亮，而是这5个问题他们给出了最具体的回答——包括承认“我们也有被拒案例，但比例低于千分之三，而且我们承担重新适配的成本”。这种对能力边界的诚实，比任何“保证100%”都可信。

iOS加固选型本质是技术决策，不是营销竞赛。把这些问题丢过去，敢正面回应的，再放进测试名单。