先交代一句背景做iOS开发的人十有八九都见过4.3。就差把“你这个包跟别人长一样”写在你脸上。尤其是做马甲包、做矩阵产品的团队4.3就是绕不过去的一道坎。这篇东西不写什么玄学申诉话术就讲我在5天时间内从4.3被拒到顺利过审的完整操作重点放在代码混淆和二进制差异化上标题里写了“附完整代码混淆方案”我就把能直接抄的部分都贴出来。1. 4.3审核到底在审什么很多人一看到4.3就开始焦虑觉得苹果是故意卡你其实4.3还真不是“人工看你不顺眼”这么简单。4.3的全称是“Spam”也就是垃圾信息。苹果的审核机制里4.3既可能是机审判断也可能是人工审核结论大多数时候是两者叠加的结果。先说机审。App Store对提交上来的是个安装包会做静态分析、动态分析和特征比对。苹果会提取你App的二进制特征、资源文件列表、代码字符串、类名、方法名、URL Scheme、Bundle ID的关联信息等等然后跟商店里已有的App做相似度比对。如果你的App和另一个App的代码结构高度相似或者类名、框架引用路径都一样机审这一关就会直接标记。再说人工审核。哪怕你机审过了到了人工那边审核员也会快速扫一眼你的界面、功能、文案、整体观感。如果两个App的界面布局几乎一致、功能点完全对应、连文案都差不多人工审核大概率也会直接判4.3。所以在实际处理中“马甲包过审”这件事本质就是两个维度同时发力一是二进制层面的差异让人一眼看不出、机器比对也匹配不上二是产品层面的差异让人工觉得这是另一个独立的应用。两个维度缺一个都容易被判死。我在这次项目里遇到的情况很典型主包已经上架产品想要做一个新包功能有80%重叠但定位不同面向的人群也不同。第一次提交的时候我就改了个Bundle ID、换了个图标、改了几个文案就扔上去了结果毫无悬念被4.3干回来。从那时候开始我就把“代码混淆”和“资源混淆”当成了正式流程来做而不是事后补救。2. 5天过审的时间规划和整体思路时间紧是常态尤其是做马甲包的项目往往是在主包运营起来之后才临时决定要拓展渠道留给开发的窗口就那么几天。我这边的5天安排是这样拆的第1天全量梳理差异点制定混淆方案完成工程结构改造。第2天完成代码层混淆改造重点处理类名、方法名、字符串、网络接口特征。第3天完成资源层混淆包括图片资源重命名、Assets目录调整、启动图/图标重做同时处理界面层面的差异化。第4天完成提交材料准备包括截图、描述、关键词、隐私政策等并做一次完整的自查。第5天提交审核做一版备用方案准备同时准备申诉材料。这个时间安排的核心逻辑是代码混淆和资源混淆并行推进界面差异化和文案差异化同步做不要等代码全部改完了再动UI那样时间肯定不够。另外一个很重要的认知是4.3并不要求你跟主包“完全不同”只需要让审核方觉得“这是另一个独立的东西”。所以我在做差异化的过程中始终看的是“相似度”这个词而不是“完成度”。不是要你把功能全砍了而是把看起来像、听起来像、用起来像的地方都做足够的区分。实际操作中我给自己定了一个简单的判断标准如果我把两个App放在同一部手机上截两张图发给我一个没见过这两个产品的朋友他能不能一眼看出这是两个App如果能那这个包基本就具备过审的基础。如果连我们自己人都觉得“这不就是换了个皮嘛”那审核员也会这么想。3. 代码混淆完整方案代码混淆这个东西很多人第一反应是“加壳”或者“用工具跑一遍”。但我可以负责任地说iOS项目做混淆跟Android不太一样。iOS没有像ProGuard那样成熟的内置混淆工具而且App Store审核对动态加载、反射调用、代码注入检查得比较严格花里胡哨的混淆方案容易适得其反。我用的方案是“源码层混淆 编译期脚本处理”的组合兼顾了稳妥和效果。3.1 类名和方法名混淆类名和方法名的混淆是二进制差异化的第一层也是最容易被机审命中的点。如果你的新包和线上老包有一堆同名同结构的类那基本就是送人头。工程级的做法是批量重命名。比如把项目里所有跟业务含义强相关的类名改成无意义的随机字符串同时保持逻辑不变。这里有一个关键的坑直接用Xcode的Refactor重命名速度慢而且容易漏掉字符串引用、KVC调用、Nib绑定这些隐藏点。我的做法是写Python脚本对源代码做批量替换。下面是这次用的方法名混淆脚本Python实现负责把指定的类名、方法名替换为随机字符串并自动更新所有引用位置import os import re import random import string # 定义需要混淆的类名映射 # 键为原类名值为随机生成的新类名 class_mapping { LoginViewController: XKJwPwzE A1, UserProfileManager: QmNjHdaT B2, NetworkService: LpRwZsUv C3, OrderDataController: NfVcXyQa D4, PaymentHelper: HgTyUioP E5, } # 定义需要混淆的方法名映射 method_mapping { loginWithAccount:password:: pXkLwQzr, fetchUserProfile: wMzHnVbA, submitOrder:: kRcJfXyq, processPayment:: vLnBdUwZ, } def random_string(prefix, length8): 生成随机的类名/方法名保持可读性和唯一性 chars string.ascii_letters string.digits return prefix _ .join(random.choice(chars) for _ in range(length)) def process_swift_file(file_path): 处理单个Swift文件替换类名和方法名 with open(file_path, r, encodingutf-8) as f: content f.read() # 替换类名注意处理继承和实现协议的情况这里做了简单匹配 for old_name, new_name in class_mapping.items(): content re.sub(r\b re.escape(old_name) r\b, new_name, content) # 替换方法名仅在方法定义和调用位置替换 for old_method, new_method in method_mapping.items(): # 处理类似 func oldMethod( 的定义 content re.sub(r\bfunc\s re.escape(old_method), func new_method, content) # 处理调用点例如 self.oldMethod( 或 .oldMethod( content re.sub(r(?[\.\s]) re.escape(old_method) r(?\(), new_method, content) with open(file_path, w, encodingutf-8) as f: f.write(content) def walk_and_process(root_dir): 遍历项目目录处理所有Swift源文件 for dirpath, _, filenames in os.walk(root_dir): for filename in filenames: if filename.endswith(.swift): file_path os.path.join(dirpath, filename) print(fProcessing: {file_path}) process_swift_file(file_path) if __name__ __main__: project_root ./YourProject/Sources walk_and_process(project_root)这个脚本的核心作用是降低人工改动的工作量。你要做的事是先把整个工程的类名清单、方法名清单拉出来人工筛选“哪些是必须保留的”比如UIApplicationDelegate入口、系统回调方法剩下的都交给脚本去处理。这里有几个坑需要提醒第一个坑是Swift的访问控制。如果类被定义为internal或者private改名后可能影响模块间的调用关系。我的方案是统一检查编译报错报一个改一个确保最终能跑通。第二个坑是Nib和Storyboard。如果你用了Xib绑定类名在Interface Builder文件里也有引用只改代码文件会造成运行时crash。所以需要额外写一个针对.xib和.storyboard文件的替换逻辑把customClass字段同步改掉。第三个坑是字符串引用。比如你用了NSClassFromString(LoginViewController)这种动态加载方式类名是以字符串形式存在的单纯的代码替换改不到这些。我的处理方式是全局搜索所有NSClassFromString、NSSelectorFromString调用统一改成宏定义方式管理。3.2 字符串加密字符串是机审重点扫描的对象。如果你的App里包含一些很典型的词比如接口URL、API Key、SDK接入信息、支付回调地址等机审工具能直接通过字符串匹配的方式找出你和其他App的相似之处。我的方案是做一个字符串加密工具把项目中所有需要保密的字符串统一改为运行时解密不在二进制里保留明文。下面是一个简易的字符串加密示例Objective-C实现// RuntimeDecrypt.h #import Foundation/Foundation.h interface NSString (RuntimeDecrypt) // 解密函数key是混淆密钥data是加密后的密文 (NSString *)decryptWithKey:(NSString *)key data:(NSData *)data; end// RuntimeDecrypt.m #import RuntimeDecrypt.h #import CommonCrypto/CommonCryptor.h implementation NSString (RuntimeDecrypt) (NSString *)decryptWithKey:(NSString *)key data:(NSData *)data { char keyPtr[kCCKeySizeAES256 1]; bzero(keyPtr, sizeof(keyPtr)); [key getCString:keyPtr maxLength:sizeof(keyPtr) encoding:NSUTF8StringEncoding]; NSUInteger dataLength [data length]; size_t bufferSize dataLength kCCBlockSizeAES128; void *buffer malloc(bufferSize); size_t numBytesDecrypted 0; CCCryptorStatus status CCCrypt(kCCDecrypt, kCCAlgorithmAES128, kCCOptionPKCS7Padding, keyPtr, kCCKeySizeAES256, NULL, [data bytes], dataLength, buffer, bufferSize, numBytesDecrypted); if (status kCCSuccess) { return [[NSString alloc] initWithBytes:buffer length:numBytesDecrypted encoding:NSUTF8StringEncoding]; } free(buffer); return nil; } end使用方式是把接口URL和敏感字符串用AES加密编译时直接写密文运行时再解密// 原明文https://api.example.com/v1/user/info // 加密后密文示例 NSString *encryptedBase64 U2FsdGVkX19yXb4QnFhBpM3jVX5pR0aB7cC8eW1fY; NSData *encryptData [[NSData alloc] initWithBase64EncodedString:encryptedBase64 options:0]; NSString *decryptedURL [NSString decryptWithKey:your-encrypt-key data:encryptData]; NSLog(Decrypted URL: %, decryptedURL);字符串加密这块我要额外强调一点不要只盯着URL加解密还要关注本地化文案。很多团队的马甲包连App内的文案字符串都跟主包一样人工审核一眼就看穿了。所以字符串混淆方案里必须包含一个步骤把App内所有面向用户的文案重新写一遍至少要做到“不是简单同义词替换”而是“换一种说法”。我这次是把整个App的本地化字符串全部导出来重写了大约70%的文案。关键按钮的文案、页面标题、提示信息、隐私政策摘要全部调整过。剩下30%属于系统级的通用文案比如“取消”“确认”“加载中”苹果不会因为这些判你重复。3.3 逻辑混淆与控制流变形字符串加密解决的是“让机器看不懂字符串”代码逻辑混淆解决的是“让机器看不懂代码结构”。这一步主要是为了对抗静态扫描工具的分析。但这个环节我们团队内部争议比较大。原因在于过度的逻辑混淆会增加代码的维护成本而且如果使用了比较复杂的技术比如在启动时动态加载代码、用JavaScriptCore跑脚本反而可能触发苹果的“代码注入”检查最终被判定2.1大礼包。所以我的策略是适度的控制流扁平化不做动态加载。具体做法有两种一种是在编译前对源码做预处理把顺序执行的代码块打乱顺序然后通过switch-case跳转恢复执行路径。这种方式能在二进制层面制造出“代码结构差异”但又不会改变实际运行结果。另一种做法是插入无效代码块和无意义逻辑。比如在关键方法里插入一段不会被执行的循环或分支让静态分析工具在追踪代码路径时产生歧义。但要注意无效代码不能太明显否则会被人工审查看出来。这里给一个简单的控制流混淆示例用最笨的方式让代码路径变得不那么直观- (NSInteger)calculateUserLevel:(NSInteger)score { NSInteger level 0; NSInteger tempValue 0; // 插入一段无实际业务含义的干扰逻辑 int randomSeed (int)[[NSDate date] timeIntervalSince1970]; for (int i 0; i 3; i) { tempValue (score 0xFF) i; } tempValue tempValue % 7; // 用switch结构替代简单的if-else提升代码路径复杂度 NSInteger scoreBlock score / 100; switch (scoreBlock) { case 0: case 1: level 1; break; case 2: case 3: level 2; break; case 4: case 5: level 3; break; default: level 4; break; } // 插入一个永远不会执行到的分支 if (tempValue 10 randomSeed 0) { level 100; } return level; }这种做法的好处是改动成本低不需要引入额外的编译链工具。缺点是对抗“同功能代码特征比对”的效果有限毕竟核心逻辑还在。所以我一般把这种方法定位为“辅助手段”真正的主力还是类名方法名混淆和资源混淆。4. 界面资源差异化的关键操作代码混淆是过机审的关键但真正决定你能不能在人工审核环节活下来的是界面资源差异化。很多人做马甲包喜欢“换皮不换里”也就是只改一个主题色、换几张图片界面布局和创新度一摸一样。这种情况下人工审核员只要打开App截几张图跟线上版本对比基本就凉了。我的经验是界面差异化要做到“看起来像两个团队做出来的产品”。4.1 UI布局层面不能只改颜色要改布局。同一个功能页面主包用的是列表形式新包就可以改成卡片形式或者把入口从底部Tab栏移到首页右上角。这样做的好处是截图对比时审核员无法把两种不同布局的页面直接对应起来。但这里有个度的问题马甲包毕竟要承接主包的核心功能不可能把页面全部重做。我的做法是优先差异化“第一屏”和“核心功能页”。第一屏决定了审核员的第一印象核心功能页决定了审核员能不能发现这是一个“功能重复”的App。至于那些非核心页面比如设置、关于、帮助布局微调一下就行了。4.2 图标与启动页图标和启动页是审核员在还没打开App之前就能看到的东西。这里必须做到完全不同。不仅仅是颜色不同而是图形设计和视觉风格都要重新出图。启动页建议不要用单纯的品牌Logo加背景色而是做成活动运营页或内容展示页一是视觉上拉开了差异二是后续审核员从截图进入App时更不容易判断出功能结构上的雷同。4.3 图片资源的二进制差异化这个环节很多人会忽略。假设你从主包里直接复制了一张按钮背景图到新包哪怕你把这张图从btn_bg.png改名为login_btn_bg.png它的二进制内容跟主包里那张图是一样的机器比对时会直接把两张图的hash值匹配出来。我这次的方案是所有从主包复制的图片资源全部经过一个图片处理脚本做“微调”包括非常轻微的缩放、改变图片的压缩率、调整RGB通道做颜色偏移。这样二进制的hash值完全变了但肉眼看起来几乎没有差异。这里我贴一个图片批量处理的Python脚本用Pillow库实现可以在打包前对图片资源做一次“无感变化”from PIL import Image import os import hashlib def image_hash(img): 计算图片的感知哈希值 img img.resize((16, 16), Image.LANCZOS).convert(L) avg sum(list(img.getdata())) / 256 return .join(1 if p avg else 0 for p in img.getdata()) def process_image(input_path, output_path): 对图片做轻微改动改变二进制hash但保留视觉原样 img Image.open(input_path).convert(RGB) # 1. 将图片尺寸缩放至原来的 99.5%避免在比例上出现明显差异 w, h img.size new_w int(w * 0.995) new_h int(h * 0.995) img img.resize((new_w, new_h), Image.LANCZOS) # 2. 调整亮度亮度偏移量控制在 ±2% 以内 from PIL import ImageEnhance enhancer ImageEnhance.Brightness(img) img enhancer.enhance(0.99) # 3. 调整色相饱和度对每个像素的RGB通道做微量偏移 r, g, b img.split() r r.point(lambda i: max(0, min(255, i 1))) g g.point(lambda i: max(0, min(255, i 1))) b b.point(lambda i: max(0, min(255, i - 1))) img Image.merge(RGB, (r, g, b)) # 4. 用不同的压缩质量重新保存PNG可改为JPEG或降低/提高PNG压缩等级 if output_path.endswith(.png): img.save(output_path, PNG, optimizeTrue) else: img.save(output_path, JPEG, quality85) return image_hash(img) if __name__ __main__: source_dir ./source_images output_dir ./output_images os.makedirs(output_dir, exist_okTrue) for root, _, files in os.walk(source_dir): for file in files: if file.lower().endswith((.png, .jpg, .jpeg)): src os.path.join(root, file) dst os.path.join(output_dir, file) h process_image(src, dst) print(fProcessed {file} - perceptual hash: {h})图片处理的关键在于不能改到让设计师“看不下去”的程度也不能一点不改。微调幅度保持在肉眼不可察觉的范围内但机器的二进制指纹已经完全对不上了。4.4 音频、视频和配置文件如果App里使用了音频、视频资源这些也要做同样的处理。最简单的方式是改变编码参数比如音频转为AAC格式视频转换码率和分辨率哪怕只改一点点二进制指纹就会变。另外plist配置文件里的内容凡是跟主包有重叠的地方都要重新写。比如权限描述文案不能跟主包一字不差要换一种表达方式。隐私政策URL、技术支持URL这些都是审核员会实地访问的资源一定要确保域名不同、页面内容不同。5. 提交流程中的隐藏加分项代码和资源都处理完之后提交流程本身也有很多可以优化的地方。很多人把4.3完全归结为技术问题其实提交流程里的操作往往能直接影响审核结果。5.1 版本号和Build号的独立性一个很常见的低级错误是新包沿用了跟主包相同的版本号。苹果内部系统在比对时版本号相同是两个App高度关联的信号。新包一定要用自己独立的版本号序列比如主包当前是2.1.0新包可以从1.0.0开始或者用1.1.0这种独立序列。Build号也是一样不能让新包的Build号跟主包连续。最好的做法是留出一段不连续的数字让系统无法通过Build号猜测两个包之间的关联。5.2 关键词和描述不要复制App Store的标题、副标题、关键词、描述这些文本内容会被苹果的搜索索引和机器审核系统抓取比对。如果你的新包描述跟主包有大量重复词语机审也很容易打出高分。我的做法是重新挖掘新包的目标关键词围绕新的定位来写描述。比如主包面向的是一二线城市年轻用户新包就可以定位为下沉市场用户关键词从“高效率”转为“简单易用”描述从功能列表转为使用场景故事。这不是让你夸大其词而是让整套文案看起来像另一个产品。5.3 登录方式与第三方SDK如果新包和主包都使用了同一套第三方登录SDK并且SDK的初始化参数比如AppID都一样那么审核系统在扫描SDK特征时就会判定两个App使用了相同的第三方接入信息。这是一个很容易被忽略的相似点。处理方案是新包注册全新的第三方平台AppID包括微信、QQ、微博、支付宝等不要复用主包已经注册好的账号。如果有自建账号体系建议换一套API域名和服务器配置至少做到逻辑隔离。5.4 隐私政策与用户协议的独立化隐私政策、用户协议这些法务文本很多团队是直接拷贝主包的。这非常危险。一方面审核员打开你的隐私政策页面看到产品名和网址都是主包的信息会直接产生怀疑另一方面苹果本身对隐私政策的要求非常严格你提交的隐私政策URL必须能正常访问并且要体现出“这个App是独立的运营实体”。我建议的做法是为每个包准备独立的隐私政策页面哪怕内容主体一样也要在文案措辞、公司名称、联系方式上做区分。这是合规的基础不只是过审的需要。6. 常见问题与避坑经验做马甲包过审这件事技术方案其实相对固定真正容易掉进去的坑反而是流程和细节上的。这次5天的实际操作中我碰到了一些值得记录的问题和对应的排查方式。6.1 混淆后编译报错怎么排查批量替换类名方法名之后编译报错几乎是必然的。尤其是OC项目里消息发送、方法调用的动态性很强一旦某个方法名被脚本替换漏了编译不报错但运行时会崩溃。我的排查方法是先做一次全量全局搜索把跟混淆名单相关的所有字符串都搜出来确认没有遗漏的硬编码引用。然后再编译编译报错了就按报错位置改。如果编译通过但运行崩溃打开Xcode的崩溃日志看崩溃栈里出现的是哪个类哪个方法反查混淆映射表把对应位置的调用改了。这里有一个非常重要的小技巧混淆脚本在生成新类名和新方法名时一定要生成一份“映射表”文档。这样将来要崩溃排查或者做版本回溯时能快速看明白代码里的pXkLwQzr对应原来的loginWithAccount:password:。6.2 审核被拒后如何找准申诉方向如果你按照上面的方案都做完了还是收到了4.3被拒的消息那大概率不是代码相似度的问题而是产品功能层面的“重复感”太强烈。这时候不要急着做技术层面的申诉而是先对比一下新包和主包的“用户视角”。你要想清楚一件事苹果审核团队认为你这是一个重复App核心依据是什么是界面布局太像是功能逻辑太一致还是产品定位都指向同一个用户场景我这次第一次被拒时就没搞清楚这一点提交了一堆代码混淆的技术说明结果被秒拒。后来冷静下来花了半天时间把新包的首页模块重新设计把一个核心Tab从底部挪到了顶部把首页的宫格入口改成了瀑布流信息流重新截图后提交才顺利过审。申诉模板不是万能的。你要在申诉里说清楚“为什么这不是一个重复App”而不是“我用了多少混淆技术”。审核员不是技术背景的人你跟他说代码混淆他理解不了你跟他说“我两个App面向的用户不同、解决的问题不同、使用场景不同”他才看得进去。6.3 时间不够时的最小可行方案如果你的时间连5天都不够比如只有2天那我的建议是砍功能不要砍差异化。保留新包最核心的2到3个功能其余功能全部隐藏或者是剪掉。这个做法有两个好处一是功能变少了跟主包的界面对比度自然就下来了二是提交材料里的截图和描述更好写审核员看的时候不容易产生“跟另一个App一样”的感觉。隐藏功能有个操作细节不要直接在代码里注释掉而是做服务端开关。新包提交审核时服务端下发的配置里只开启2个功能审核通过后再通过后台打开其他功能。这个方案在合规性上有一定风险但确实是行业里的常见做法。我不鼓励滥用但作为应急方案可以理解。6.4 审核通过后的注意事项审核通过不是终点而是另一个起点。苹果的后台系统会持续扫描已经上架的App如果发现两个已上线App的相似度异常高有可能会在后续做下架处理。所以即便过审了也建议在功能迭代时持续做差异化不要越改越跟主包像。特别是当你准备给新包发布版本更新时改动不要涉及主包已经高度差异化的部分。比如主包改了首页布局你的新包就不要跟着改成一样的。这种“趋同演化”是很多马甲包在上架几个月后被追封的主要原因。7. 这5天实操下来我的几个体会第一点是4.3过审这件事不是靠某一个灵丹妙药而是靠“整体差异化”。代码、资源、文案、提交流程每个环节都要做缺一个都可能被机器抓到相似特征。我看过很多团队只做了代码混淆就提交结果被4.3打回然后抱怨苹果审核玄学。其实不是玄学是资源的二进制差异没做到位。机器那边它不只看代码还看资源这是很多人容易忽略的盲区。第二点是时间越紧越不要慌。把前两天的精力集中在代码混淆和资源混淆上这是过审的“硬门槛”。UI界面差异化的投入产出比也很高但前提是你的马甲包在功能上确实有独立定位。如果产品本身没有独立的卖点技术上做到极致也是空中楼阁。反过来说如果产品的定位是独立的技术上再叠加差异化和适度混淆成功率会高很多。第三点是文案差异化的优先级往往被排得太低。我见过很多技术出身的团队花了大量时间在代码混淆上结果提交时直接复制了主包的描述和关键词审核员一对比就判了重复。文案是人工审核员最容易接触到的材料一定要舍得花时间重写。标题、标语、功能描述、隐私政策这些虽然看起来不涉及技术但在过审这件事上的权重非常高。最后再说一个细节提交前一定要自己用两部手机分别装上主包和新包真正用一遍。这不只是为了检查崩溃更是让你自己站在审核员的角度去看这两个东西像不像。如果自己在使用过程中都觉得“这就是同一个东西”那不用怀疑审核员也会这么判断。与其赌概率不如把差异做到位再提交省得来回折腾浪费时间。这5天的流程基本就是这样。代码混淆方案我尽量把核心脚本和思路都列出来了资源处理脚本也贴了照着改的话能让你的包在二进制层面有一个比较大的差异。如果你正在被4.3搞到头大可以按这个思路一步步来至少不会完全没方向。
