少踩雷,不作死。
前言
最近越来越多的开发者遭遇了苹果审阅万恶的 other 查询。可以看出苹果的查询触发频率是越来越高了。且很难找出规则。有时分是机器审阅出app反常导致的查询,有时分是批量集中时间段的大规模查询。
假如是遭遇了大规模查询,那简直大部分开发者都很难幸免,这不是你的错,是苹果的机制就是如此。可是也存在一些开发者自己操作不妥导致。下边就列举一下简单触发查询的几个开发者行为。
上包次数过于频频
鉴于现如今苹果产品审阅日趋严厉,许多开发者没有意识到一些不妥行为带来的危险,还沿用曩昔所谓的“互联网思路“,想经过短快平的方法不断迭代产品来制胜,这个想法可以说已经掉队了。
现如今假如不是已经成为闻名IP的“可信任产品”,或者有严重bug需求批改,一个产品的更新频率最好维持在一个月一次,或者两个月三次左右的节奏。这样的更新频率可以确保每次更新都能有足够的开发内容迭代,确保产品可以按部就班的进步质量,也不简单呈现审阅危险。
有些开发者一个产品刚上架,假如数据足够好,就想快马加鞭更上一层楼,假如数据不够好,又急着想经过改动来把数据提上去,以至于一经过审阅立刻提交新版本,一个月下来完结了三四次更新。
依照我的经验,更新频率过于频频,在前期审阅可能会非常顺利,可是会在某个时间节点遽然被苹果卡住查询,而从那个时间节点开始,你会发现你后面提交的审阅越来越困难,似乎苹果有意不让你过包相同。
这种情况我和许多朋友交流,是的确存在的,我的理解是频频上包终究触发了苹果对该产品可信任度的“降权”,从“白名单”产品,不幸成了“灰名单”产品。
大改标题
大改标题,指的是开发者在没有足够有说服力的理由的情况下,对产品品牌和名称进行严重变化。
例如你的产品原本姓名叫“咸鱼 – 做一只没有梦想的咸鱼”,下一版遽然改成“懒猫 – 做一只偷懒的小猫”。两个姓名之间简直没有相关性,也简直没有重叠的当地。像这种改名,假如你没有充足的理由阐明,基本上很简单被苹果评定为你是在歹意经过关键字蹭流量,然后招致查询。
咱们知道,一般一个产品立项后的姓名是不会轻易改动的,简单稍作修改的往往是副标题的某些词汇,这才是一般意义上比较正常的标题改动。许多开发者因为上架了一个产品,发现标题所运用的关键词排行起不来,权重过低,就很简单心急直接换名。可是这么做是比较简单触发苹果查询的。
所以说,产品命名是一个重要的工作,最好一开始就定好,定好就不要乱改,否则后期改动很可能本钱越来越高 — 当然了,一般来说也不会有很大危险,只是会给自己制造点麻烦罢了。
添加很多无用代码
假如你开发的一款产品有一些额外的功能还没有完结,可是屏蔽掉不影响上架,于是你想把他暂时屏蔽掉然后改一改预备上架,请不要这么做。
假如项目开发中存在很多事务代码最后却没有被运用,非常简单触发苹果查询。所以,假如开发的整块代码最后决议功能暂时不上,那么最好的办法是先把它从项目中移除,等下次需求上的时分再引用进来。
产品搬运后的首次提交
产品搬运是开发者有时分难以避免的工作,一起,产品搬运带来的危险也很难回避。因为搬运产品总是不可避免的导致账号之间呈现相关,一旦一个账号出问题,另一个账号也很简单被污染。
即使是两个合法账号,搬运了产品后提交更新,也很简单触发一次查询。所以开发者有必要做好预备。
视觉大幅度重构
视觉大幅度重构和 大改标题 的问题是类似的,假如产品的整个面貌和曩昔截然不同,是比较简单触发查询的。
假如是必要的大改版,主张更新列表和审阅阐明的时分写清楚。(不过假如真的是产品需求大改版,也不简单被查询。)
委托过发行商发布产品
这是个要注重的问题,国内有不少发行商会拿开发者供给的代码发布产品,他们可能一起运营着网赚,马甲包等产品,一旦发行商的账号呈现问题被封号,开发者本身也简单受牵连。因为代码是自己供给,那么自己编写的代码结构很可能也被做了特征标记!
更多阅读
苹果开发者防相关开新号自查清单
苹果开发者相关封号扫盲贴
移动开发者联盟入群指引