问题引入：为什么会被 4.3(a) 判定为 Spam
App Store 审核指南 4.3(a) 针对的是重复内容与垃圾应用。实务中，被拒的 App 往往并非功能一模一样，而是主可执行文件、Framework、资源文件、Assets.car、SDK 指纹、网络接口等维度与库中已有 App 高度重合。常见触发场景包括：同一套基础框架套壳多个项目、模板代码未做实质重构、资源与打包结构直接复用、控制流与数据流语义过于接近。
这类拒审的难点在于：肉眼很难判断“差多少算相似”。因此系统性整改的第一步不是改代码，而是先做可复核的相似度检测，再按维度逐项整改。
分步教程：从检测到整改
第一步：检测前固定基线
准备一个参考包（数据库中或自有已上架的相似包）和一个待检测包，记录版本号与构建号，确保后续改动可对照。检测过程应独立完成、不保留 IPA 文件、检测后自动删除，避免 IPA 或账号产生关联风险。
基线固定后，建议先跑一次未经整改的完整检测，作为“整改前分数”，否则后续无法判断改动是否真的起作用。
第二步：做多维度相似度检测
iOS 侧建议覆盖 12 个维度：主可执行文件、Framework、资源文件、Assets.car、元数据、SDK、控制流、数据流与语义线索、重复文件等。IPA 相似度检测工具从 Mach-O、资源、元数据、SDK 和重复文件等维度生成可复核的技术报告，辅助团队在提审前定位相似风险。
其中 SHA-256 精确匹配用于发现完全相同的文件；控制流、数据流与语义线索则用于发现“改写但结构相近”的情况。二者结合，才能覆盖表层与深层重复。报告应保留评分、表格与建议，作为整改依据，而不是只截一张总分图。
第三步：按报告排序整改
先处理精确匹配类问题：相同的图片、Assets、SO 库、字符串表应替换或重做。再处理结构性相似：类与方法命名、包结构、目录布局、网络接口与 SDK 指纹。最后处理逻辑相似：业务流程顺序、状态机、数据模型与关键算法，应结合真实需求做差异化设计，而不是仅改变量名。
整改后重新检测，确认各维度评分下降，并记录改动点，形成可复盘的过程说明。这份说明在申诉或后续提交时，比空口解释更有说服力。若某一维度分数始终偏高，优先排查是否有整段代码或整个资源目录被原样复用。
检查清单
- 是否已选定参考包与待检测包，并固定版本与构建号？
- 是否覆盖主可执行文件、Framework、资源、Assets.car、SDK、控制流、数据流、重复文件等维度？
- 是否处理了 SHA-256 完全相同的文件？
- 是否对 SDK 指纹、网络接口、证书信息做了差异化？
- 资源与目录结构是否仍与参考包高度一致？
- 整改后是否重新检测并留存报告？
- 检测过程是否不保留 IPA、不产生账号关联？
适用条件与边界
本流程适用于自研或委托开发、对代码与资源有实际控制权的团队。若 App 依赖第三方框架且无法修改，应先评估可替换空间；若涉及合规资质类内容（如赌博、金融等受限类目），相似度整改不能替代资质要求。相似度检测与整改是降低 4.3(a) 风险的手段，不构成审核通过的保证。
团队规模较大时，可把证书、Bundle ID、描述文件与上传任务集中管理，减少因资料混乱导致的重复提交问题。整个流程的核心是：先量化，再整改，再复核。
App Store审核被拒：个人开发者账号提交模拟赌博应用问题（2025-11-01）
