常规被拒
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.0 – Undergo significant concept changes after approval
2.3.1 – Have hidden or undocumented features, including hidden “switches” that redirect to a gambling or lottery website
3.1.1 – Use payment mechanisms other than in-app purchase to unlock features or functionality in the app
3.2.1 – Do not come from the financial institution performing the loan services
4.3.0 – Are a duplicate of another app or are conspicuously similar to another app
5.2.1 – Were not submitted by the legal entity that owns and is responsible for offering any services provided by the app
5.2.3 – Facilitate illegal file sharing or include the ability to save, convert, or download media from third party sources without explicit authorization from those sources
5.3.4 – Do not have the necessary licensing and permissions for all the locations where the app is used
2.1俗称狗年大礼包, 一般会列出N个条款, 告诉你你的APP可能不符合其中的一个或多个,看起来挺吓人, 其实这个是最容易解决的. 一般遇到这个一条条对着回复就行, 本着打死不承认的原则就行了
Business – 3.2.1
The seller name associated with your app does not reflect the financial service provider of the financial products offered in the app, as required by Guideline 3.2.1(viii) of the App Store Review Guidelines.
金融资质问题, 当时我们APP在审核人员复查的过程中, 被发现有理财和贷款, 直接下架了.贴上这条, 是想说, 如APP做了隐藏内容, 一定要把隐藏策略做足, 考虑到复查问题, 以免造成被拒, 我们APP至今未上架成功.下面的段落中有专门讲隐藏相关.
Guideline 5.2.1 – Legal – Intellectual Property
The seller and company names associated with your app do not reflect the name “Government Entity“ in the app or its metadata, as required by Guideline 5.2.1 of the App Store Review Guidelines.
这个条例目前只有A团队遇到过, 从字面意思翻译是说知识产权, 其实跟知识产权毛关系没有.
如果被拒这条, 最好留下电话让审核人员跟你沟通.A团队当时被这条拒了两次, 最后还是电话沟通, 得知: A相关属于政府机构专有,其他非政府机构不能做, 比如A查询
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里面99%都是没有资质, 大家都是通过隐藏内容做上架, 那么隐藏内容的策略就显得尤为重要, 要考虑到方方面面的问题:
审核态切换(审核和非审核之间)
新老用户UI切换(新用户是否展示全部UI, 什么样的老用户在什么情况下展示全部UI?)
时间点控制(能否在指定的时间点控制APP的展示)
IP过滤(国外IP显示审核状态, 主要应对审核人员的审核和复查)
黑白名单机制
审核账号控制
最后着重说一点: 如果你想要隐藏的内容是微信支付和支付宝支付,且你的支付功能是首次提交上去, 可以一试.如果你之前已经被IAP相关原因被拒过, 那么我劝你趁早放弃隐藏这俩支付这个想法, 不要冒险, 老老实实的IAP, 或者参考我下面关于支付绕过IAP的方法.
一般被IAP拒过以后, 审核的时候大概率会扫描你代码里面的Alipay/WxPay关键字, 一旦检测到基本APP就进入黑名单了
支付相关
使用背景
如果APP中提供内容销售，订阅，购买以开启新功能和服务。
You can use in-app purchases to sell a variety of content, including subscriptions, new features, and services. There are four in-app purchase types you can offer.
所以因为IAP被拒的, 大部分因为对这条规则解读不清晰, 一个粗暴的总结:只要不是实物, 都要先考虑IAP, 不然拒你没商量.
一般拒绝邮件理由大部分11.xx,列举几条如下:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
Apps that use IAP to purchase credits or other currencies must consume those credits within the application
如何破
大部分时候不想使用IAP的原因大多在于: 30%的分成
几条绕过IAP的方案,仅供参考:
跳转H5支付, 然后H5再跳转到支付宝/微信支付
跳转小程序,然后微信支付
注意: 如果你想要绕过IAP, 那么审核时商品一定要是免费的
马甲包
拒绝邮件
先上两个个拒绝邮件模板:
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
3 Design: Spam
Guideline 4.3 – Design – Spam
We found that your app provides the same feature set as other apps submitted to the App Store, which is not appropriate to theApp Store
上面俩都是因为马甲包问题导致的拒绝, 但是两者有根本的不同, 前者是机审的结果, 后者是人工审核的结果.
机审发出这样类似的邮件一般时间极短, 在in review状态进入半小时以内基本能出这个结果, 一般几分钟就出来了.人工审核时间更长.
如何破
发布前基于原来的项目check一下几个点
工程名称修改, 注意这里说的是工程名称可不是APP名称, 有一下几个步骤
修改项目名称, 即xx.xcodeproj
修改对应的scheme, product -> scheme -> edit scheme
修改工程内文件名称, 通常多加一些前缀词之类或者直接修改和替代掉原来的前缀
修改实体文件夹名称
删除原有的.entitlements文件, 重新生成新的
资源文件修改, 可以选择修改名称, 也可以替换掉
应用的主界面修改, 暴露次数最多的界面UI调整
使用新的开发者帐号发布应用
修改应用icon, 商店图片, 应用描述, 搜索关键词调整等
修改销售区域(可选)
加入一些垃圾代码(尽量多加, 对于过机审很有用)
加急审核
一般提交加急审核有两种情景:
Critical Bug Fix: 有严重bug需要修复, 比如crash, 影响整体流程等.提交这类加急需要描述详细的bug复现步骤
Time-Sensitive Event: 因时间周期原因需要加急, 在各种节日前用, 屡试不爽
友情提示: 加急审核没有次数限制, 只要理由能被审核人员接受, 可以一直使用
友情提示: 加急审核没有次数限制, 只要理由能被审核人员接受, 可以一直使用
友情提示: 加急审核没有次数限制, 只要理由能被审核人员接受, 可以一直使用
说两点老司机经验:
bug修复加急, 这个一般只要提了, 合情合理, 一般几个小时以就能过审, 所以这个东西可以加以利用:
在重要的页面设计一个可控的crash开关, 比如个人中心的某个页面
最简单不过的方式, 可以跟后端协商做一个可控的crash接口
需要的时候能在指定的情景(账号/设备/页面/时间/区域等)下crash
时间周期这个加急审核, 可以在审核中使用, 即APP已经In Review, 但是持续时间较长, 这时候就可以去官方提一个Time-Sensitive Even加急
审核黑名单
每一次审核被拒都要慎重对待, 因为你随时有可能被拉入黑名单
每一次审核被拒都要慎重对待, 因为你随时有可能被拉入黑名单
每一次审核被拒都要慎重对待, 因为你随时有可能被拉入黑名单
如果APP被拉入黑名单, 单次审核周期会变得谜之巨长, 少则一周, 多则数月, 你没有看错, 是数月.
所以, 每次被拒之后, 要仔细了解被拒条款相关的信息, 如果有不明白的, 可以直接邮件跟审核人员沟通, 或者留下电话要求对方电话联系, 最主要的还是要拿到如何修改相关问题.