苹果开发者审核自救，破4.3魔咒

为什么说4.3是魔咒，因为一旦中了4.3，就意味着你离账号被封还差5步。

因为其他大部分拒审都还属于无害拒审（比如4.2，以后我在再专文提这个），而4.3一旦中招，如果反复提交就容易反复中招，而反复五次中招将面临封号的风险。所以我称其为魔咒。

4.3 Design: Spam

Guideline 4.3 - Design - Spam

Your app duplicates the content and functionality of apps submitted to the App Store, which is considered a form of spam. Apps that simply duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps.

遇到 4.3 无外乎这几种情况：

1. 本来就是马甲包。发了多个app，总算让苹果识别出来了。

2. 不是马甲包，但是上一个包因为总总原因弃用了，选择在新账号或者新建了产品想上架，让苹果识别出来了。

3. 既不是马甲包也不是提交过的包。居然让苹果误打了。

对于第三种情况，很简单，直接申诉就好了，行的正坐的直，心里没鬼就直接刚。但是要注意措辞语气。尽量礼貌，大部分时候应该是能复审通过的。或者复审后产生新的审核问题，只要不是4.3就好。

对于前两种情况，就要掌握方式方法了。

首先，一般根据无数开发者的经验总结，苹果的4.3审核不是人审，而是机审的结果，这意味着4.3是机器审核了你的二进制代码，发现和过去上架或者提交（注意，提交也算）的相似度爆表，所以立刻给你驳回了。所以一般中4.3的审核速度都很快，可能三点审核三点半就给结果了。

这时候一般的策略分三步走：

1. 换一套视觉UI，更换素材。

2. 代码改写方法名，做代码混淆

3. 更换预览图，产品名，关键字

按这三步走，4.3基本可以消灭。

但是这个方法存在的隐患是 — 代码混淆。我相信随着越来越多的开发者选择代码混淆这种轻便的策略，苹果迟早会采取针对性的方案，如果有一天苹果开始识别代码混淆而针对性的审判使用代码混淆的产品和账号，对于珍惜手里账号和产品的开发者，将会是重大灾难。

这里介绍一个适合代码量不大，但是更安全有效的办法。

1. xcode层面，重新建立工程，模版选择空模版。选择不同的工程名。

2. 将原先的代码逐步移植到新工程里，从底层抽象接口开始移植，一边移植一边编译、保证编译成功。

3. 移植到逻辑和视觉层时，选择性的重构文件名（善用xcode的rename功能）。重构工程的目录结构。

4. 移植文件素材时，重置素材的二进制文件。用你能想到的任何办法，只要让二进制文件不一样就可以了。因为4.3是机审，长得差不多不要紧，二进制不一样就好了。

5. 重置预览图。

6. 在itunes connect删除老的app。（注意是完整删除整个而不是下架。

7. 新建app，app名，bundle id，关键字重新改。重新提交。

如果完整按以上方法执行，个人评估破4.3魔咒的概率大概在80%左右。

当然了，这个办法也有弊端，首先你的代码量必须没那么大，不然新建工程带来的移植问题足够你发狂，其次你必须足够珍惜这个产品，不然更改花的精力肯定是舍不得出的，还不如做个别的什么。

汇总一下遭遇4.3后的行动要点：

1. 如果自己的产品是新发布产品，非复制品，那么直接在回复面板回复苹果自己并没有抄袭。必要时可以选择申诉，但是尽量还是先回复为主，沟通无效再考虑申诉。如果自认为自己用了太多网络上的代码模版，那么很可能需要重新规划下引入哪些第三方库的问题。但是注意，沟通期间千万别重新提交产品，也不建议病急乱投医反复乱改乱交，不然你离封号不远了。

2. 如果确实是实出无奈的“复制品”，那么一定要在如何不被机器识别上下功夫。

3. 如果是主观上玩马甲包（虽然我不推荐），那么代码混淆是个好主意，马甲包大部分讲究的是收割一波就走，所以不存在长期维护的问题，那么利用代码混淆工具强行绕过机器审核是好主意。反正上架了，上个一年半载钱赚到手了后面该怎么着怎么着。

4. 如果确实是想把产品做好，决定长期维护，并且代码量不是特别大的，建议老老实实按之前加粗提到的办法。尽量破4.3，一旦过了4.3，后面别的拒绝理由可以针对性应付。