App Store审核被拒5次后的经验总结！

算上Beta版的审核,我们的应用已经在App提交了5次了,被拒了五次。这里就来总结下各种被据的原因吧。

 

BUG

 

2.2 – Apps that exhibit bugs will be rejected

 

程序有bug,这个应该属于最浅显易懂的拒绝原因。但是谁又会提交一个有明显bug的版本上去呢?

 

我们有一个“使用微信登陆”的按钮,审核人员告诉我们,“unresponsive when tapped”,原因其实就是没有检查用户是否安装了微信,导致在未安装微信的设备上,这个按钮就没有响应。

 

程序依赖

 

10.6 – Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected

 

这 段话的说法其实很模糊,你的程序太差了所以被拒绝了。不过好在每次审核人员都会解释到底“差”在哪里,并且附上一个“Next Steps”告诉你怎么解决。(不过Beta版的审核人员不会这么做,感觉这是两个不同的部门,审核标准也略有不同,正式上架的审核会严格些,下文会详细 介绍。)

 

Apps should be able to run on launch, without requiring additional applications to be installed.

 

这句话很重要,我们因为这个原因被拒了两次。我们的应用需要登陆,我们开始时我们只提供了一个第三方的微信登陆,第一次提交后,我们“贴心”的增加了判断,当用户未安装微信时点击微信登陆,会收到弹窗提醒告诉你未安装。不允许。

 

后 一次提交的时候,我们增加了QQ作为登陆方式,结果QQ提供的手机SDK也和微信一个尿性,不装应用不能登录,更甚者不装最新版的不能登陆。毫无疑问,我 们又被拒了,这次审核人员很贴心的用了一个“still”:We still find that your app requires the installation of another app before it can be used。于是我们很自作聪明的采用QQweb的登录方式来绕过必须安装手机QQ的问题,花了好大的精力,但实际上意义不大,国内不装手机QQ的用户屈指 可数,而且不用qq的人基本上也不属于我们的应用的潜在用户。

 

这样做总算是通过了Beta版的审核,当我们正式提交的时候,还是被拒了。

 

Apps should be able to run on launch, without requiring additional applications to be installed.

 

这句话很重要,所以要说两遍。没装微信时,我们给了提示,不允许。在审核人员看来,你这种做法属于“required to install WeChat”。

 

更 加方便的做法应该是,“没装QQ就不显示QQ登陆的按钮,没装微信就不显示微信登陆”,如果确实想用第三方登陆,请使用微博,他家SDK很贴心的在未安装 微博时使用网页登陆。最好,你还是提供一个测试账号用于登陆。另外值得注意的是,在ios中,必要的操作都应该在应用内完成,不应该弹出到应用外,我们使 用了qq的一个分享功能,qq的sdk在未安装QQ时会弹出到Safari里让用户登陆,因为这个事情,又被拒了一次。

 

用户系统

 

17.2 – Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected

 

审核人员告诉我们,我们用了QQ、微信、微博的登陆授权,但是呢,“does not include account-based features offered by that site”,没用到他们网站提供的相应功能。

 

解决这个问题要么就增加“account-based features of that social network”,要么就使用自己的账户系统。但是网上的资料告诉我们说,自己的账户系统就一定要有完整的一套功能,密码找回之类的,不然会涉及到收集用户信息。

 

✦游客模式

 

到 底要不要做游客模式,这个问题我们争论了很久,理论上讲,如果你有完整的自己的用户系统,可以注册,那么确实没有必要游客系统。这样的应用有很多,比如微 信QQ,比如Nike Training。但是大部分应用都是有的,这个问题的考量,更多的时从用户体验的角度上来看,用户是否必须要登陆才能使用。

 

✦what if 只有第三方登陆呢?

 

这 个问题就比较棘手了,按照17.2的说法,必须要有““account-based features of that social network”。在这个问题上,我们理解是这样的,如果你的应用是基于个人账户的,所有的功能点都是围绕着用户系统展开的,那么,只提供一个第三方登 陆,应该是远远不够的,你必须要有自己的用户系统;反之,如果你的应用,登陆属于bonus,比如“最美应用”,“ZAKER”(它们刚刚关闭了自有账户 的注册),那么,只使用第三方登陆是可以的。

 

iCloud

 

2.23 – Apps must follow the iOS Data Storage Guidelines or they will be rejected

 

审 核人员说,我们的应用一打开,数据下载完毕后,就产生了3兆多的数据,这些数据我们默认是储存在/Documents里的,这个目录下的数据是默认会被同 步到iCloud上去的。但是,只有用户自己产生的数据,才可以同步过去。简而言之,我们存错地方了,我们保存的其实是cache文件,这些文件是不应该 被同步的,增加”do not back up” attribute就可以了,当然保险起见,cache类的文件不应该储存到/Documents里。

 

<Application_Home>/Documents 里面只能存放用户产生的文件。

 

如果为了满足应用在离线状态下的使用,那么你缓存文件应当 <Application_Home>/Library/Caches这里面。

 

放在<Application_Home>/tmp 里的东西,用完就要去把它删掉。

 

用户自己放到documents里的数据,你也可以将其设为不同步到iCloud上去,以节约用户的iCloud空间。(毕竟是花钱买到)

上面四条就是iOS Data Storage Guidelines中提到的四条规则。

 

另外值得注意的就是iTunes中对于应用数据的暴露,用户通过iTunes是可以直接访问Documents里的数据的,那么如果不希望用户拿到的数据,其实是不应该放在这里面的。