1. 机审原理
我们虽然无法得知苹果实际的机审原理，但从程序员的角度还是能分析出一些东西的。

1.1 首先OC和C++代码编译出的二进制文件，有点经验和反编译过的应该都知道：
删注释神马的是没用的，因为注释是不会被编译进包里
改类名是靠谱的，因为反编译出来能看到类名，改掉它显然是会造成包不一样
增改函数也是靠谱的，同样是因为反编译能看到
改文件夹或者文件名应该是不太靠谱的，编译的时候会根据路径来引用查找，编译之后应该是根据在包里的相对内存地址来查找类和函数，跟你编译时的文件名称和路径关系应该不大。不过为了方便和代码的统一，更换时可以顺便换了。
1.2 然后是一些资源文件如图片、音效
路径和文件名相当可能或者*对是有用的，可惜修改代价有点高
文件的md5值以程序员的角度来看才是真正区分文件是否一致的标准，我们有理由相信我们的苹果同行也用了这个来判断是否重复。所以一些修改md5值的操作如添加空行、注释、额外字节，应该也被考虑加上。
1.3 *后是相似的判定，应该是相似率高于某个值才认为你跟其他的重复了，针对像改资源文件名这种代价太高的可能暂不考虑的操作，我们只能添加垃圾文件提高总值来降低重复率了。
2. 混淆方法
2.1 修改类名文件名
先说下手动操作，无非是在xcode上修改文件名类名，然后在可能引用的地方替换类名和文件名（header），要注意的地方是替换的时候要选中匹配大小写；然后是文件夹名称跟文件名一样的时候，可能文件夹名称也要跟着改名，否则替换之后路径引用可能找不到。 招ios app马甲包套壳上架技术（个人、团队）H5接口、*光推送、关键词、介绍图、标题。
如果是要脚本批量操作，那*好先对工程整理下，确保以下几点能让脚本写的更简单更可靠：

要修改的类和文件*好都放到一个文件夹下，万一搞出事不用东找西找，备份和回滚也简单一点
类名和文件名尽量带上前缀，这样修改只替换前缀即可，也不太会跟函数名、变量名什么的重复
*好过一遍把不能修改类名的列出来，比如外面太多地方调用的、第三方的类库。在写脚本的时候把他们排除在外
脚本的话就是遍历文件，判断前缀、是否排除在外，修改文件名类名，在其他文件中查找替换。用python的话应该不是什么大问题。一个小技巧是改完后可以替换一下xxx.xcodeproj/project.pbxproj里的相应字符串，这样xcode打开工程的时候就不用手动再添加进来。

2.2 添加垃圾函数
OC头文件的声明必然是在@interface @end之间，实现是在@implementation @end之间，C++的大部分应该是以}结尾，直接在相应的地方插入垃圾函数，模板可以直接写个HelloWorld输出个随机字符串。在这一步随机名称是个坑，可以去网上找下常见英文单词，格式化后把太短的、太长的、看着不爽的，*重要的是语言的关键字如break,false,if之类的删掉

2.3添加垃圾类
根据我们猜测的路径应该是不影响打包的，所以我们可以简单的把垃圾类文件都放到同一个文件夹下方便管理，写好2.2后这一步应该就是顺手的事情了 。我不太确定的是如果外部不引用这些垃圾类，编译之后它们会不会因为太独立而被检测认为是垃圾代码。所以保险起见，我实现的时候写了一个单独的头文件include了所有这些生成的垃圾类，然后在外部include了这个单独的头文件

2.4修改资源md5值
资源文件有很多类型，通常来说文本文件添加随机数量的空格或空行应该就可以了。图片的话常见的png和jpg都是有固定的结尾字节块的，png是00 00 00 00 49 45 4E 44 AE 42 60 82，jpg是ffd9，用16进制查看工具打开图片应该能注意到这个规律，也可以参考下常见图片文件格式简析。在结尾字节块添加的内容是不会影响图片本身显示的，我们可以利用这个来改变图片的md5值。音效应该也有相应的格式，期待大佬科普下！

