请不要为同一个 app 创建多个套装 ID。如果您的 app 针对特定位置、运动队、大学等存在不同版本，请考虑提交单个 app，并提供 App 内购买项目以提供不同的功能。同时，请避免继续在已有大量类似 app 的类别下进行开发；App Store 上已经有太多模拟放屁、打嗝声音的 app，以及手电筒和爱经 app。上传大量相似版本 app 的开发者会遭到 Apple Developer Program 的除名。
有过向 App Store 提交 App 被拒经历的人，大概都听说过这个恐怖的 4.3 条款，下面做一个详细的介绍：
【马甲包】指的是内容几乎一样，只是主题色或者是名称等不重要信息略有改动的雷同 App。
【4.3 条款主要针对谁】一方面源于很多大公司希望批量产出类似 App 进行 A/B 测试；另一方面源于很多小产品希望通过对相同的产品用不同的关键词来进行宣传，获取更多的流量（同一个 App，上 10 个马甲包，收入增 10 倍）；这些行为破坏了 App Store 的生态，导致苹果会用非常严格的手段来进行打击。
【4.3 条款麻烦在哪】第一点在于这个条款宁可错杀也不放过，就算你什么错都没犯，也很可能被误伤。 第二点在于，简单的修改是不足以绕过这个条款的，一旦遭遇它，后面无论你怎么修改，再次重新提交也几乎没有通过审核的可能。
【4.3 条款并不是完全搞不定】如今上架马甲包已经变成了很多公司的一个常规性业务，只要手段合适，是可以进行一定的规避的。
【什么情况可能导致遭遇 4.3 条款】提交 App 给人工审核之前，会先经过一次机器审核，基本上就是个反编译的过程。如果项目里面大量复用了其他 App Store 上线项目的代码，会被机器审核回绝；如果产品形态和其他现有 App 几乎一致，会被人工审核拒绝。
判定拒绝来源
首先，搞清楚你是被人工审核拒绝，还是机器审核拒绝的。
你的应用进入审核（In Review）的时候，你会收到一封邮件，之后被拒绝（Rejected）的时候又会收到一封邮件。如果这两封邮件的时间差非常小，比如小于半小时，那么基本上就是被机审拒绝了，否则大概率是人工审核拒绝。另外如果你的项目里面复用了其他项目的代码，你自己心里也应该有数，
如果是被人工审核拒绝了，由于每次审核你的 App 的人可能不一样，可以直接尝试换个 BundleID 再次提交，如果屡次被拒，可能你不得不考虑一下更改一下 App 的 UI，包括但不限于导航方式、主题色、页面结构等等，或者干脆加点功能、砍点功能。
工程混淆
对于机审被拒，首先要做的一步是代码混淆。这个工作不是专门针对 4.3 条款的，项目本身为了防止被别有用心的人反编译，也是常常需要进行加固处理的。
对于纯代码层面的混淆，直接推荐你看这篇博客：https://blog.csdn.net/yiyaaixuexi/article/details/29201699 ，不同的手段所做的工作都差不多，难度也不高，无非就是让反编译出来的函数名、类名、变量名都显示为随机字符串。这篇博客里面的内容我已经实际使用、并提交 App Store 试过，亲测有效。
对于工程层面的混淆，要做以下几个工作：
项目里面的文件目录、子文件夹排列等，尽可能改动要大，完全打乱最好
所有图片、音频资源文件名，建议批量修改，为了便于批量处理，可以加上较长的前缀，比如“CodeExampleTest_123.mp3”
类名、变量名也建议批量重构，Xcode 自带了 Refactor – Rename 的重命名功能，直接加上前缀处理起来很快
BundleID 一定要换，作为一个新 App 重新提交，并且最好和之前的 BundleID 差别较大
App Store Connect 清理工作
内容上
在内容上只上线最最核心的东西，第一次提交，能不要的东西都可以不要，比如设置页什么的。这样万一你后续提交的都被拒，那么这一版可能成为你相当长时间无法更新、甚至永远都无法更新的一个版本，你要保证它起作用。
信息上
一开始的版本，除了要把 ASO 的关键词写好之外，截图、App Store 描述可以都只放最最基本的内容，争取先把第一关过了，后面更新再改这些内容，哪怕代码不动，直接通过发版来更新这些内容也行。
地区上
一开始上线，想碰审核的时候，上线地区可以不要选择所有地区，可以只随便选择一个地区，尽量保证过审。这个地区在你的 App 上架之后是可以随便改的，所以你一开始不妨就让它在一个语言不通的小国家上线，反正也不会有人用。
等通过审核之后，考虑到，你下次提交不一定还能过审，通过审核的应用一定不要“取消发布”，而是要让它在一个小地方先上线。等你确定你之后的更新要失败了，你没办法改代码了，再通过勾选地区的方式，让你的应用在其他地区上线。就算发一版，总比什么都没有要强。
应对苹果审核的非技术因素
机审还是人审
App Store 审核，一般分为机器审核和人工审核两部分，先机审、后人审。
开始审核的时候，你会收到一封邮件；被拒的时候，你又会收到一封邮件。
如果两份邮件间隔时间小于半小时，一般来说，被拒的过程就是机器完成的。
大部分是 2.1 条款和 4.3 条款
回复时机
这个 “回复” 分为两种情况，一种是审核被拒了，在后台的 resolution center 给你发了消息，这种情况下你可以不改 App 包，而是直接在 resolution center 给审核团队进行回复、辩解；另外一种情况是，被卡审核了，拖个十天半个月不给审核、也不给拒绝。
对于前者，你需要回复消息；对于后者，你需要把 App 撤回再提交。而不管是哪种情况，需要做到的一点是：尽量间隔 2-3 天再进行回复。
有这么几个好处：
比如遇到 2.1 条款，等了两三天之后，看起来像是你真的认证检查过自己的问题了，而不是直接回怼
比如遇到卡审，等了两三天之后，看起来像是你把他们没有明确指明的 App 里面的问题解决了
避免遇到同一个审核工作人员
间隔的这两天刚好是周末的话，反正周末他们也不怎么审核，你也没浪费时间
另外还需要注意，如果你准备撤回 App 再提交，要确保：
如果审核明确说明，你再次提交会遭遇 “longer review time”，则要慎重
撤回 App 再提交的话，最好给 App 加上一些明显的功能性改动，不要让对方认为你只是重新打包了一下（对方是有足够的动机来检查你的应用的 MD5 值的）
换账号不解决问题
有时候很多开发者并不是有意要上马甲包，而是比如说，我本来做了一个滤镜的 App，现在想换一套滤镜，再出一个 App，但是 App Store 希望你把功能整合在一起，做成一个 App，给了一个 4.3 条款打回来。于是开发者就准备和审核作斗争。
斗争半天无果，就准备再注册个开发者账号，结果发现还是没有结果。
这里面有很多基础性的因素，来帮助苹果判定你这个新账号还是对应的以前的开发者：
两个账号银行卡信息一样
两次上传 App 包的设备一样（判定是不是同一台 Mac 对他们简直太小儿科了）
两次上传 App 包的 IP 地址一样（MAC 地址、GPS 位置等信息同理）
新旧账号有关联（开发者为了省事，进行账号授权，通过一个账号来管理多个账号下面的 App）
这就是为什么，很多人觉得自己给 App 做了翻天覆地的改变，什么代码混淆、UI 改动全都试过了，还是没有结果。你两次上传 App 用的都是同一个 WiFi，当审核团队都是傻子吗？
看到这可能很多人都绝望了，因为如果网络环境、地址位置、设备、账号全都换一套，成本太高太高了。
所以，如果你真准备从这个角度来骗过审核，就不如直接找个朋友的账号。代码你来搞定，从打包到上架全过程都由对方完成，你在北京，他在深圳，毫无关联。这样虽然也不一定就能帮你过审核，但是至少把非技术性的这块最容易暴露自己的问题解