2.5创建资源垃圾文件
跟2.3类似，不过这个*好也随机下创建文件夹显得真实点，一些文本文件是什么格式都有各自定义，png和jpg的话就随机写任意长度的任意字符，*好结尾加上相应的结尾字节块，防止2.5后又执行2.4导致出错。

3. 其他事项
上面的基本都能脚本自动化执行，完了后工程名*好也在xcode改下；info.plist会被打包进ipa，*好也多加几个字段上去；target能改也改下方便识别；scheme关联到导出的ipa文件名，不是特别麻烦也顺手改掉；包名、启动页、图标应该都是基本的东西不会被忽略。
———————
一、只改了APP图标和bundleId
Guideline 4.3 – Design
This app duplicates the content and functionality of other apps submitted by you or another developer to the App Store, which is considered a form of spam.

显然已经被标定为重复APP了，机器审核应该就已经发现相似度很高了，然后当晚我打开公司APP监控，在审核这个甲方APP期间，公司的APP被打开了，显然机器审完后，人工还做了一次校验，发现两个APP几乎一样，囧。

二、加入垃圾代码和更改类名
这里我主要做的是，找一些平时练习的工程或者测试工程，把能用的全部拉拉进去，管他是啥，编译不报错就行了。
因为本身学了一些Python的基础，然后我参考网上的一些教程写了一个用Python一键更改类名前缀和后缀的脚本，这样类名也变了，我想应该差差不多了吧。
因为之前4.3了，被警告并延迟审核了，为了快速审核，我移除了那个APPID，重建一个id，这样第二天就得到审核了。然而…

Guideline 4.3 – Design …

what?! 还是一样的结果

三、新建工程，并更改资源文件MD5
这里我想到了，我原来的Project都跟之前的一样，所有配置参数都一样，这样可能比较容易被发现。于是我新建了一个项目，工程名称也用新的，然后调一调工程基础设置，还是用第二点的方式，进行处理。
同时我查到资源文件MD5也可能被苹果的机器审核进行了记录。于是想办法在不改变图片的情况下，更改文件的MD5值，于是了解到文件的二进制原理，于是做了下尝试在图片的流数据末尾混入垃圾数据，结果真的可以在不改变图片展示的情况下，成功修改了图片的MD5，同样在Python一键更改类名前缀和后缀的脚本有脚本代码，可自行更改。该做的都做了，于是又新建了个APPID重新提交。

Guideline 4.3 – Design …

我去?! 怎么还过不了

四、更改首页(假页面)、在其他IP地址下打包上传APP
查了比较多资料，看看我的工程，该做的都做了，机器审核应该发现不了了吧，莫非是我打包APP的ip地址苹果也会记录，既然如此那就，用我的手机给电脑发热点，然后打包吧。
同时，既然过了机器，那怎么过人工呢，人工肯定是肉眼来看的，那就用假页面骗骗他吧。本来我们的APP是开放的进首页点击的时候再登录的，我在后台做了个接口配置，让他在审核的时候必须先登录才能进首页，进入的首页，根据给他的账号，跳转到假页面上…差不多就这样

Guideline 2.1 – Information Needed…
This type of app has been identified as one that may violate one or more of the following App Store Review Guidelines. Specifically, these types of apps often:
1.1.6 – Include false information, features, or misleading metadata.
2.3.1 – Have hidden or undocumented features, including hidden “switches” that redirect to a gambling or lottery website
…

等等！这不是2.1大*包吗？然而身经百战的我根本不慌，我直接回复：“我们确认，我们的APP不存在你说的任何问题”，也可以参考网上的一些2.1大*包的回复格式。

*终，苹果审核人员第二天就妥协了，运气还不错！
仅供参考，毕竟每个APP应用场景不同