研发效能是目前互联网企业和传统软件企业都高度关注的领域，一线互联网企业希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发；腰部厂商则希望通过“研发效能”实现弯道超车，充分发挥后来者居上的优势；更多中小企业看到国内一线互联网企业不约而同地在这个领域重点投入，纷纷也是摩拳擦掌准备在效能领域发力。

一夜之间，似乎只有推进了研发效能，才能提升研发团队的效率，才能让自己在和友商的比拼中不至于输在起跑线上。

那么现在企业的研发效能实践到底为企业带来了多大的优势，又帮企业解决了哪些问题呢？那些推行研发效能的企业现在的状态怎么样？研效问题到底解决了吗？

别急，这些问题其实大多都还没有解决，而且有些问题可能还变得更糟糕了。毕竟研发效能的实施没有捷径，需要摸着石头过河，肯定不会能像电影里面演得那样注定会有皆大欢喜的结局。经历了风雨，不一定能看见彩虹，更有可能会得重感冒。所以想要快速解决研发效能的问题，我们首先需要对研发效能有一个全局的认识，需要先从正向的角度来理解研发效能。

到底什么是研发效能

和敏捷的概念类似，到底什么是研发效能很难精确定义。其实很多复杂概念也不是定义出来的，而是逐步演化出来的，是先有现象再找到合适的表述。其实，效率和效能也从来都不是软件工程的专有名词，纵观人类发展史，就是生产力和生产效率不断提升的发展篇章，到了数字化时代，软件研发效能的重要性被凸显了出来。如果要用一句话来总结研发效能的话，我们会用“更高效、更高质量、更可靠、可持续地交付更优的业务价值”来总结。

图1：研发效能的“*性原理”

解释一下其中几个关键概念：

• 更高效：价值的流动过程必须高效顺畅，阻力越小越好。
• 更高质量：如果质量不行，流动越快，死的也会越快。
• 更可靠：安全性和合规性要保障好。
• 可持续：输出不能时断时续，小步快跑才是正道，不要憋大招。
• 更优的业务价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。

在这个概念的引导下，我们引出持续开发，持续集成，持续测试，持续交付和持续运维的理念，它们是研发效能落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。

为什么一线企业都开始搞研发效能

近几年，各大行业龙头企业都纷纷开始在研发效能领域发力，我们认为背后的原因有以下这么三点：

图2：组织层面的“谷仓困局”

01 很多企业存在大量重复造轮子

就像“中台“概念一样，现在很多大企业的产品线非常广，其中存在大量重复的轮子，如果我们关注业务上的重复轮子，那么就是业务中台；如果我们关注数据建设上的重复轮子，那么就是数据中台；如果我们关注研发效能建设上的重复轮子，那就是研效平台，其实研效平台在某种程度上也可以称之为”研发效能中台“，其目标是实现企业级跨产品跨项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0 到 1“，没人有精力去关注更有价值的”1 到 n“。现代化的研效平台会统一来打造组织级别通用研发能力的*佳实践平台。

02 toC 产品已经趋向饱和

从商业视角来看，现在 toC 产品已经趋向饱和，过去大量闲置时间等待被 APP 填满的红利时代已经一去不复返了，以前业务发展*快，那么用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是*佳选择，那个时代关心的是软件产品输出，研发的效率都可以用钱填上。而现在 toC 已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。

03 部分企业存在“谷仓困局”

从组织架构层面看，很多企业都存在“谷仓困局”（图 2），研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。

研发效能真的能够提高吗

既然如此重要，那接下来的问题是研发效能是否真的能提高？

很不幸，我们的观点比较悲观。我们认为研发效能的*对值随着以下因素的增长必然会变得越来越差，就像我（声明一下，这里没有张乐老师）的头发一样，随着时间的推移必然会越来越少一样。

• 软件架构本身的复杂度提升（微服务，服务网格等）
• 软件规模的不断增长（集群规模，数据规模等）
• 研发团队人员规模不断扩大引发沟通协作难度增长

所以，我们能做的不是提升研发效能的*对值，而是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，努力保持现状就是成功。

图3：研发效能的鸿沟

减缓研发效能恶化我们能干啥

看清了本质后，关于如何减缓研发效能的恶化，我们能做点什么呢？

可以说研发效能的涉猎面是很广的，软件研发的每个阶段都有研发效能需要关注的问题，腾讯提出的“研发效能双流模型”可以说很好的诠释了这一概念。双流模型从软件研发的各个阶段提出了研发效能提升的各种工程实践，并且倡导需求价值流和研发工程流的自动联动。

图4 研发效能的双流模型

这里我们列举一些实践给大家抛砖引玉一下，下期的文章我会更系统地来说明其中的*佳实践。

• 可以通过 All-in-one 的开发环境降低每位开发人员开发环境准备的时间成本，同时又能保证开发环境的一致性。更高级的玩法是使用云端集成开发环境 IDE，实现只要有浏览器就能改代码，这一领域国内典型的代表就是腾讯云 CODING 旗下的 Cloud Studio 以及 Github 目前处于 beta 测试阶段的 CodeSpaces。
• 可以借助基于 AI 的代码提示插件，大幅度提升 IDE 中代码的开发效率。输入一段相同的代码，不借助 AI 代码提示插件，需要敲击键盘 200 次，启用插件可能只需要 50 次键盘敲击，这样可以更容易让开发工程师进入“心流“状态，实现”人码合一“。
• 代码的静态检查没有必要等到代码递交后由 CI 中的 Sonar 流程来发起，那个时候发现问题再修复为时已晚，完全可以通过 Sonar Lint 插件结合 IDE 实时发起本地的代码检查，有问题直接在 IDE 中提示，直接修复，这样开发工程师会更愿意修复问题，因为成本更低，也不会引起修复后的再次发版。
• 单元测试比较耗费时间，可以借助 EvoSuite 之类的工具降低单元测试的开发工作量。
• 对于规模较大的项目，每次修改后编译时间比较长。可以采用增量编译，甚至是分布式编译（Distcc 和 CCache）提升效率，对于 Maven 项目还可以通过缓存 pom 依赖树进一步降低编译时间。
• 前端开发可以借助 JRebel 和 Nodemon 之类的工具使前端开发预览的体验更流畅，实现前端代码的“所见即所得”，避免重复的编译、打包、部署和重启步骤，以此提高开发过程的流畅度。
• 选择适合项目的代码分支策略对提升效率也大有帮助。
• 构建高度自动化的 CI 和 CD 流水线将大幅提升价值的流转速率。
• 选择合适的发布策略也会对效能和风险之间的平衡起到积*的作用。比如架构相对简单，但是集群规模庞大，优选金丝雀，如果架构比较复杂，但是集群规模不是太大，可能蓝绿发布更占优势。
• 引入 DevSecOps 与 DevPerfOps 实践，使安全和性能不再局限在测试领域，而是形成体系化的全局工程能力，让安全测试成为安全工程，性能测试成为性能工程。
• …

研发效能的“罗生门”

好了，理解了研发效能的正面观点后，我们再回来看看研发效能在实际落地过程中又是一番什么样的景象。

可以说理想很丰满，但是现实很骨感，下面就我一起看看国内研发效能的各种乱象。

01 迷信单点局部能力，忽略全局优化和拉通的重要性

研发效能的单点能力其实都不缺，各个领域都有很多不错的垂直能力工具，但是把各个单点能力横向集成与拉通，能够从一站式全流程的维度设计和规划的研发效能成熟平台还是凤毛麟角。现在国内很多在研效领域有投入的公司很多其实还在建设，甚至是重复建设单点能力的研效工具，这个思路在初期可行，但是单点改进的效果会随着时间收益递减，企业往往缺少从更高视角对研发效能进行整体规划的能力。很多时候局部优化并不能带来全局优化，有时候还会是全局恶化。

02 具有普适性的通用研发效能工具其实没有专属工具来的好用

既然打造了研发工具，那就需要到业务部门进行推广，让这些研效工具能够被业务部门使用起来。其实，很多比较大的业务团队在 CI/CD、测试与运维领域都有自己的人力投入，也开发和维护了不少能够切实满足当下业务的研发工具体系。此时要把新打造的研效工具来替换业务部门原来的工具，肯定会遇到很强的阻力。除非新的工具能够比老工具好 10 倍，用户才可能有意愿替换，但实际情况是新打造的工具为了考虑普适性很有可能还没有原来的工具好，再加上工具替换的学习成本，所以除非是管理层强压，否则推广成功的概率微乎其微。即使是管理层强压，实际的执行也会大打折扣，接入但不实际使用的情况不在少数。

03 用“伪”工程实践和“面子工程”来滥竽充数

如果你去比较国内外研发效能工程实践的差距，你会发现国内公司和硅谷公司的差距还是相当明显的。但是当你逐项（比如单元测试，静态代码扫描，编译加速等）比较双方开展的具体工程实践时，你会惊讶地发现从实践条目的数量来说，国内公司的一点都不亚于硅谷公司，在某些领域甚至有过之而不及。那为什么这个差距还会如此明显呢？我们认为这其中*关键的点在于，国内的很多工程实践是为了做而做，而不是从本质上认可这一工程实践的实际价值。这里比较典型的例子就是代码评审和单元测试。虽然很多国内一线互联网企业都在推进代码评审和单元测试的落地，但是在实际过程中往往都走偏了。代码评审变成了一个流程，而实际的评审质量和效果无人问津，评审人的评审也不算工作量，也不担任何责任，这样的代码评审能有什么效果，结果可想而知。单元测试也沦为一种口号，都说要贯彻单测，但是在计划排期的时候压根没有给单测留任何的时间和人力资源，可想而知这样的单测是否能成功开展。所以，国内公司缺的不是工程实践的多少，而是工程实践执行的深度。不要用“伪”工程实践和“面子工程”来滥竽充数。

04 忽略研发效能工具体系的长尾效应

再回到研效工具建设的话题上，很多时候管理团队希望能够打造一套一站式普遍适用的研发效能平台，希望公司内大部分业务都能顺利接入，这和想法的确非常好，但是不可否认的，研效平台和工具往往具有非标准的长尾效应，我们很难打造一套统一的研效解决方案来应对所有的业务研发需求，各种业务研发流程的特殊性是不容忽视的。退一万步说，即使我们通过高度可配置化的流程引擎实现了统一研效解决方案，那么这样的系统会因为过于灵活，使用路径过多而易用性变得很差。这两者的矛盾是很难调和的。

05 盲目跟风

再来看看一些中小型研发团队，他们看到国内一线互联网企业在研效领域不约而同的重兵投入，所以也会跟风。他们往往试图通过引进先进企业的工具和人才来作为研效的突破口，但实际的效果可能差强人意。一线互联网企业的研效工具体系固然有其先进性，但是是否能够适配你的研发规模和流程是有待商榷的。很多时候研效工具应该被视为起点，而不是终点，就像你买了一辆跑车，你依旧不能成为赛车手。

06 迷信外部专家

引入一线互联网专家其实也是类似的逻辑，我常常会被问及这样的问题：“你之前主导的研效提升项目都获得了成功，如果请你过来，多久能搞定”？这其实是一个无解的问题。一定程度上，投入大，周期就会短，但是，实施周期不会因为投入无限大而无限变短。我可以帮你避开很多曾经踩过的坑，尽量少走弯路，犯过的错误不再次犯，但是，适合自己的路子还是要靠自己走出来，拔苗助长只会损害长期利益。

07 研效度量的罪与罚

*后再来看看度量。研发效能的度量一直以来都是很敏感的话题。科学管理时代我们奉行“没有度量就没有改进”，但是数字时代这一命题是否依然成立需要我们的反思。现实事物复杂而多面，度量正是为描述和对比这些具象事实而采取的抽象和量化措施，从某种意义上来说，度量的结果一定是片面的，反映部分事实。但没有银弹，也没有完美的效能度量。数据本身不会骗人，但数据的呈现和解读却有很大的空间值得探索。那些不懂数据的人是糟糕的，而**糟糕的人是那些只看数字的人。当把度量变成一个指标游戏的时候，永远不要低估人们在追求指标方面“创造性”，总之我们不应该纯粹面向指标去开展工作，而应该看到指标背后更大的目标，或者是制定这些指标背后的真正动机。

总体来看，对于研发效能，我认为*重要的不是技术升级，而应该是思维升级，我们身处数字化的变革之中，需要转换的是自己的思维方式，我们需要将科学管理时代的思维彻底转为数据经济时代的思维。

研发效能的“冷思考”

*后，回到工程师层面，研发效能的提升对我们而言又意味着什么？

01 工具效率的提升并没有减少我们的工作时长

新工具新平台在帮助我们提升效率的同时，也不断增加着我们学习的成本。用前端开发来举例子，以全家桶为基础的前端工程化大幅度提高了前端开发的效率，但与此同时前端开发工程师的学习成本却在成倍增加，“又更新了，实在学不动了”一定程度反映了前端同开发的悲哀和无奈。

02 技术的升级正在不断模糊工作和生活的边界

早年时候的工作沟通除了面聊以外主要靠邮件，非工作时段老板给你发邮件你有各种正当理由不用及时回复，可是现在及时通讯工具 IM（那个消息已读提示，你懂的）再结合各种 ChatOps 实践，已经让工程师已经无法区分什么是工作什么是生活了，这难道是我们想要的吗？

随着在研发效能领域的不断投入，会有越来越多的研效工具诞生，所有这些工具都使人与工作之间的链接更加紧密，人越来越像工具，而工具越来越像人。我们之所以创造工具是想减轻我们自己的工作，但现实却很可能发展成，我们*终沦为被亲手创造的工具奴役。我们致力于的研发效能，究竟会成就我们，还是毁了我们？值得我们深入思考。

对于研发效能，实施的思路不对，方法不对会搞垮一个团队，我们需要的是体系化的方法论和相应的工程实践。

（2021年9月28日） 　　彭博新闻社记者：贫富差距现在有多大？国家会怎样控制、缩小贫富差距？税务方面的政策会不会起大的作用？ 　　国家发展改革委党组成员、副主任兼国家统计局党组书记、局长宁吉喆：这是个很重要的问题。可以说，我国全面建成小康社会的进程，是贫困现象不断减少的过程，也是人民日益富裕起来的进程。党的十八大以来，我国经济实力持续跃升，人民生活水平全面提高，居民收入分配格局逐步改善。虽然存在贫富差距，但城乡、地区和不同群体居民收入差距总体上趋于缩小。 　　一是城乡之间居民收入差距持续缩小。随着国家脱贫攻坚和农业农村改革发展的深入推进，农村居民收入增速明显快于城镇居民，城乡居民相对收入差距持续缩小。从收入增长上看，2011—2020年，农村居民人均可支配收入年均名义增长10.6%，年均增速快于城镇居民1.8个百分点。从城乡居民收入比看，城乡居民人均可支配收入比逐年下降，从2010年的2.99下降到2020年的2.56，累计下降0.43。2020年，城乡居民人均可支配收入比与2019年相比下降0.08，是党的十八大以来下降*快的一年。 　　二是地区之间居民收入差距逐年下降。在区域协调发展战略和区域重大战略实施作用下，地区收入差距随地区发展差距缩小而缩小。2011—2020年，收入*高省份与*低省份间居民人均可支配收入相对差距逐年下降，收入比由2011年的4.62（上海与西藏居民收入之比）降低到2020年的3.55（上海与甘肃居民收入之比），是进入新世纪以来的*低水平。2020年，东部与西部、中部与西部、东北与西部地区的收入之比分别为1.62、1.07、1.11，分别比2013年下降0.08、0.03和0.18。 　　三是不同群体之间居民收入差距总体缩小。基尼系数是衡量居民收入差距的常用指标。基尼系数通常用居民收入来计算，也用消费支出来计算，世界银行对这两种指标都进行了计算。按居民收入计算，近十几年我国基尼系数总体呈波动下降态势。全国居民人均可支配收入基尼系数在2008年达到*高点0.491后，2009年至今呈现波动下降态势，2020年降至0.468，累计下降0.023。同时居民收入分配调节在加大。“十三五”时期，全国居民人均转移净收入年均增长10.1%，快于居民总体收入的增长。还要看到，在世界银行数据库中，2016年中国消费基尼系数为0.385，比当年收入基尼系数0.465低0.080，而消费的数据更直接地反映了居民实际生活水平。 　　四是基本公共服务均等化加快推进。看居民收入，不仅要看家庭可支配收入，还要看政府为改善民生所提供的公共服务。在全面建设小康社会进程中，各地区各部门积*推进基本公共服务均等化。完善多层次社会保障体系成效明显，目前我国已经建成世界上*大的社会保障网，基本医疗保险覆盖超13.5亿人，基本养老保险覆盖超10亿人。住房保障和供应体系建设稳步推进，全国已累计建设各类保障性住房和棚改安置住房8000多万套，帮助2亿多困难群众改善了住房条件。教育公平和质量不断提升，2020年九年义务教育巩固率为95.2%。基本医疗和公共卫生服务改善，2020年一般公共预算卫生健康支出1.92万亿元。人民群众通过自己劳动得到的收入、经营得到的收入、转移支付得到的收入在增加。同时，有一些收入并没有进入家庭，而是通过公共服务提供给广大群众，这方面在我们这样的中国特色社会主义国家，各部门各地区做的工作尤其多。 　　“十四五”时期，进一步控制和缩小贫富差距，既要做大蛋糕，又要分好蛋糕。要坚持发展是*要务，通过发展经济、辛勤劳动、扩大就业增加居民收入。同时，坚持按劳分配为主体、多种分配方式并存，提高劳动报酬在初次分配中的比重，健全工资合理增长机制，着力提高低收入群体的收入，扩大中等收入群体；完善按要素分配政策制度，增加中低收入群体的要素收入；完善再分配机制，加大税收、社保、转移支付等调节力度和精准性；发挥第三次分配的作用，发展慈善事业；构建初次分配、再分配、三次分配协调配套的基础性制度安排，促进社会公平正义，促进人的全面发展，使全体人民朝着共同富裕目标扎实迈进。 　　你刚才专门提到税收，税收在收入分配中已经发挥重要作用，今后无论是在初次分配，还是在再分配、三次分配当中，都要发挥好税收杠杆的作用。谢谢。 　　CNBC记者：中国的一线城市发展还存在哪些不足之处？比如在养老、社会保障等方面，一线城市未来的发展方向和重点是什么？ 　　宁吉喆：改革开放以来，北京、上海、深圳、广州等一线城市及其他超大特大城市经济大幅增长、人口显著增加、开放不断扩大、社会事业蓬勃发展，已经成为中国经济增长的重要引擎、对外开放的重要枢纽和国家治理的重要支撑，也日益成为人民安居乐业、享受美好生活的重要空间载体。同时，这些城市也存在交通拥堵、房价高企、发展受限等世界各国普遍存在的“城市病”。这些都是发展中的问题、前进中的困难、成长中的烦恼。至于在养老社保方面，一线城市总体水平并不差，几个一线城市人均期望寿命都在80岁以上，名列各类城市前茅。需要改进的是控制成本、改善服务。“十四五”规划纲要对于完善城镇化空间布局，优化提升超大特大城市中心城区功能等进行了规划部署，有以下几点。 　　一是促进超大特大城市高质量、可持续发展。要统筹兼顾经济、生活、生态、安全等多元需要，推动超大特大城市转变开发建设方式，加强城市治理风险防控。坚持人民城市人民建、人民城市为人民，深入把握城市发展规律，统筹发展和安全，切实推动城市发展方式由规模扩张向内涵提升转变，更加注重民生，稳步提高社会保障水平，提升城市治理现代化水平，使城市更健康、更安全、更宜居。同时，进一步强化超大特大城市的中心辐射作用，不断优化经济发展空间格局、实现区域协调发展，更好带动乡村振兴、促进城乡融合发展。 　　二是合理降低超大特大城市开发强度和人口密度。要科学规划城市生产、生活、生态空间，有序疏解中心城区一般性制造业、区域性物流基地、专业市场等功能和设施以及过度集中的公共资源，加强城市治理中的风险防控。比如，北京将立足全国政治中心、文化中心、国际交往中心、科技创新中心功能定位，建设和谐、宜居、美丽的大国首都。同时，以非首都功能疏解为着力点推动京津冀协同发展向更高水平迈进，加强京津冀及周边地区空气质量监测和联防联控，发挥北京科技创新优势带动津冀传统行业改造升级，提升对周边地区的辐射带动作用。 　　三是优化提升超大特大城市核心竞争力。增强全球资源配置、科技创新策源、高端产业引领功能，率先形成以现代服务业为主体、先进制造业为支撑的产业结构，提升综合能级与国际竞争力。比如，上海将提升城市能级和核心竞争力，发挥在长三角地区的龙头带动作用，以强化全球资源配置、科技创新策源、高端产业引领、开放枢纽门户“四大功能”为引领，不断推动国际经济、金融、贸易、航运和科技创新“五个中心”能级跃升，为长三角高质量发展和参与国际竞争提供服务，引领长三角一体化发展。又如，深圳将以建设中国特色社会主义先行示范区为引领，建设综合性国家科学中心，加快推进前海、河套等粤港重大合作平台，在粤港澳大湾区规则衔接、机制对接方面先行先试，充分发挥深圳在大湾区建设中核心引擎作用，辐射带动周边地区加快发展。广州也将发挥在大湾区建设中的重要作用，包括完善广深港、广珠澳科技创新走廊等。谢谢。 　　日本电视网记者：在中国的少子化与老龄化加速增长的背景下，有消息指出，可能对中国今后的经济发展也会产生影响。请问在这种情况下，中国可以继续保持全面小康社会吗？ 　　宁吉喆：进入新世纪以来，中国的人口总量和结构都发生了一些新的变化。2020年开展的第七次全国人口普查全面查清了我国人口的数量、结构、分布等方面情况，这个成果已经公布了。虽然我国人口总量增速有所放缓，总和生育率下降，老龄化程度加深，但总体上看，人口红利依然存在，人才红利优势后发，人口健康水平不断提升。随着人口政策的逐步完善，我国经济发展长期向好，在全面建成小康社会基础上全面建设社会主义现代化国家，仍然具备较好的人力资源保障。 　　一是劳动力资源依然丰富，人口红利继续存在。我国仍然是世界人口*大国，人口总量仍然保持增长，劳动年龄人口总量仍然庞大。我国16-59岁劳动年龄人口达到8.8亿人，还有3亿多育龄妇女，每年能保持1000多万的出生人口规模。2020年，我国农民工总量仍达2.86亿人。人口数量增长产生的红利仍然存在，劳动力资源仍然较为充沛，为经济持续发展提供了人口红利支撑。 　　二是人口素质明显提高，人才红利新的优势逐步显现。过去十年，我国人口受教育程度明显提升。2020年，我国16-59岁劳动年龄人口平均受教育年限达到10.75年，比2010年的9.67年提高了1.08年。教育事业过去十年大发展，其中，大专及以上受教育程度人口2.08亿人，占劳动年龄人口的比重达到23.61%，比2010年大幅提高了11.27个百分点。人才规模比重上升了超过10个百分点，翻了近一倍。这有利于促进我国经济发展方式加快转变、产业结构优化升级、全要素生产率不断提高，为经济高质量发展提供新的人才红利支撑。 　　三是居民健康水平大幅改善，劳动力资源条件优化。健康既是福祉，也是生产力。随着医疗卫生事业改革发展，我国人口身体素质明显提高。2019年，我国人口预期寿命达到77.3岁，比2010年提高2.47岁，这个提高幅度也是很大的。中老年人的身体状况总体改善，现在有许多人虽然已经达到了老年，但是身体素质还是相当好。2020年，我国婴儿死亡率和孕产妇死亡率也分别下降至5.4‰和16.9/10万，两端年龄人口的身体素质都改善了。我国居民的健康水平总体上还优于中高收入国家平均水平，卫生健康事业取得的成绩，也为经济持续发展提供有效的劳动力投入支持。同样是劳动力，身体健康程度改善了，有利于劳动力资源发挥作用。 　　四是少儿人口数量和比重上升，新一代劳动力资源正在成长。“单独二孩”“全面二孩”政策实施以来，我国出生人口数量明显回升。第七次全国人口普查数据显示，0-14岁少儿人口数量比2010年增加了3092万人，比重上升1.35个百分点。“二孩”生育率明显提升，出生人口中“二孩”占比由2013年的30%左右上升到2017年的50%左右。今年国家实施三孩生育政策及配套支持措施，有助于促进出生人口增加，改善人口年龄结构，实现人口长期均衡发展。谢谢。 　　中国日报记者：中国是世界第二大经济体，也是拉动世界经济发展的主要引擎之一，去年中国成为世界上唯一实现经济正增长的主要经济体。当前世界经济复苏的势头不是很稳定，在这样的背景下，中国全面建成小康社会对世界意味着什么？会为世界经济带来哪些新的发展机遇？ 　　宁吉喆：中国全面建成小康社会，意味着全球人口*多的国家和世界上*大的发展中国家经济繁荣、民生改善，这本身就是对世界和平发展的巨大贡献。同时，中国全面建成小康社会也为世界经济复苏提供了动力、创造了机遇，为构建人类命运共同体贡献了中国智慧、中国力量。中国离不开世界，世界也离不开中国。 　　首先，中国全面建成小康社会，为全球减贫事业作出了突出贡献。改革开放以来，中国有7.7亿农村贫困人口摆脱了贫困，占同期全球减贫人口的70%以上，2020年又消除了*对贫困现象，提前10年实现了《联合国2030年可持续发展议程》中的减贫目标，14亿多中国人民踏上全面建设社会主义现代化国家的新征程，这是人类历史上前所未有的大变革、大事件。近年来，在世界贫困人口不减反增、全球减贫事业遭遇瓶颈的背景下，中国减贫取得的成就显著缩小了世界贫困人口的版图，为全球减贫事业注入了信心和力量。 　　第二，中国全面建成小康社会，为世界经济增长和复苏提供了拉动力量。从2006年起，我国已连续15年成为世界经济增长的*大贡献国，连续多年对世界经济增长的平均贡献率超过30%，成为世界经济增长的主要引擎。2020年，我国国内生产总值超过100万亿元，这是克服了新冠肺炎疫情的影响，成为全球唯一实现正增长的主要经济体。今年上半年，中国经济同比增长12.7%，不仅成为拉动全球经济和贸易复苏的重要力量，而且为维护全球供应体系的稳定发挥了积*作用。一年多来，中国已向世界供应口罩数千亿只、疫苗十几亿剂，有力支持了各国抗疫发展。 　　第三，中国全面建成小康社会，为世界经济繁荣发展带来了巨大机遇。目前，中国已经成为全球第二大消费市场、*货物贸易大国，利用外资和对外投资稳居世界前列。随着我们加快构建以国内大循环为主体、国内国际双循环相互促进的新发展格局，中国市场的潜力将日益迸发，中国开放的大门将越开越大，为世界各国提供更广阔的市场、更有力的合作契机和更宽广的发展空间。据测算，今后五年，中国从世界其他国家和地区进口货物将超过10万亿美元，向世界其他国家和地区直接投资将超过5500亿美元，这必将为全球经济稳定复苏和持续发展提供强大动力。 　　*后，中国全面建成小康社会，为发展中国家走向现代化拓展了新的途径。经过新中国70多年特别是改革开放40多年的建设和发展，中国经济面貌从一穷二白到总量全球第二，中国人民生活从温饱不足到全面小康，迎来了从站起来、富起来到强起来的伟大飞跃。在全面建成小康社会进程中，我们创造了经济快速发展和社会长期稳定两大奇迹，这不仅给中国人民带来实实在在的好处，也大大提升了人类社会的发展水平。2019年起，我国人均GDP超过1万美元，这使得世界上人均GDP超过1万美元的经济体人口总量又增加了14亿人，接近30亿人，翻了近一番，这无疑是人类社会发展的巨大福音。中国全面建成小康社会的生动实践，给世界上那些既想加快发展又希望保持自身独立性的国家和民族提供了全新选择。谢谢。

前言

Arm架构以其兼具性能与功耗的特点，在智能终端以及嵌入式领域得到了广泛的使用，不断扩大其影响力。而在PC端以及数据中心，之前往往是x86架构在其中发挥着主要的作用。*近，随着人工智能、云计算等技术的兴起，5G网络的不断成熟，万物互联的时代是的应用的需求越来越多样化，使得对于芯片架构的需求也越来越多样化。

Arm架构在提供可靠性能的基础上，低功耗、低开销的特点使得它被越来越广泛的应用到数据中心和云计算中，成为其中必不可缺少的重要组成部分。亚马逊投入大量精力自研Arm服务器，并应用到AWS服务中，*多实现了成本45%的降低；阿里巴巴也在云服务中大量采用Arm服务器，并积*参与Linaro，Adoptium等组织，不断推动Arm架构的发展。

*近几年，腾讯对于Arm架构的需求也不断增加，各个产品线也不断引入Arm服务器，对于Arm架构软件的需求也在不断增长。KonaJDK团队在腾讯公司内部提供高性能、高稳定性的商用JDK版本，坚定地将Arm架构作为KonaJDK重点支持的架构之一，不断扩展JDK在Arm架构的功能，并不断提高Arm架构中JDK的性能。

随着Arm架构在终端和云计算场景的广泛应用，JDK需要做好对于Arm架构的支持工作，才能更好地得到发展。目前在JDK社区，Arm架构属于*梯队支持架构。而对于Arm架构而言，Java语言“一次编译，到处运行” 的特性适合业务应用无缝推广到Arm平台，而JDK则是Java应用运行的必要条件。JDK对于Arm架构的支持，也是Arm生态推广的有力支撑。在这个过程中，KonaJDK团队希望和Arm紧密合作，共同发展。

腾讯和Arm在JDK方面的合作交流

KonaJDK

目前腾讯和Arm在JDK方面已经有了深入的交流和合作。双方针对JDK在Arm架构常见的性能问题，对于Arm架构新特性的支持情况等方面进行了广泛和深入的讨论，通过性能测试、数据交流、技术研讨等形式不断推动JDK在Arm架构的发展。

KonaJDK团队Arm平台优化技术介绍

KonaJDK

目前在Arm架构，KonaJDK平台已经发布了JDK8和JDK11两个版本，在2021晚些时候还会发布*新的JDK17版本。Kona JDK团队从功能、性能多方面出发，在Arm架构支撑KonaJDK的通用特性，并针对架构特征进行优化，保证Java应用向Arm平台迁移的一致性，为Arm架构推广做好准备。

ZGC：

GC使得程序不再需要手动控制内存的释放，有效的降低了内存管理相关错误产生的可能性。但是，对于GC算法而言，如何准确高效的进行内存清理是一个复杂的过程。随着业务需求的不断发展，GC算法也在不停地迭代，只有针对不同的业务目标，选择*合适的GC算法，才能够更好的帮助业务实现其目标。近几年，随着服务器硬件性能越来越强劲，其软件应用往往也需要更大的堆，从10G到100G，甚至TB级别。在这种环境下，传统的CMS、G1等GC算法，其停顿时间往往随着堆大小的增长而增加，对于超大堆在触发Full GC的时候，甚至可能产生分钟级别的停顿，这样对于延迟敏感的应用来说，GC 停顿已经成为阻碍 其广泛应用的一大顽疾，需要更适合的 GC 算法以满足这些业务的需求。

ZGC 是由JEP333引入JDK，希望彻底解决GC停顿带来的延迟问题，其设计目标为：每次GC停顿时间控制在10ms以下；相对于G1 GC，吞吐率下降不超过15%；支持大堆和特大堆，并且停顿时间不随着堆大小的增长而增长。ZGC从 JDK11 开始推出实验性版本，并随着JDK新版本发布不断补充完善，*终在JDK15中成为正式版本，保证了 Java 停顿时间不会随着堆大小和业务规模的增加而增长。为对GC停顿要求高的业务提供了一种更好的选择。

图 1 ZGC性能（出自The Design of ZGC，Per Lidén）

KonaJDK团队为了满足业务的需求，在Tencent Kona JDK11版本中，完善了ZGC功能的补全，并进行了长期的验证落地，使得对GC停顿敏感的业务也能够在JDK11版本中满足对于低GC延迟的需求。JDK11在2018 年下半年发布，属于Long-Term Support版本，而后续LTS版本为JDK17，预计将于2021年9月发布，中间其他版本属于过渡开发版本，没有持续的更新和修复。因此，KonaJDK团队选择在JDK11完善ZGC的功能，满足业务的需要，即使后续JDK17发布之后，业务版本更新也需要一个过程，在这期间，仍然需要JDK11的支持。

对于Arm架构而言，在JDK11支持ZGC相对于x86架构是一个更大的挑战。x86架构从JDK11开始ZGC就作为Experimental特性开始发布，但是在Arm架构，从JDK13才有对于ZGC的支持。KonaJDK团队进行了大量的工作完成了Arm架构在JDK11中对于ZGC的支持：

• 需要选择JDK在Arm架构中合适的提交移植到JDK11版本
• 从JDK11到JDK13，ZGC代码以及Hotspot代码经过了多次重构，在代码移植过程中需要分析代码重构的功能以及影响，或者移植相关重构代码，或者根据JDK11对相关代码进行适配修改
• 根据Arm架构的特征，适配团队对于ZGC的优化、功能增强以及Bug修复。
• Arm属于RISC架构，而且使用弱有序内存模型，因此在适配相关汇编代码（特别是ZGC使用的barrier）时，需要仔细斟酌指令的选择，在保证正确性的基础上尽可能的降低开销，提高效率
• 在Arm平台进行充分、全面的测试，保证相关代码的健壮性

KonaJDK团队在Arm结构支持ZGC的过程中，遇到的*大困难在于如何正确添加barrier指令保证正确性。由于Arm使用弱有序内存模型，在x86平台能够正确执行的代码在Arm架构下可能由于缺少必要的barrier导致产生随机错误。KonaJDK团队在初步完成ZGC支持代码之后，进行ZGC压力测试过程中，发现存在执行若干次GC之后，存在JDK随机崩溃的现象，发生几率几千分之一。通过对错误现场的分析，大概率怀疑是缺少必要的barrier所致。尝试通过对社区代码以及ZGC逻辑对问题进行分析，在这个过程中，JDK13和JDK11代码结构的不同进一步加大了分析的难度，*终KonaJDK团队完成该问题的修复，ZGC代码在Arm架构连续运行数百万次无问题。

和其他GC算法一样，ZGC也有其适用的业务场景。ZGC算法*大的优势是能够将停顿时间控制在10ms以下，特别适合对于停顿时间敏感的业务。但是为了实现如此短的停顿时间，ZGC的代价是一部分性能损失和内存消耗。ZGC通过将若干任务进行并发化改造，使得若干之前必须在停顿时完成的工作，可以和应用代码并发执行，有效的降低了必须的停顿时间。但是这种并发执行，以及其引入的各类Barrier，也会导致一定程度的应用吞吐率下降。通过整个 OpenJDK 社区的持续投入，当前 ZGC 在性能损失场景中的性能下降已经控制在很小的范围内。对于性能来说，如充足的内存下即大堆场景，ZGC 在各类 Benchmark 中能够超过 G1 大约 5% 到 20%，而在小堆情况下，则要低于 G1 大约 10%。

因此，不同的业务需要根据实际的情况，选择更为合适的GC算法，来保证吞吐率和停顿时间都能够满足业务的需求。目前来看，如果业务应用使用了超大堆（几十G甚至上百G）为了避免传统G1等GC算法Full GC时带来的几十秒甚至分钟级别的停顿，建议使用ZGC。另外如果业务对于停顿时间的有着严格的时限要求，那么也建议使用ZGC。

KonaFiber

应用在需要并发执行多项任务的时候，会创建多个线程，每个线程负责一项任务，从而实现任务的并发执行。但是，随着业务规模的不断增大，如果仍然为每一个任务创建一个线程，由于线程本身内存消耗较大，会导致占用大量的内存。另外，线程切换需要内核完成，大量的线程存在时，其频繁的切换开销也会影响并发执行的效率。协程就是为了解决这种情况而诞生的。协程是一种轻量级的线程，兼顾开发效率和执行效率。协程的切换在用户态完成，比线程切换开销小很多，同时对于内存的需求更低，相对的需要应用代码编写时关注部分协程切换的工作。协程相对于线程，在高并发场景能够取得更好的性能，应用越来越广泛。OpenJDK也启动了Java协程原生支持项目：Project Loom，开发时间超过3.5年，并在不断发展完善，即将成为Experimental特性。

KonaFiber是KonaJDK团队实现的协程方案，它在兼容OpenJDK社区Loom API的同时，提供了更好的切换性能，不过需要部分额外的内存开销。KonaFiber根据业务的需要，目前在JDK8和JDK11实现，和社区兼容的API使它成为可以和社区方案一起长期演进的协程方案。目前KonaFiber已经完成对于Arm架构的支持，能够满足Arm架构应用对于协程的需求。

图 2 KonaJDK和Loom对比

为了满足业务的需求，提供更好的协程切换性能，KonaFiber采用了基于JKU的StackFul有栈方案，为每一个协程创建独立的堆栈。当进行协程切换的时候，JDK在对于协程Pin状态检测以及上下文保存之外，只需要修改Frame Pointer和Stack Pointer的值就可以完成协程的切换工作，逻辑简单且性能开销很小。不过相对于社区的方案，KonaFiber的StackFul方案对于内存的使用要多一些，更适用于对于内存消耗不太敏感，但是对于性能更敏感的业务场景。性能数据如图 2所示，左图表示在不同协程数量情况下，每秒内协程切换次数对比；右图对内存消耗进行了对比。

图 3 KonaFiber性能对比

KonaFiber的实现注重优化以及代码重构，通过多种方式不断进行优化：

• 协程轻量化，不断优化降低协程的资源消耗
• 按需创建，根据业务的需要创建协程，降低内存使用
• GC优化，优化实现，降低协程对GC引入的开销
• 稳定性修复，通过广泛的测试以及业务适配，提高健壮性

相对于OpenJDK社区的协程方案Loom，KonaFiber提供了更高更稳定的调度性能。图 3对比了KonaFiber和Loom在不同协程数量情况下的每秒调度次数。

图 4 调度性能对比

目前KonaFiber在KonaJDK8中已经开源，后续也会在KonaJDK11中开源，KonaJDK也会持续跟进Loom社区并不断完善KonaFiber的实现。

OWST优化

GC运行过程中，存在若干GC线程并行处理各种任务，但是不同任务的处理时间不等，使得各个GC线程之间负载分配并不平衡。JDK中通过如下的方式来平衡各个GC线程之间的负载，降低GC的停顿时间：当一个GC线程执行完成它被分配的任务之后，会查看其它GC线程的任务队列，如果存在这个线程可以执行的任务，那么它会将该任务“偷取”过来并执行。该过程持续循环直到GC结束。该方案实现了负载的自动平衡，但是执行过程中，由于可能多个GC线程同时“偷取”任务，在线程数量较多时，锁的竞争会比较激烈，同时抢锁过程中，各个GC线程的自旋等待也会导致一定的性能开销，使得该算法实际表现差强人意。

为了优化这个过程，Google在ISMM 2016发表了的论文提出了一种新的负载均衡算法：Optimized Work-Stealing Threads（OWST）。该算法的基本思想是：当存在多个GC线程需要“偷取”任务时，*终只有一个线程执行“偷取”操作，其它线程进入等待状态。执行“偷取”操作的线程检查各个GC线程的任务队列，根据任务个数唤醒线程，并执行任务。算法有效的降低了各个GC线程之间对于锁的竞争，提高了整个负载均衡的效率。

OpenJDK社区首先在Shenandoah GC上实现了OWST算法，在JDK12版本中合入主干分支并成为默认的Parallel Terminator。为了更好地支持LTS版本，KonaJDK团队将OWST算法相关代码移植到JDK8和JDK11，并完成相关代码适配和测试工作，经过业务端验证，为JDK8和JDK11添加了商用的OWST算法支持，有效降低了GC并行任务的执行时间，降低了GC的停顿时间。

通过对SPECjbb2015的性能进行测试，使用ParallelGC时OWST在对于max-jOPS基本没有影响的前提下，能够提升大约8%的critical-jOPS评分。另外对于腾讯内部大数据相关的Map/Reduce以及Spark SQL任务进行测试，执行性能也有10+%的提升。

业务应用

KonaJDK

目前在Arm架构，ZGC已经在腾讯的大规模生产中得到了实践应用。

ZGC将停顿时间控制在10ms以下的特性，使得它特别适合停顿时间敏感的业务。腾讯的WAF团队使用Java语言来快速实现产品功能迭代及上线。该团队有一个旁路安全服务，是一个基于Netty框架的Http服务。它对于端到端请求的时延要求特别严格，需要达到99.99% 请求时延小于 80ms 的 SLA 目标。传统的GC算法，难以达到如此高的标准，较长的停顿时间对于该服务有一定的负面影响，需要寻找一种更低停顿时间的GC算法。WAF团队之前采用了G1 GC算法，花费了大量的时间和精力对G1 GC进行选项调优以及代码层面的修改，但由于G1GC本身的不足，仍然存在请求抖动延迟，无法达到既定的 SLA 目标。后续在KonaJDK团队的配合下，通过切换ZGC算法，实现了该业务的P9999 请求延迟稳定小于 80ms，为用户提供了更快速、稳定的服务。

后续计划

KonaJDK

目前KonaJDK团队在Arm架构，主要在JDK8和JDK11版本进行优化和支撑，后续也会支撑JDK17等版本。KonaJDK团队会持续对JDK基础类库、运行时、内存管理、执行引擎等等各个模块进行分析和测试，不断扩展JDK的功能，提升性能。

KonaJDK团队会始终将Arm架构作为重点支撑平台，不断加大投入，推动并完善JDK对于Arm架构的支持，满足对于Arm架构不断增长的需求。

1、应用内包含检查更新功能

iOS 应用的版本更新必须通过 App Store 进行，自身 App 内不能包含提示更新功能。从2015年3月起，所有包含检查更新功能的 App 都会被拒*上架。

2、使用第三方登录时未做安装检测

接入第三方登录要检测是否安装了第三方客户端，未安装时不要显示对应按钮。2015年9月之前，通常可以采用判断未安装则隐藏登录按钮的方式。但目前隐藏按钮的方式也可能被审核拒*，QQ 和微博提供了 web 登录的方式，如果判断未安装，需要允许用户使用 webview 的登录方式。苹果在条款中有声明不允许 iOS 应用的正常使用需要依赖另外一个 App。

3、采集设备IDFA但应用没有广告功能

从2014年2月起，Apple 开始拒*采集 IDFA (identifier for advertising) 却未集成任何广告服务的应用进入 App Store。如果 App 本身没有广告，建议可以在审核的时候显示一个 Banner 广告，并且放在比较明显的位置，审核通过后关掉即可。

4、含UGC却未提供用户协议及举报功能

如果你的 App 内有发帖等UGC（用户产生内容）功能，必须提供用户协议，并留有内容举报功能，否则就会被审核拒*。

5、上传时没有使用真实的应用截图

应用程序的名称、描述、截图或者预览与应用的内容和功能不相关将会被拒*。有 App 因为应用截图使用的是自己设计的插画而被审核拒*。

6、应用必须使用邀请码才能注册使用

苹果要求应用不能限制只有部分用户可以使用。

7、应用内出现第三方移动平台的名字或图标

一直以来，苹果都不允许iOS开发者在进行软件描述时提到 Android 版本，而自从2015年4月起，在 App 内、截图等任何地方提到安卓、Android 的文字、图标、系统界面都会被拒。曾经有电商 App，因为出现了售卖三星安卓手机而被拒。。。

8、应用内涉及*励，未声明与苹果无关

App 里有实物*励的话，不能使用苹果产品（例如 iPhone 、iPad 等）作为*品。另外一定要声明“*励由本公司提供，与苹果官方无关”。

9、没有提供恢复内购的方法

增加一个“恢复购买记录”的按钮即可。

10、未注册时不能使用与账号无关的功能

对于资讯等 App，在没有进行与用户信息相关的操作时，却强行让用户登录，甚至不登录就无法看到任何内容，有可能会被拒*。

11、iPhone 应用在 iPad 上不能正常显示

iPhone程序必须不经修改就能以iPhone分辨率和2倍iPhone 3GS的分辨率在iPad上运行。即使你的App 只为 iPhone 用户提供，在 iPad 上也必须能够正常显示，否则审核会被拒*。

12、侵犯第三方版权

对于视频、音乐、图书类的应用很容易因为这一条而被拒。建议应用内*好不要出现第三方的商标，例如运营商的Logo、影视公司的 Logo 等。

13、应用截图、名称、描述等出现不雅词汇

在应用截图、名称、描述等任何地方出现例如诸如 牛逼、绿茶婊、无节操、逗比 等词汇，都会被苹果审核拒*。

14、应用出现 beta版、测试版字样

不要过度谦虚地在启动画面或者应用名称上加上”beta”字样，苹果不允许测试版产品上架。

15、注册缺少隐私政策

如果应用包含注册功能，注册页面必须提供隐私说明协议按钮或者链接。另外在 iTunes connect 提交新版本的时候，Privacy Policy URL 必须要填写。

16、应用出现崩溃、加载失败等 bug

审核期间出现崩溃会导致审核被拒。建议在审核期间务必保证服务器稳定，避免审核人员审核时出现内容加载失败的情况，导致被拒。

17、应用描述、截图和应用功能不符

如果应用的描述或截图介绍的功能在审核期间没有体现，则会被拒*，如果介绍文案不够详细也会有一定概率被拒。

18、应用包含应用推荐功能

除特殊情况，苹果明令禁止应用内推荐其他APP。

19、应用包含不正确的诊断功能

如果你的应用中，包含不真实的系统检测或优化功能，苹果会认为这项功能有误导用户的嫌疑，审核时会被拒*。

20、应用提交的新版本与上一版差异过大

如果你提交的新版本应用与上一版相比，功能上变化过大，比如将游戏升级为工具类应用，或在新版本中完全改掉前一版产品的功能，则会被苹果拒*。

21、应用违反当地法律法规

应用程序必须遵守上线地区的法律法规，禁止含有赌博、色情、有偿陪伴等违反法律的内容，尤其为用户提供付费社交服务的APP，例如在线直播类APP，必须严格遵守相关规定。

22、应用作者名与金融机构名字不一致

针对理财、P2P等金融相关产品，苹果增加规定 开发者的名字必须与APP内的金融机构名字保持一致，否则会被拒。 且由同一品牌的金融机构提供服务的APP，必须发布在同一个开发者账号跟名称下。

如果你已经代表委托人或者公司发布了这些APP，你的委托人或者公司应该注册iOS开发者账号，并把你添加到他们的开发者账号里，这样你就可以在他> 们账号下面提交并发布APP了。

23、应用提供功能过于简单

应用内的功能不能太过单一，苹果虽然理念中提倡“简单”，但并不代表能接受功能不够完善的应用，他们对应用的核心要求，是希望能够给用户更有价值的体验。当然，如果你的产品太有创意，可能苹果的审核员没能理解它的独到之处，这样的情况下，你可以通过申诉来更详细的描述产品优势，以便通过审核。

24、App 名称 的 副标题 关键词化 被拒*

展示在Appstore中的App名称，包含了不适宜的关键词或描述符。这些词具体如下所示：（一般就是你全部的标题）。下一步，请修改你的App名称，去掉所有不适宜的关键词和描述符。你在Itunes connect关键词字段添加的词，都可以用来搜索你的App。 一般是app名称 过长。。。

App Store审核规则中文版(App审核被拒原因,苹果开发必备)
简介
App Store 的指导原则非常简单 – 我们希望为用户获取 app 时提供更安全可靠的体验，并为所有开发者提供借助 app 获得成功的契机。为此，我们精心打造了 App Store，其中的每个 app 都会经过专家审核，而且还有编辑团队每天帮助广大用户发现新的 app。至于别的一切，可以考虑在开放的互联网上分享。如果 App Store 模式和准则与您的 app 或经营理念不能完美契合，那也没关系，我们的 Safari 浏览器也能提供出色的 Web 体验。

在以下页面中，您会发现我们已把*新的准则清晰地划分为五个部分：安全、性能、业务、设计及法律。App Store 一直在不断变化和改善，紧跟我们客户和产品的需求。您的 app 也需要做出改变与改进，才能留在 App Store 上。

另外，请将以下几点谨记在心：

很多儿童会从我们这里大量下载各种 app。尽管家长控制功能能为儿童提供有效保护，但您也必须做好自己份内的工作。因此，您要知道，我们时刻都在关注这些儿童。
App Store 是向全球数亿人分享 app 的好方法。如果您开发 app 只是为了分发给亲朋好友，那么 App Store 并不是*适合的途径。这时可考虑使用 Xcode 将 app 免费安装到设备上，或者使用面向 Apple Developer Program 会员推出的 Ad Hoc 分发。如果您刚开始开发 app，请进一步了解 Apple Developer Program。
在 App Store 上发布的所有观点，我们都非常支持 — 只要这些 app 尊重用户的不同意见，并能带来良好的 app 体验。如果我们认为 app 的任何内容或行为超出了可接受的范围，我们将拒*该 App。您可能会问，这个可接受的范围是什么？套用*高法院大法官的一句话：“当我看到的时候，我就知道了”。而且，我们相信，当您超出这个范围时，您自己也会意识到。
如果您试图欺骗系统 (例如，试图在审核流程中弄虚作假，窃取用户数据，抄袭其他开发者的作品，操纵评分或 App Store 上的发现方法)，我们会从商店中移除您的 app，并将您从 Developer Program 中除名。
您要确保 app 中所含内容全部符合这些准则的要求，包括广告网络、分析服务和第三方 SDK 等；因此，在审核和选择这些内容时务必要慎重。
某些一般不提供给开发者的功能和技术可能会以授权的形式提供，供开发者在受限情况中使用。例如，我们提供 CarPlay 车载音频、HyperVisor 和特权文件操作的授权。请查看 developer.apple.com 上的文档，进一步了解各种授权。
我们希望这些准则能帮助您顺利通过 App Review 流程，并使批准和拒*标准在整体上更加一致。本文是一个动态文稿；如果新的 app 引发了新的问题，我们可能会随时制定新的规则。也许，您的 app 就将促成新的规则。我们同样热爱 app 开发，并且尊重您所做的一切。我们正竭尽全力为您营造世界上*优秀的平台，既能让您展示才华，还能让您获得回报。

提交之前
为了帮助您尽可能顺利地通过 app 审批，请查看下方列出的常见错误行为，这些行为可能会导致审核流程延误或导致 app 被拒。这些内容不能代替准则或保证 app 获批，但确保核对这个列表中的每一项会是一个良好的开始。如果您的 app 无法再按预期方式工作，或者您不再积*地对其提供支持，那么这个 app 将从 App Store 中被移除。进一步了解 App Store 所做的改善。

请确保：

测试 app 是否会发生崩溃、是否存在错误
确保所有 app 信息及元数据完整且正确
更新您的联系信息，以便 App Review 部门在需要时与您取得联系
提供有效的演示帐户和登录信息，以及审核 app 时所需的任何其他硬件或资源 (例如，登录凭证或示例二维码)
启用后台服务，以使其在审核期间处于活动和可用状态
在 App Review 备注中附上与非明显功能及 App 内购买项目相关的详细说明，包括支持文稿 (如适用)。
检查 app 是否遵循了其他文稿中的相关指南，如：
开发指南

UIKit
AppKit (英文)
WatchKit (英文)
App 扩展编程指南 (英文)
iOS 数据存储指南 (英文)
macOS 文件系统文档 (英文)
Safari 浏览器 App 扩展 (英文)
App Store Connect 帮助
设计指南

Human Interface Guidelines (英文)
品牌和营销指南

营销资源和识别标志指南
Apple Pay 识别标志指南
“添加到 Apple 钱包” 指南 (英文)
Apple 商标及版权使用准则 (英文)
1. 安全
当用户通过 App Store 安装 app 时，他们希望获得安全的体验：app 不含令人不快或具有攻击性的内容，不会损坏他们的设备，不会在使用中造成人身伤害。我们在下方列出了主要的安全隐患。如果您想恐吓、攻击他人，则您的 app 不适合出现在 App Store 中。

1.1 令人反感的内容
App 不应包含具有攻击性、不顾及他人感受、令人不安、惹人厌恶、低俗不堪或只是让人感到毛骨悚然的内容。此类内容的示例有：

1.1.1 诽谤、歧视或恶意的内容，包括有关宗教、种族、性取向、性别、国籍、种族起源或其他目标群体的引用或评论，特别是当 app 很可能对特定的个人或团体进行羞辱、恐吓或造成伤害时。通常情况下，专业政治讽刺和政治幽默作家不受此要求限制。
1.1.2 人类或动物遭到杀害、残害、酷刑、虐待的写实描绘，或者鼓励暴力的内容。在游戏中，“敌人”不能单单针对特定种族、文化、真实存在的政府或企业，或是任何其他真实存在的实体。
1.1.3 鼓励非法使用或不负责任地使用武器和危险物品的描述，或者促进军火或弹药购买的描述。
1.1.4 过于色情的内容 (韦氏词典对“色情”一词的定义是：对性器官或性活动的露骨描述或展示，目的在于刺激性快感，而非带来美学价值或触发情感)。
1.1.5 具有煽动性的宗教评论，或者对宗教文本进行错误或误导性的引用。
1.1.6 虚假信息和功能，其中包括不准确的设备数据或用于恶作剧/开玩笑的功能，如虚假的位置跟踪器。即使指明 app“仅供娱乐”，也不能违背这一准则。支持匿名或恶作剧电话或短信/彩信的 app 会被拒*。
1.2 用户生成的内容
对于包含用户生成内容的 App，有特定的难题需要解决，比如知识产权侵权、匿名欺凌等。为了避免滥用，包含用户生成内容或社交网络服务的 app 必须满足以下条件：

采用相应的方法来过滤令人反感的内容，以免这些内容在 app 中发布
制定一个机制，以举报攻击性内容并在出现问题时及时作出回应
若用户发布攻击性内容，可以取消其使用服务的资格
公布联系信息，以便用户与您联系
如果 app 中所含的用户生成内容或服务*终主要用于色情内容、Chatroulette (随机视频聊天) 式体验、客体化现实生活中的某人 (如“性感与否”投票)、进行人身威胁或欺凌，则这些 app 不适合出现在 App Store 中，它们可能会在未经通知的情况下被移除。如果 app 中所含的用户生成内容来自于基于网页服务，并且该内容是默认隐藏的 (只有当用户通过您的网站将其打开时才会显示)，则可以显示意外产生的“NSFW (公众场所不宜)”内容。

1.3 儿童类别
“儿童类别”可帮助用户轻松找到专为儿童设计的 app。如果您希望参与“儿童类别”，则应该致力于为年纪较小的用户量身打造卓越的使用体验。这些 app 不得提供 app 外链接、购买机会或其他会对儿童造成干扰的内容，除非其保留在受家长监控的指定区域中。请谨记，一旦客户认为您的 app 能够满足“儿童类别”要求，您的 app 就需要一直满足后续更新中的相应准则；即使您决定取消选择此类别，也是如此。进一步了解家长监控。

您必须遵守世界各地与在线收集儿童数据相关的适用隐私法。请务必查阅本指南的“隐私”部分，以了解更多信息。此外，“儿童”类别的 app 不得向第三方发送个人身份识别信息或设备信息。“儿童”类别中的 app 不应包含第三方数据分析或第三方广告。这些做法可为儿童提供更安全的体验。在少数情况下，可能允许包含第三方数据分析，前提是相关服务不会收集或传输 IDFA 或关于儿童的任何身份识别信息 (如姓名、出生日期、电子邮件地址)、儿童所在位置或其设备。这包括任何设备、网络或其他可直接用来或结合其他信息来识别用户及其设备的信息。在少数情况下，也可能允许包含与页面内容相关的第三方广告，前提是该服务拥有适合“儿童”类别 app 的公开备案做法和政策，包括人工审核广告创意以确保适合相应年龄段。

1.4 人身伤害
如果 app 的行为方式可能会造成人身伤害，我们可能会拒*该 app。例如：

1.4.1 如果医疗 app 可能会提供错误的数据或信息，或用于诊断或治疗病患，则这些 app 可能会面临更加严格的审核。
App 必须清楚地披露相关数据和方法，用于佐证声明的健康测量准确度，如果准确度或方法得不到验证，我们会拒*该 app。例如，如果 app 声称仅通过设备上的传感器就能照 X 光、测血压、测体温、测血糖浓度或测血氧含量，则这个 app 会被拒*。
App 应当提醒用户，除了使用该 app，还应咨询医生的意见，然后才能做出医疗决定。
如果您的医疗 app 已经获得监管部门的批准，请随 app 提交相关文稿的链接。
1.4.2 药物剂量计算器必须来自药品生产企业、医院、大学、健康保险公司、药店或经过 FDA 或其相应国际部门的批准的其他实体。由于可能会对病患造成伤害，我们需要确保 app 将在长时间内获得支持，并保持更新。
1.4.3 App Store 中不允许分发任何鼓励消费烟草及电子烟产品、使用违禁药物或摄入过量酒精的 app。鼓励未成年人摄入任何上述物品的 app 都会被拒*。为大麻、烟草或管制物品的销售提供便利 (经授权的药店除外) 同样不被允许。
1.4.4 App 只能显示由相关执法部门公布的酒后驾车检查点，不得鼓励酒后驾车和包括超速在内的其他鲁莽行为。
1.4.5 App 不得促使客户参与赌博或挑战等活动，或以可能对自己或他人造成人身伤害的方式来使用他们的设备。
1.5 开发者信息
用户需要知道如何就疑问和支持问题与您取得联系。确保您的 app 及其支持 URL 中包含能轻松联系到您的联系信息；对于可能会在课堂中使用的 app 而言，这一点尤为重要。如果未能提供准确的*新联系信息，不但会让客户有不好的感受，可能还会违反某些国家/地区的法律。另外，请确保在钱包凭证中包含发卡机构的有效联系方式，以及分配给凭证的品牌或商标所有者的专用证书。

1.6 数据安全
App 应实施适当的安全举措，确保按照“Apple Developer Program 许可协议”和这些准则 (更多信息见“准则 5.1”) 妥善处理收集到的用户信息，防止对这些信息进行未经授权使用、披露或者被第三方访问。

2. 性能
2.1 App 完成度
提交至 App Review 的申请 (包括可供预订的 app) 应为该 app 的*终版本，并应包含所有必要的元数据和有效网址。所有占位符文本、空白网站和其他临时内容应在提交前移除。在提交 app 之前，请务必在设备上对 app 的错误和稳定性进行测试；如果您的 app 需要登录，请提供演示帐户信息 (并打开您的后台服务！)。如果您在 app 中提供了 App 内购买项目，请确保审核人员能够看到这些内容，并确保这些内容处于完整且*新的状态，否则请在审核备注中说明相关原因。请不要将 App Review 视作软件测试服务。我们将拒*不完整的 app 套装以及会出现崩溃或存在明显技术问题的二进制文件。

2.2 Beta 测试
App 的演示版、Beta 版和试用版不适合出现在 App Store 中 – 请使用 TestFlight。所有通过 TestFlight 提交以进行测试发布的 App 都应旨在公开发布，并应遵循“App Review 准则”。请注意，使用 TestFlight 的 app 不得分发给测试者用以换取任何类型的报酬，包括作为众筹资金的*励。对于 beta 版 app 的大幅更新应先提交至 TestFlight App Review 团队，然后再分发给您的测试者。欲了解更多信息，请访问“TestFlight Beta 测试”。

2.3 准确的元数据
客户应该知道他们在下载或购买您的 app 时会得到什么，所以请确保 app 的描述、屏幕快照和预览能够准确反映 app 的核心体验，并记得不断更新，以便保持与新版本相应的*新状态。

2.3.1 请勿在 app 中包含未记录的功能或隐藏功能；不管是对于*终用户还是 App Review 团队，app 功能都应清晰可见。同样，您不应该在 App Store 或离线情况下，营销您的 app 中实际并不提供的内容或服务 (例如基于 iOS 的病毒和恶意软件扫描工具)。如果出现恶劣或屡教不改的行为，则可能会从 Apple Developer Program 中除名。我们正努力将 App Store 打造成值得信赖的生态系统，并希望我们的 App 开发者也能如此；如果您不诚实以待，我们之间就不会有任何业务往来。
2.3.2 如果您的应用包含 App 内购买项目，请确保应用的描述、屏幕快照和预览清楚地指明是否有需要另行购买的精选项目、关卡和订阅等。如果您决定在 App Store 中推广 App 内购买项目，请确保 App 内购买项目的显示名称、屏幕快照和描述适合所有公众，并遵循“推广您的 App 内购买项目”中的准则；此外，您的 app 也应正确使用 SKPaymentTransactionObserver 方法 (英文)，以便客户可以在 app 内无缝完成购买。
2.3.3 屏幕快照应展示 app 的使用情况，而非仅显示标题封面、登录页面或初始屏幕。屏幕快照还可以包括文本及图像说明 (例如：演示输入机制，如触控点或 Apple Pencil 的动画)，并展示设备上的扩展功能，如触控栏。
2.3.4 预览是让客户了解 app 外观和功能的好方法。为了确保客户理解他们将在 app 中获得的体验，预览只可使用从 app 中采集的视频屏幕。Stickers 和 iMessage 信息扩展可以将用户体验展示在“信息”app 中。您也可以添加旁白和视频，或添加文本说明，以帮助说明任何无法仅通过视频进行阐明的内容。
2.3.5 请为 app 选择*适合的类别，并在需要帮助时参考“App Store 类别定义”。如果选择的类别与实际情况相差较远，我们可能会更改 app 的类别。
2.3.6 请在 App Store Connect 中诚实地回答年龄分级问题，以使 app 与家长控制功能的分级保持一致。如果 app 分级有误，客户在获得 app 时可能会感到诧异，或促使政府监管部门展开相应调查。如果 app 所含的媒体内容要求显示内容分级或警告 (如电影、音乐和游戏等)，则需在销售 app 的每个地区内遵循当地要求。
2.3.7 请选择一个独一无二的 app 名称，指定能够准确描述 app 的关键词，不要试图用商标术语、流行 app 的名称或其他不相关的短语来包装任何元数据，以此欺骗系统。App 名称必须限制在 30 个字符以内，且不得包含不属于 app 名称的价格、词语或描述。App 副标题是详细介绍 app 背景信息的*佳之处。副标题必须遵循我们的标准元数据规则，且不得包含不当内容、提及其他 app 或做出无法证实的产品声明。Apple 可以随时修改不合适的关键字或采取其他相应步骤，以防止不当使用。
2.3.8 元数据应适合所有受众，所以请确保您的 app 和 App 内购买项目的相关图标、屏幕快照和预览保持在 4+ 年龄分级；即使您的 app 分级更高，也应如此。例如，如果您的 app 是包含暴力的游戏，请勿选择包含惨烈的死亡或用枪瞄准特定角色的图像。只有“儿童类别”的 app 才能在元数据中使用类似“适合幼儿”和“适合儿童”等词语。请务必确保包括 app 名称和图标 (小图标、大图标、Apple Watch app 和备用图标等) 在内的元数据彼此相似，以免引起困惑。
2.3.9 您应负责确保有权使用 app 图标、屏幕快照和预览中的所有材料，并应显示虚构的帐户信息，而非真实个人的数据。
2.3.10 请确保您的 app 注重 iOS、Mac、Apple TV 或 Apple Watch 体验，并且不在 app 或元数据中包含其他移动平台的名称、图标或图像，除非存在已获批的特定互动功能。确保您的 app 元数据注重 app 本身及其体验。不要包含无关的信息，包括但不限于关于 Apple 或开发流程的信息。
2.3.11 您提交至 App Store 可供预订的 app 必须为完整且可发布的状态。请确保您*终发布的 app 与其在预购状态时所宣传的内容没有实质性差异。 如果您对该 app 进行了重大更改 (例如更改其商业模式)，则应重新开始其预订销售。
2.3.12 App 必须在其“新功能”文本中清楚地描述新功能和产品更改情况。一些简单的错误修复、安全更新和性能改进可以通过一般描述来说明，但较为重大的更改必须列明在备注中。
2.4 硬件兼容性
2.4.1 为了确保用户能够充分利用您的 app，iPhone app 应尽量能在 iPad 上运行。我们鼓励您考虑开发通用 app，这样客户就可以在所有设备上加以使用。进一步了解 通用 app (英文)。
2.4.2 通过设计，让您的 app 节省能耗，且其使用方式不会带来设备损坏的风险。App 不应快速耗尽电池电能、产生过多的热量或对设备资源造成不必要的负担。例如，app 不得鼓励在充电期间将设备置于床垫或枕头下，或对固态硬盘进行过多的写入循环操作。App 及其中显示的任何第三方广告均不可运行无关的后台进程，如加密货币挖矿。
2.4.3 对于 Apple TV app，应确保用户无需使用除 Siri Remote 或第三方游戏控制器之外的硬件输入，但您可以随意提供增强功能供连接其他外围设备时使用。如果需要用户配备游戏控制器，请务必在元数据中清晰说明，以便用户知晓他们需要额外的设备才能玩游戏。
2.4.4 App 不得建议或要求重新启动设备，或者修改与 app 核心功能无关的系统设置。例如，请勿鼓励用户关闭 Wi-Fi 或停用安全功能等。
2.4.5 对于通过 Mac App Store 分发的 app，还有几个额外要求需要您留意：
(i) 这些 app 必须妥当地沙盒化，并遵循“macOS 文件系统文档 (英文)”。另外，这些 app 只应使用相应的 macOS API 来修改其他 app 存储的用户数据 (如书签、“地址簿”或“日历”条目)。
(ii) 这些 app 必须使用 Xcode 中提供的技术来进行打包和提交；不允许使用第三方安装器。另外，这些 app 必须是单个的自包含 app 安装包，不能将代码或资源安装在共享位置。
(iii) 这些 app 不得自动启动或者在启动时包含其他自动运行的代码，不得在未经同意的情况下登录，也不得大量生成在用户退出 app 后仍在未经同意的情况下继续运行的进程。这些 app 不得将图标自动添加到程序坞中，或在用户桌面上留下快捷方式。
(iv) 这些 app 不得下载或安装独立的 app、kext、额外代码或资源，以向我们在审核过程中看到的 app 添加功能，或进行大幅更改。
(v) 这些 app 不得申请升级至 root 特权或使用 setuid 属性。
(vi) 这些 app 不得在启动时显示许可证屏幕、需要使用许可证密匙或实施自己的拷贝保护措施。
(vii) 这些 app 必须使用 Mac App Store 分发更新；不允许使用其他更新机制。
(viii) 这些 app 应在当前发布的 OS 上运行，不得使用已停用或选装的技术 (如 Java、Rosetta)。
(ix) 这些 app 必须在单个 app 套装内包含所有的语言和本地化支持。
2.5 软件要求
2.5.1 App 仅可使用公共 API，并且必须在当前发布的 OS 上运行。进一步了解 公共 APIs (英文)。及时更新您的 app，在未来的操作系统版本中不再支持的任何过时功能、框架或技术皆应被淘汰。App 使用的 API 和框架应该是为了实现预期用途，并在 app 描述中说明集成详情。例如，HomeKit 框架应提供家居自动化服务，HealthKit 则应该用于保持健康和健身目的，并集成在“健康”app 中。
2.5.2 App 应自包含在自己的套装中，不得在指定容器范围外读取或写入数据，也不得下载、安装或执行会引入或更改 app 特性或功能的代码，包括其他 app。仅在特殊情况下，用于教授、开发或允许学生测试可执行代码的教育类 app 可以下载所提供的代码，但这类代码不得用于其他用途。这类 app 必须开放 app 提供的源代码，让客户可以完全查看和编辑这些源代码。
2.5.3 如果 app 传输的病毒、文件、计算机代码或程序会对操作系统和/或硬件功能 (包括推送通知和 Game Center) 的正常运行造成负面影响或导致其中断，则该 app 会被拒*。屡教不改或恶劣的违规行为会导致开发者从 Apple Developer Program 中被除名。
2.5.4 多任务处理 app 只允许在实现预期用途时使用后台服务：VoIP、音频播放、地理位置、任务完成记录和本地通知等。如果应用使用定位后台模式，请提醒用户，这么做会大幅降低电池续航能力。
2.5.5 App 必须能够在仅支持 IPv6 的网络上完全正常地运作。
2.5.6 如果 app 会浏览网页，则必须使用相应的 WebKit 框架和 WebKit Javascript。
2.5.7 基于蜂窝移动网络且超过 10 分钟的视频流内容必须使用 HTTP 实时流化，并包含一个 192 kbps 为底线的 HTTP 实时流化。
2.5.8 如果 app 会创建替代的桌面/主屏幕环境，或者模拟多 app 插件体验，则该 app 会遭到拒*。
2.5.9 如果 app 会改变或停用标准开关 (如调高/调低音量和铃声/静音开关) 的功能，或者改变或停用其他的原生用户界面元素或行为，则该 app 会遭到拒*。例如，app 不应屏蔽转向其他 app 的链接，或用户希望以某种特定方式运行的功能。进一步了解如何正确处理链接。
2.5.10 不得提交包含空白广告横幅或测试广告的 app。
2.5.11 SiriKit 和快捷方式
(i) 集成 SiriKit 和快捷方式的 app 只能登记无需其他 app 支持便可处理的意图，而且这个意图应当与用户对所述功能的预期相符。例如，如果您的 app 属于膳食计划 app，则不应融入开始体能训练的意图，即使这个 app 共享了与健身 app 的集成也不可以。
(ii) 确保 plist 中的词汇和短语与您的 app 及它所登记意图的 Siri 功能相符。别名必须与您的 app 或公司名称直接相关，不得使用通用术语或者包含第三方 app 名称或服务。
(iii) 以*直接的方式解析 Siri 请求或快捷方式，不要在请求与实现之间插入任何广告或其他市场营销信息。只有在完成相关任务需要时 (例如让用户指定特定类型的体能训练时)，才可以要求解疑。
2.5.12 利用 CallKit 或包含 SMS Fraud 扩展的 app 应该只拦截已确认用于发送垃圾信息的电话号码。具有通话、短信或彩信拦截功能或垃圾信息识别功能的 app 必须在营销文本中清楚标识这些功能，并且说明归入拦截列表和垃圾信息列表的标准。通过这些工具获得的数据不得用于与运行或改进您的 app 或扩展没有直接关联的任何其他目的 (例如，不得出于跟踪或创建用户资料等目的来使用、共享或销售这些数据)。。
2.5.13 若有可能，使用人脸识别进行帐户验证的 app 必须使用 LocalAuthentication (英文) (而非 ARKit 或其他人脸识别技术)，且必须对未满 13 岁的用户使用备用身份验证方式。
2.5.14 在录像、记录日志或以其他方式记录用户活动时，app 必须征得用户的明确同意，而且要提供清晰的视觉和/或听觉指示。这亦包括任何对设备摄像头、麦克风、屏幕录像或其他用户输入方式的使用。
2.5.15 能够让用户查看和选择文件的 app 应包含“文件”app 中的项目和用户的 iCloud 文稿。
3. 商务
在 App Store 中，您可以通过多种方式让自己的 App 实现盈利。如果您的业务模式并不显而易见，请务必在其元数据和 App Review 备注中加以说明。如果我们无法理解 app 的工作方式，或者 App 内购买项目不是那么一目了然，则审核会有所延误，并可能会导致 app 被拒*。尽管价格由您决定，但是我们不会分发要价明显过高的 app 和 App 内购买项目。对于试图以不合常理的高昂价格欺骗用户的 app，我们将予以拒*。

如果我们发现您试图操纵评价，通过付费、提供*励、经过筛选或伪造的反馈来提高排名，或者要求第三方服务代您这样做，我们将采取相应措施以保持 App Store 的公正性，其中可能包括将您从 Apple Developer Program 中除名。

3.1 付款
3.1.1 App 内购买项目：
如果您想要在 app 内解锁特性或功能 (解锁方式有：订阅、游戏内货币、游戏关卡、优质内容的访问权限或解锁完整版等)，则必须使用 App 内购买项目。App 不得使用自身机制来解锁内容或功能，如许可证密钥、增强现实标记、二维码等。App 及对应元数据不得包含指引客户使用非 App 内购买项目机制进行购买的按钮、外部链接或其他行动号召用语。
App 可以提供 App 内购买货币，供客户在 app 内“打赏”数字内容提供商。
通过 App 内购买项目购买的所有点数和游戏货币不得过期，并且您应确保为所有可恢复的 App 内购买项目设计一套恢复机制。
请务必指定正确的可购买类型，否则您的 app 将被拒*。
App 可以允许用户将符合 App 内购买项目条件的物品赠予他人。此类*品只能退款给原始购买者，而且不可交货。
通过 Mac App Store 分发的 app 可托管基于非 App Store 机制的插件或扩展。
提供“战利品箱”或其他随机虚拟物品购买机制的 app 必须在客户购买前，向客户披露每种类型物品的获取几率。
非订阅型 app 在提供完整解锁选项前可以提供按时间计算的免费试用期，方法是在“价格等级 0”中设置非消耗型 IAP 项目，并按照命名约定“XX 天试用”来命名。在开始试用之前，app 必须清楚指明试用期时长、试用期结束后不再能访问的内容或服务，以及用户为获得完整功能而需要支付的任何后续费用。进一步了解如何使用收据 (英文) 和设备检查 (英文) 来管理内容访问权限和试用期时长。
3.1.2 订阅：无论属于 App Store 上哪一类别，app 都可以提供自动续订的 App 内购买订阅。在 app 内集成可自动续订的订阅时，请务必遵循下述指导原则。
3.1.2(a) 允许的用途：如果您提供自动续订订阅，则必须为客户提供持续的价值，订阅期必须持续至少七天，并且能够在用户的所有设备上访问。适当的订阅示例包括但不限于：新游戏关卡；连载内容；多玩家支持；持续提供实质性更新的 app；对媒体内容的大型合集或持续更新的访问权限；软件即服务 (SAAS)；以及云服务支持。此外：
订阅可与单点式服务一起提供。例如，您可以提供整个影片库的订阅，以及单部影片购买或租赁。
您可以在您的多个 app 和服务中提供跨 app 的订阅项目，但这些订阅不可扩展到第三方的 app 或服务。游戏订阅中提供的游戏必须由该开发者拥有或已受*许可 (例如：非属于游戏发布平台的一部分)。所有游戏都必须直接从 App Store 下载。游戏须避免订阅用户的重复支付，且不应损害非订阅用户的利益。
订阅必须适用于可使用该 app 的所有用户设备。进一步了解在您的多个 app 之间共享订阅项目 (英文)。
App 不得强制要求用户为 app 评级或点评、下载其他 app，或执行其他类似操作，然后才能访问该 app 的功能、内容或者使用该 app。
与所有 app 一样，此类服务订阅应当允许用户直接获得付费购买的项目而无需执行额外任务，如在社交媒体上发帖、上传通讯录，以及在 app 内签到特定次数等。
订阅可以包含消耗性的积分、宝石或游戏内货币等。您也可以提供包含消耗性商品打折权益的订阅 (例如能以优惠价购买宝石包的高级会员资格)。
如果要将现有 app 更改为基于订阅的业务模式，您不得减掉现有用户已付费购买的主要功能。例如，针对新客户引入订阅模式后，已购买“完整游戏解锁”的客户应能够继续访问完整版游戏。
支持自动续期订阅的 app 可以通过提供 App Store Connect 中规定的相关信息，来为客户提供免费试用期。
试图诓骗用户的 app 会从 App Store 中被移除。这包括试图通过虚假信息诱骗用户购买订阅或涉及“诱购”和欺诈行为的 app，这些 app 会被从 App Store 中移除，您也可能会从 Apple Developer Program 中除名。进一步了解订阅免费试用期。
3.1.2(b) 升级和降级：用户应能获得无缝的升级/降级体验，并且不会出现无意间订阅同一内容的多个不同版本。请查阅关于管理订阅升级和降级选项的*佳做法。
3.1.2(c) 订阅信息：在让客户订阅之前，您应当清晰描述付费后的具体权益。每月有几期？云存储容量有多大？具体能访问您的哪些服务？务必清晰地传达“协议、税务和银行业务”下“Apple Developer Program 许可协议”的“附件 2”中所述的要求。
3.1.3(a)“阅读器”App：App 可以允许用户访问先前购买的内容或内容订阅 (具体包括：杂志、报纸、图书、音频、音乐、视频、专业数据库访问权限、VoIP、云存储以及经批准的服务，如课堂管理 app)，前提是您同意不会直接或间接引导 iOS 用户使用非 App 内购买项目机制进行购买，并且在您介绍其他购买方式的普通沟通中没有刻意阻止用户使用 App 内购买项目。
3.1.3(b) 多平台服务：跨平台运行的 app 可以允许用户访问他们在其他平台上的相应 app 中或您的网站上获取的内容、订阅或功能，包括多平台游戏中的消耗品，前提是这些项目也在 app 中以 App 内购买项目的形式提供。您不得直接或间接引导 iOS 用户使用非 App 内购买机制进行购买，在您关于其他购买方式的一般说明中亦不可刻意阻止用户使用 App 内购买项目。
3.1.4 硬件相关内容：在为数不多的情形中，例如当功能依赖于特定的硬件功能时，app 可在不使用 App 内购买项目的情况下解锁相应功能 (例如，天文 app 会在与望远镜同步后增加功能)。与经过批准的实际产品 (如玩具) 配合使用的可选 app 功能可在不使用 App 内购买项目的情况下解锁特定功能，前提是它同时也提供 App 内购买项目选项。您不得要求用户通过购买无关产品或参与广告或市场活动来解锁 app 功能。
3.1.5 (a) App 之外的商品和服务：如果 app 允许用户购买将在 app 之外使用的商品或服务，则必须使用 App 内购买项目以外的购买方式来收取相应款项，如 Apple Pay 或传统的信用卡入口。
3.1.5 (b) 加密货币：
(i) 钱包：App 可以协助虚拟货币储值，前提是它们由组织类别帐户的开发者提供。
(ii) 挖矿：App 不可参与虚拟货币挖矿，除非处理过程是在设备外进行的 (例如，云端挖矿)。
(iii) 兑换：App 可以通过经批准的交易所协助加密货币交易或传输，前提是它们是由交易所本身提供的。
(iv) 首次代币发行：App 如支持首次代币发行 (“ICO”)、数字加密货币期货交易以及其他数字加密证券或准证券交易，发布方须为已创立的银行、证券公司、期货经纪商 (“FCM”) 或其他经批准的金融机构，并遵守所有相关法律。
(v) 加密货币 app 不可通过完成任务来提供货币，如下载其他 app、鼓励其他用户下载，以及在社交网络发帖等。
3.1.6 Apple Pay：如果 app 使用 Apple Pay，则在销售任何商品或服务之前，必须先向用户提供所有的基本购买信息，并且必须正确使用 Apple Pay 品牌和用户界面元素，具体要求可参考“Apple Pay 识别标志指南”和“Human Interface Guidelines (英文)”。使用 Apple Pay 提供重复付款服务的 app 至少需要披露以下信息：
续订周期的时长；除非被取消，否则续订将会继续
每个周期中会提供哪些服务
将向客户收取的实际费用
如何取消
3.1.7 广告：App 内显示的广告必须与 app 的年龄分级相符。应允许用户查看用于引导至这个广告的所有信息 (不要求用户离开 app)，并且不可涉及基于敏感用户数据的定向或行为定向广告。敏感的用户数据包括健康/医疗数据 (如来自 HealthKit API 的数据)、学校和课堂数据 (如来自 ClassKit 的数据)，或儿童的数据 (如来自儿童类别的 app 的数据)，等等。插播广告、会中断或阻止用户体验的广告必须清楚地表明它们属于广告，不得操纵或欺骗用户轻点它们，并且必须提供可以轻松访问和清晰可见的关闭/跳过按钮，按钮大小要足以让用户轻松解除广告。
3.2 其他业务模式问题
下方列表并非详尽清单，且我们的政策可能因您提交的 app 有所变更或更新，但这里有一些额外的应做及勿做事宜需要您的注意：

3.2.1 可以接受
(i) 在您的 app 中，出于购买或促销目的而展示您的其他 app，只要您的 app 不只是简单地罗列其他 app。
(ii) 显示或推荐专为经批准的特定需求而设计的第三方 app (如健康管理、航空以及辅助功能等)。您的 app 应能提供持续不断的编辑内容，这样 app 才不会看起来像是个摆设。
(iii) 在租借期限结束后，禁止访问经批准的特定租借内容 (例如电影、电视节目、音乐、图书)；所有其他项目服务不得存在过期时间。
(iv) 钱包凭证可用于付款或接收付款、传输交易或是提供身份验证 (例如电影票、优惠券和 VIP 凭据)。如将钱包凭证用作其他用途，则可能会导致 app 被拒，钱包凭据也有可能被撤销。
(v) 保险类 app 必须免费提供，并且必须遵守 app 发布地区的相关法律，且不得使用 App 内购买项目。
(vi) 经批准的非营利组织可以在他们持有的 App 或第三方 app 内进行筹款活动，前提是这些筹款活动必须遵守所有的 App Review 准则并提供 Apple Pay 支持。这类 app 必须披露资金的计划用途，遵守所有必要的当地和联邦政府法律，并且确保向捐款人提供相应的报税收据。在被要求时，还应向 App Review 团队提供其他信息。向捐款人介绍其他非营利组织的非营利组织平台必须确保 app 中列出的每一家非营利组织都已通过非营利组织批准流程。进一步了解如何成为受批准的非营利组织 (英文)。
(vii) App 可允许个人用户使用非 App 内购买项目机制向另一位个人送赠货币式*物，前提为：a) 送赠方拥有决定是否进行送赠的完全自主权，b) 获赠方收取 100% 的*物金额。然而，*物若在任何时间点对应或包含接收任何数字内容或服务，则必须使用 App 内购买项目。
(viii) App 如用于金融交易，投资或资金管理，发布方应为执行此类服务的金融机构，或必须使用由相应机构根据自身条款与条件提供的公共 API。
3.2.2 不可接受
(i) 创建与 App Store 类似且用于显示第三方 app、扩展功能或插件的界面，或将其作为热门 app 的合集。
(ii) 通过由硬件或操作系统提供的内置功能 (诸如推送通知、照相机或陀螺仪) 或 Apple 服务 (如 Apple Music 访问或 iCloud 存储) 获利。
(iii) 人为地刷广告展示次数或者广告点进次数的 app，以及主要设计目的在于显示广告的 app。
(iv) 在 app 内为慈善机构和募款方筹集资金，除非您是经批准的非营利组织或依上文 3.2.1 (vi) 规定获得了许可。出于以上目的筹集资金的 App 必须在 App Store 上免费，并只能在 App 之外筹集，例如通过 Safari 浏览器或短信。
(v) 强行限制 App 的用户群，例如限制特定地区或运营商。
(vi) App 应当允许用户直接获得付费购买的项目而无需执行额外的任务，如在社交媒体上发帖、上传通讯录，以及在 app 内签到特定次数等。App 不得要求用户必须先为 app 评分或点评、观看视频、下载其他 app、点击广告或进行其他类似操作，然后才能访问 app 的功能、内容或使用 app，或者收到现金或其他补偿，包括但不限于*品卡和代码。
(vii) 人为操纵用户在其他服务中的可见性、状态或排名，除非相关服务的条款和条件允许这样做。
(viii) App Store 中不允许分发协助进行二元期权交易的 app。请考虑使用网页版 app。App 如支持差价合约或其他金融衍生工具 (如外汇) 交易，则必须在提供服务的所有司法管辖区获得相应的许可。
(ix) App 不得强制要求用户为 app 评级或点评、下载其他 app，或执行其他类似操作，然后才能访问 app 的功能、内容或者使用 app。
4. 设计
Apple 客户非常注重简洁、雅致、创新且易于使用的产品，这也正是我们希望在 App Store 上看到的。您可尽情提供各种优秀设计，但要想获准在 App Store 上发布 app，至少需要满足以下标准。另请记住，即使在 app 获得批准之后，您也应当对其进行更新，确保 app 功能正常并持续吸引新客户和现有客户。停止服务或体验下降的 app 随时可能会从 App Store 中被移除。

4.1 抄袭者
请拿出您自己的想法。我们知道您有自己的奇思妙想，那么请将它们付诸实际。请不要简单照搬 App Store 上的热门 app，或只是细微修改其他 app 的名称或 UI，就将其挪为己用。这么做不但有引发知识产权侵权索赔的风险，更会加剧在 App Store 中浏览的难度，并对您的开发者同仁来说也很不公平。

4.2 *低功能要求
App 应包含功能、内容和 UI，而不仅仅是一个经过重新包装的网站。如果 App 没有什么实用价值、毫无新意或者不太像是一个 App，那它就不适合出现在 App Store 中。如果 App 不能带来持久的娱乐价值，则可能无法获得批准。如果 app 只是一首歌曲或一部影片，则应提交到 iTunes Store。如果 App 只是一本图书或游戏指南，则应提交到 Apple Books Store。

4.2.1 使用 ARKit 的 app 应提供丰富而完整的增强现实体验，仅将模型放入增强现实视图或重播动画并不足够。
4.2.2 除了目录类 app 之外，app 不应只包含市场营销材料、广告、网络剪报、内容聚合或链接集合。
4.2.3
(i) App 应能独立工作，无需安装其他 app。
(ii) 确保 app 发布时在其二进制文件中包含有正常运行所需的充足内容。
(iii) 如果 app 需要下载其他资源，请披露下载大小并在下载之前提醒用户。
4.2.4 与表盘类似的 Apple Watch app 可能会令人感到困惑，因为用户会认为这些 app 能与各种设备功能 (如轻扫、通知和第三方复杂功能) 配合使用。将创意性的时间表现方式用作 app 界面是个好点子 (例如，供冲浪者使用的潮汐时钟)，但是如果您的 app 与表盘过于相像，则可能会被我们拒*。
4.2.5 主要用作 iCloud 和 iCloud 云盘文件管理器的 app 需要包含更多的 app 功能，才能获得批准。
4.2.6 利用商业化模板或 app 生成服务创建的 app 将被拒*，除非这个 app 由相应内容的提供商直接提交。这些模板服务若要为不同的客户提供差异化的用户体验，可提供工具来帮助客户自行创建创新的 app，但不应代表客户提交 app。模板提供商也可以考虑创建单一的二进制文件，以汇总或“选取”的模型托管所有客户端内容 (例如：在搜索餐厅的 app 里为每个客户餐厅定制独立的条目或页面，或在聚会活动 app 里为每个客户的活动创建单独的条目)。
4.2.7 远程桌面客户端：如果您的远程桌面 app 用作特定软件或服务的镜像，而不是主机设备的普通镜像，则必须符合以下规定：
(a) App 必须仅连接到归用户所有的主机设备 (即归用户所有的个人电脑或专用游戏控制台)；主机设备和客户端皆须通过本地局域网连接。
(b) 客户端中显示的任何软件或服务应完全在主机设备上执行，在主机设备屏幕上完整呈现，并且不可使用超出远程桌面传输所需的 API 或平台功能。
(c) 所有帐户的创建和管理均必须从主机设备发起。
(d) 客户端上显示的 UI 不与 iOS 或 App Store 视图相似，不提供商店类界面，也不能供用户浏览、选择或购买用户尚未拥有或授权的软件。为明确起见，在镜像的软件中发生的交易不需要使用 App 内购买，前提是这些交易是在主机设备上处理的。
(e) 云端 app 的瘦客户端不适合在 App Store 上发布。
4.3 重复 App
请不要为同一个 app 创建多个套装 ID。如果您的 app 针对特定位置、运动队、大学等存在不同版本，请考虑提交单个 app，并提供 App 内购买项目以提供不同的功能。同时，请避免继续在已有大量类似 app 的类别下进行开发；App Store 上已经有太多模拟放屁、打嗝声音的 app，以及手电筒、算命、约会和爱经等 app。除非这类 app 会提供独特、高质量的体验，否则我们将会予以拒*。上传大量相似版本 app 的开发者会遭到 Apple Developer Program 的除名。

4.4 扩展
托管或包含扩展的 app 必须遵循“App 扩展编程指南 (英文)”或“Safari 浏览器 App 扩展指南 (英文)”；如果可行，还应包含诸如帮助屏幕和设置界面在内的一系列功能。您应当在 app 的市场营销文本中清晰且准确地披露提供了哪些扩展，扩展中不可包含营销、广告或 App 内购买项目。

4.4.1 Keyboard 扩展还需要遵循一些额外的规则。
它们必须：

提供键盘输入功能 (如可输入字符)；
如果键盘中含有图像或表情符号，请遵循贴纸准则；
提供切换到下一个键盘的方法；
在没有网络连接和不要求完全访问权限的情况下仍能使用；
收集用户活动数据只是为了改进其 Keyboard 扩展在 iOS 设备上的性能。
它们不得：

启动“设置”之外的其他 app；或者
将键盘按键用于其他行为，例如按住 return 键来启动相机等。
4.4.2 Safari 浏览器扩展必须在 macOS 上的*新版 Safari 浏览器上运行。它们不得干扰系统和 Safari 浏览器 UI 元素，并*不能包含恶意或误导性的内容或代码。违背此规则会遭到 Apple Developer Program 除名。除了正常工作所必需的网站，Safari 浏览器扩展不得要求访问更多网站。
4.4.3 表情贴纸
表情贴纸是让“信息”变得更动态、更有趣的*佳方式，让人们能够以更巧妙、有趣、有意义的方式表达自我。无论您的 app 是含有 Sticker 扩展，还是您要创建单独的表情贴纸包，其内容均不得冒犯用户、造成负面体验或违反相关法律。

(i) 通常，不适合在 App Store 上发布的内容也不适合放入表情贴纸内。
(ii) 考虑地区敏感性，不要在难以接受或者会违反当地法律的国家/地区提供您的表情贴纸包。
(iii) 如果您的表情贴纸含义不易理解，请在审核备注中附上清晰的说明，从而避免导致审核流程的延误。
(iv) 确保您的表情贴纸在您的朋友与家人之外具有相关性；它们不应特定于个人活动、群体或关系。
(v) 您必须对表情贴纸中的内容，持有所有必要的著作权、商标权和形象权及授权许可，不得提交任何未经授权的内容。请记住，您必须能够在要求时提供可核实的文件。若 app 内含有您无权使用的表情贴纸内容，这个 app 会被从 App Store 中移除，屡次侵权者会被从 Developer Program 中除名。如果您认为自己的内容遭到其他提供商侵权，请点击此处提交申诉。
4.5 Apple 站点和服务
4.5.1 App 可以使用获批的 Apple RSS Feed (如 iTunes Store RSS Feed)，但不能抹除 Apple 站点 (如 apple.com、iTunes Store、App Store、App Store Connect 和开发者门户等) 的任何信息，也不能使用这类信息进行排名。
4.5.2 Apple Music
(i) MusicKit API 可以让客户在使用您的 app 时访问自己的订阅。它们旨在为 Apple Music 订阅用户提供轻松简便的音乐播放体验。用户必须能够发起 Apple Music 流媒体播放，并且能够使用“播放”、“暂停”和“跳过”等标准媒体控件来浏览音乐内容。此外，您的 app 不得要求用户通过付款或间接的货币化方式来获取 Apple Music 服务的访问权限 (如 App 内购买项目、广告、要求使用用户信息等)。请勿下载、上传或分享源自 MusicKit API 的音乐文件，除非 MusicKit (英文) 文稿中已明确允许。
(ii) 使用 MusicKit API 并不能取代为获得更深入或更复杂的音乐集成而可能需要的授权许可。例如，如果您希望您的 app 在特定时刻播放特定的歌曲，或者创建可以在社交媒体上分享的音频或视频文件，您需要直接联系版权持有人来获得许可 (如同步或改编权利) 和资源。封面插图和其他元数据仅可用于与音乐播放或播放列表相关的用途 (包括展示 app 功能的 App Store 屏幕快照)，未经版权持有人明确授权，不得用于任何市场营销或广告目的。在 app 中集成 Apple Music 服务时，请务必遵循“Apple Music 识别标志指南 (英文)”。
(iii) 访问 Apple Music 用户数据 (如播放列表和个人收藏) 的 app 必须在用途字符串中清楚披露这类访问行为。收集的任何数据均不得与第三方分享，也不得用于除支持或改进 app 体验之外的任何其他用途。这类数据不得用于识别用户身份或设备，也不得用于广告定向宣传目的。
4.5.3 不得使用 Apple 服务 (包括 Game Center 或推送通知等) 发送垃圾邮件、进行网络钓鱼，或者向客户发送未经请求的信息。不得尝试进行查找、跟踪、关联、挖掘、获得或利用玩家 ID、别名以及通过 Game Center 获得的其他信息。否则将会遭到 Apple Developer Program 的除名。
4.5.4 App 不得将推送通知列为必需条件，并且不应将这项功能用来发送敏感的个人或机密信息。推送通知不得用于促销或直接营销目的，除非客户已通过 app UI 中显示的同意语句明确选择接收此类信息，并且您在 app 中提供了让用户可以选择不接收此类信息的方法。不当使用这些服务可能会导致撤销您的权限。
4.5.5 仅以 Game Center 团队批准的方式使用 Game Center 玩家 ID，并不得在 app 中显示或向任何第三方显示。
4.5.6 App 可以在自身和 app 元数据中使用会呈现为 Apple 表情符号的 Unicode 字符。Apple 表情符号不可在其他平台中使用，也不可直接嵌入到您的 app 二进制文件中。
4.6 备选 App 图标
App 可以使用自定图标以传达特定信息 (例如表达对某个运动团队的喜爱)，前提是每次更改都由用户发起，并且 app 中应包含恢复至原始图标的设置。所有图标变体必须与 app 的内容相关，并且更改内容在所有系统资源之间应保持一致，以便“设置”和“通知”等位置中显示的图标与新的 Springboard 图标相吻合。这项功能不可用于动态、自动或连续性更改，例如用于反映*新天气信息和日历通知等。

4.7 HTML5 游戏与聊天机器人 (Bot) 等
App 可包含或运行未嵌入二进制文件的代码 (如基于 HTML5 的游戏和聊天机器人等)，前提是 app 的主要目的并非代码分发，代码亦没有在商店界面或类似商店的界面中提供，而且相关软件 (1) 为免费软件或需通过 App 内购买项目进行购买；(2) 仅使用标准 WebKit 视图中提供的功能 (例如，它必须在 Safari 浏览器中原生打开和运行，且无需修改也无需其他软件)；您的 app 必须使用 WebKit 和 JavaScript Core 来运行第三方软件，且不得试图扩展或披露原生平台 API 给第三方软件；(3) 由已加入 Apple Developer Program 且签署“Apple Developer Program 许可协议”的开发者提供；(4) 不提供对真实货币游戏、彩票或慈善捐助的访问；(5) 遵守各个 App Review 指南中的条款 (例如，不含令人反感的内容)；并且 (6) 不提供数字商品或服务进行销售。在被要求时，您必须提供 app 中所含软件和元数据的索引信息。它必须包含软件提供商的 Apple Developer Program 团队 ID，以及可供 App Review 团队用于确认软件符合上述要求的 URL。

4.8 通过 Apple 登录
如果 app 使用第三方或社交登录服务 (例如，Facebook 登录、Google 登录、通过 Twitter 登录、通过 LinkedIn 登录、通过 Amazon 登录或微信登录) 来对其进行设置或验证这个 app 的用户主帐户，则该 app 必须同时提供“通过 Apple 登录”作为同等选项。用户的主帐户是指在 app 中建立的、用于标识身份、登录和访问功能和相关服务的帐户。

在以下情况下，不要求提供“通过 Apple 登录”选项：

您的 app 仅使用公司自有的帐户设置和登录系统。
您的 app 是一款教育、企业或商务 app，要求用户使用现有的教育或企业帐户登录。
您的 app 使用政府或行业支持的公民身份系统或电子身份证来鉴定用户身份。
您的 app 是特定第三方服务的客户端，用户需要使用他们的邮件、社交媒体或其他第三方帐户直接登录才能访问内容。

5. 法律
只要 app 向某个地区的用户提供，那么就必须遵守该地区的所有法律要求 (如果您不太确定，请与律师联系)。我们知道这些东西非常复杂，但除了下方所列准则以外，同时理解所有本地法律，并确保您的 app 能满足所有法律要求，是您必须承担的责任。当然，如果 app 存在唆使、宣传或鼓励犯罪的行为或明显不负责任的行为，则会被拒*。在发现涉及如方便人口贩卖和/或剥削儿童的 app 的*端情况下，我们将通知有关当局。

5.1 隐私
在 Apple 生态体系中，保护用户隐私总是*要务。您要在处理个人数据时小心谨慎，以确保遵守了隐私保护*佳做法 (英文)、适用的法律和“Apple Developer Program 许可协议 (英文)”中的条款，并满足客户的期望。尤其是：

5.1.1 数据收集和存储
(i) 隐私政策：所有 app 必须在 App Store Connect 元数据栏位和 app 内部包含可轻松访问的隐私政策链接。隐私政策必须明确而清楚地：
指明 app/服务所收集的数据 (若有)、收集数据的方式，以及这些数据的所有用途。
确认与 app 共享用户数据 (遵从这些准则) 的任何第三方 (例如，分析工具、广告网络和第三方 SDK，以及能够访问用户数据的任何母公司、子公司或其他相关实体) 会提供与 app 隐私政策所述及这些准则所要求相同或等同的用户数据保护措施。
解释数据保留/删除政策，并且说明用户可以如何撤销同意和/或请求删除用户数据。
(ii) 许可 如果 app 会收集用户数据或使用数据，即使此类数据在收集当时或收集后即刻被匿名处理，app 也必须征得用户的同意才能收集。付费功能不得依赖于或要求用户授予访问这些数据的权限。App 还必须为客户提供简单易懂且易于操作的方式来撤销同意。确保您在用途说明中清楚且完整地阐述您对数据的使用。如果 app 依据欧盟《一般数据保护条例》(“GDPR”) 或类似法规，出于合法权益而不经事先同意就收集数据，则必须遵循此类法律的所有条款。进一步了解请求许可 (英文)。
(iii) 数据*少化：App 仅可请求访问与 app 核心功能相关的数据，并且仅可收集和使用完成相关任务所需的数据。若有可能，请使用进程外选取器或共享列表，而不要请求“照片”或“通讯录”等受保护资源的完整访问权限。
(iv) 访问权限：App 必须尊重用户的权限设置，不得操纵、欺骗或强迫用户同意不必要的数据访问。例如，可发布照片到社交网络的 app 不得在允许用户上传照片前要求麦克风访问权限。若有可能，请为不同意的用户提供替代解决方案。例如，如果用户拒*共享位置，请提供手动输入地址的功能。
(v) 帐户登录：如果 app 不包含基于帐户的重要功能，请允许用户在不登录的情况下使用。App 不得要求用户提供个人信息才能正常使用，除非个人信息与 app 的核心功能直接相关，或是法律要求时。如果您的核心 app 功能与特定的社交网络 (如 Facebook、微信、微博或 Twitter 等) 不相关，您必须提供无需登录或其他类似机制的访问权限。调取基本档案信息、分享到社交网络或邀请朋友使用 app 等不视为核心 app 功能。App 还必须包含用于撤销社交网络凭证的机制，以及从 app 内停用 app 与社交网络之间数据访问的机制。App 不可在设备外存储社交网络的凭证或令牌，而且只能使用此类凭证或令牌来在 app 使用期间从 app 本身直接连接社交网络。
(vi) 如果开发者开发的 app 试图暗中收集用户密码或其他用户私人数据，那么开发者会被从 Apple Developer Program 中除名。
(iv) 必须使用 SafariViewController 在显著位置向用户显示信息；不得隐藏这个控制器，也不能被其他视图或图层遮挡。此外，未经用户的知情和同意，app 不得私下利用 Safari 浏览器 ViewController 来追踪用户。
(viii) 汇编个人信息的 app，如果其来源未经用户的明确同意，或并非直接源自用户 (即使是公共数据库)，则不可在 App Store 中发布。
(ix) 在受到严格监管的领域 (如银行和金融服务、医疗保健和航空旅行) 提供服务或需要敏感用户信息的 app，应由提供相应服务的法律实体提交，而不能由个人开发者提交。
5.1.2 数据使用和共享
(i) 除非法律另有许可，否则您不得未经他人允许而使用、传输或共享他们的个人数据。您必须提供相应的信息，说明以何种方式在哪里使用这些数据。App 收集的数据只有在为了改进 app 或用于广告投放用途 (遵守 Apple Developer Program 许可协议 (英文)) 的前提下，才能与第三方共享。如果 app 在未经用户同意或未能符合数据隐私保护法律的情况下共享用户数据，则 app 可能会被下架，并且可能会导致您从 Apple Developer Program 中除名。
(ii) 除非法律另有明确许可，否则未经用户的额外同意，为一个用途而收集的数据不可用于其他用途。
(iii) App 不得试图暗中基于收集的数据构建用户资料，也不得尝试、协助或鼓励他人根据从 Apple 提供的 API 收集的数据，或您所谓以“匿名”、“汇总”或其他不可识别的方式收集的数据来识别匿名用户的身份或重建用户资料。
(iv) 请勿使用来自“通讯录”、“照片”或能访问用户数据的其他 API 的信息来构建联系人数据库，以供自己使用或出售/分发给第三方，也不要收集关于用户设备上安装有哪些 app 的信息，以用于分析或投放广告/市场营销。
(v) 请勿使用通过“通讯录”或“照片”收集的信息来联系用户，除非用户以个人方式明确主动发起联系；请勿包含“全部选择”选项，也不要默认选中所有联系人。在信息发送之前，您必须向用户清楚说明这个信息会如何呈现给收件人 (例如，信息中包含什么内容？发件人显示为谁？)。
(vi) 从 HomeKit API、HealthKit、消费者健康记录 API、MovementDisorder API、ClassKit 或深度图和/或面谱绘制工具 (例如 ARKit、相机 API 或照片 API) 收集的数据，不得用于市场营销、投放广告或基于使用情况进行其他数据挖掘，包括第三方在内。进一步了解实施 CallKit (英文)、HealthKit (英文)、ClassKit (英文) 和 ARKit 的*佳做法。
(vii) 使用 Apple Pay 的 app 只能与第三方共享通过 Apple Pay 获得的用户数据，以帮助或改进商品或服务的交付。
5.1.3 健康和健康研究
健康、健身和医疗数据特别敏感，涵盖这些领域的 app 必须满足额外的规则，并确保客户隐私受到保护：

(i) App 在健康、健身和医疗研究背景下收集的数据 (包括从临床健康记录 API、HealthKit API、“运动与健身”、MovementDisorderAPI 或健康领域人体研究中收集的数据)，不得因广告投放、市场营销或其他基于使用情况进行的数据挖掘 (除非获得批准，并出于改进健康管理或健康研究的目的) 而使用或向第三方披露。不过，App 可以使用用户的健康或健身数据直接向该用户提供权益 (如保费减免)，前提是 app 须由提供相应权益的实体提交，而且其数据不得与第三方共享。同时，app 必须清楚说明将从设备收集的具体健康数据。
(ii) App 不得将虚假或错误数据写入 HealthKit 或其他任何医疗研究/健康管理 App，不得在 iCloud 中存储个人健康信息。
(iii) 开展健康领域人体研究的 app 必须获得参与人员提供的知情同意书，如果涉及未成年人，则必须获得由其家长或监护人提供的知情同意书。上述知情同意书必须涵盖以下内容：(a) 研究的性质、目的和时长；(b) 具体规程，给参与人员带来的风险和益处；(c) 关于保密和数据处理 (包括与第三方共享信息的情况) 的信息；(d) 用于回答参与人员问题的联系人；以及 (e) 退出流程。
(iv) 用于开展健康领域人体研究的 app 必须获得一家独立伦理审查委员会的批准。一经要求，必须提供此类批准的证明。
5.1.4 儿童
出于诸多原因，您在处理儿童的个人数据时请务必小心谨慎。我们建议您仔细阅读所有要求，以遵循相关法律，如《儿童在线隐私保护法》(“COPPA”)、欧盟《一般数据保护条例》(“GDPR”) 以及任何其他适用的法律法规。

App 只能出于遵守适用儿童隐私法规的目的要求用户提供出生日期或家长联系信息，但必须提供一些适用于各年龄层用户的实用功能或娱乐价值。

主要面向儿童的 app 不应包含第三方数据分析或第三方广告。这些做法可为儿童提供更安全的体验。在少数情况下，可能允许包含第三方数据分析和第三方广告，前提是这些服务遵守上文“准则 1.3”中所述的条款。

此外，“儿童类别”中的 app，以及向未成年人收集个人信息 (例如姓名、地址、电子邮件、位置、照片、视频、图画、能否聊天、其他个人数据，或是将永久标识符与以上任何信息组合使用)、传输此类信息或能够共享此类信息的 app，则必须拥有隐私政策，且必须遵守适用的儿童隐私保护法规。为了清楚起见，“儿童类别”的家长监控要求，通常并不完全等同于在这些隐私法规下征得家长的同意后收集个人数据。

特此提醒，“准则 2.3.8”要求只有“儿童”类别的 app 才能在元数据中使用类似“适合幼儿”和“适合儿童”等词语。不属于“儿童”类别的 app 不得在 app 名称、副标题、图标、屏幕快照或描述中包含任何暗示 app 主要受众为儿童的词汇。

5.1.5 定位服务
只有在定位服务与 app 提供的功能和服务直接相关时，才能在 app 中使用定位服务。基于位置的 API 不得用于提供紧急服务，不得对汽车、飞机和其他设备 (轻量无人机和玩具等小型设备和汽车防盗系统的遥控等除外) 进行自主控制。在收集、传输或使用位置数据之前，务必进行通知并获得用户同意。如果 app 会使用定位服务，请务必在 app 中说明相应的原因；请参考“Human Interface Guidelines (英文)”，了解相应的*佳做法。

5.2 知识产权
请确保 app 只包含由您创建或拥有使用许可的内容。如果您已越线并在未经许可的情况下使用了内容，您的 app 可能会被移除。当然，这也意味着如果他人抄袭了您的作品，则他们的 app 也可能会被移除。如果您认为自己的知识产权在 App Store 上受到了其他开发者的侵犯，请通过此网页表格提交权利主张。各个国家/地区的法律互不相同，但请务必避免以下常见错误：

5.2.1 一般性：不得在未经授权的情况下，在 app 中使用受保护的第三方材料 (例如商标、版权作品、专利设计)；也不得在 app 套装或开发者名称中包含虚假、抄袭或误导性的演示、名称或元数据。App 提交方应当是拥有或获授权使用知识产权及其他相关权利的个人或法律实体。
5.2.2 第三方站点/服务：如果您的 app 会使用、访问第三方服务、通过访问第三方服务盈利或是显示第三方服务的内容，请确保您获得在该服务的使用条款下进行此类操作的特别许可。如有相应要求，则必须提供相关授权。
5.2.3 音频/视频下载：app 不得促进非法文件共享，或在没有获得这些资源的明确授权的情况下，提供从第三方来源 (如 Apple Music、YouTube、SoundCloud、Vimeo) 保存、转换或下载媒体资源的能力。视频/音频内容流也有可能触犯使用条款，所以请务必在 app 访问这些服务前，进行检查。如有相应要求，则必须提供相关文稿。
5.2.4 受 Apple 认可：不得误导或暗示 Apple 是 app 的来源或提供商，或者 Apple 以任何形式表示认可其质量或功能。如果您的 app 被选为“编辑选荐”，Apple 将自动显示相应徽章。
5.2.5 Apple 产品：不得创建与现有 Apple 产品、界面 (如访达)、app (如 App Store、iTunes Store 或“信息”) 或广告主题外观相似或容易混淆的 app。App 和扩展功能 (包括第三方键盘和贴纸包) 不得含有 Apple 表情符号。iTunes 音乐预览内容不得用于其娱乐价值 (如用作照片拼贴画的背景音乐或游戏配音) 或其他未获授权的方式。如果 app 显示健身记录圆环，则不应以类似于“健身记录”控件的方式展示“活动”，“锻炼”或“站立”数据。请参考“Human Interface Guidelines (英文)”以了解关于如何使用健身记录圆环的更多信息。
5.3 游戏、赌博和彩票
游戏、赌博和彩票的管理难度大，是 App Store 上受到*多管制的应用类别之一。只有全面核实了即将发布您 App 的所有国家/地区的相关法律要求后，才能包含此功能，并且要做好准备此功能的审核流程需要更长的时间。您需要谨记以下事项：

5.3.1 抽*和比赛必须由 app 的开发者赞助。
5.3.2 抽*、比赛和抽彩的正式规则必须在 app 中注明，并且必须明确表示 Apple 不是赞助者，也没有以任何形式参与活动。
5.3.3 App 不得通过 App 内购买项目购买点数或货币，以用于任何种类的真实货币游戏；不得向用户出售彩票或抽彩券；不得在 app 内进行资金转账。
5.3.4 提供真实货币游戏（例如体育下注、扑克、赌场游戏、赛马）或彩票的 App 必须在使用该 App 的地区获得必要的许可和批准，且只能在这些地区发布，此类 App 在 App Store 中必须免费提供。不允许在 App Store 上发布非法的赌博辅助工具，包括记牌器。彩票 App 必须有报酬、几率及*品。
5.4 * App
提供 * 服务的 app 必须利用 NE*Manager API (英文)，并且仅可由登记为企业的开发者提供。在用户进行任何操作来购买或以其他方式使用该服务之前，您必须在 app 屏幕上清楚地声明会收集哪些用户数据，以及将如何使用这些数据。无论出于任何目的，提供 * 服务的 App 不得出售、使用或向第三方披露任何数据；并且必须在隐私政策中做出这一承诺。* app 不得违反当地法律，如果您选择在需要 * 许可证的地区发布，则必须在 App Review 注释栏位中提供您的许可证信息。除此之外，经批准的提供商所提供的家长控制、内容拦截和安全 app 也可以使用 NE*Manager API。不遵循这项准则的 app 会被从 App Store 中移除，您也可能会被从 Apple Developer Program 中除名。

5.5 移动设备管理
提供移动设备管理 (MDM) 服务的 MDM App 必须向 Apple 请求此功能。此类 app 仅可由商业企业 (如商业组织、教育机构或政府机构) 提供；在少数情况下，也可由使用 MDM 提供家长控制服务或设备安全性的公司提供。在用户进行任何操作来购买或以其他方式使用该服务之前，您必须在 app 屏幕上清楚地声明会收集哪些用户数据，以及将如何使用这些数据。MDM app 不得违反任何适用法律。无论出于任何目的，提供 MDM 服务的 app 都不得出售、使用或向第三方披露任何数据；并且必须在隐私政策中做出这一承诺。在少数情况下，可能允许包含第三方数据分析，前提是相关服务仅收集或传输关于开发者的 MDM app 性能的数据，而不会收集关于用户、用户设备或该设备上其他 app 的任何数据。提供配置描述文件的 app 也必须遵守这些要求。不遵循这项准则的 app 会被从 App Store 中移除，您也可能会被从 Apple Developer Program 中除名。

5.6 开发者行为准则
请尊重每一个人，无论是在 App Store 中回复用户评论、回应客户支持请求时，还是与 Apple 沟通时 (包括您在解决方案中心的回复)，都应做到这一点。请勿涉及任何形式的骚扰、歧视、恐吓或霸凌行为，也不要鼓励他人实施任何上述行为。

客户的信任是 App Store 获得成功的基石。App 不得存在以下行为：掠夺用户或试图勒索用户；诱导用户进行非自愿的购买；强迫用户共享不必要的数据；以欺骗的方式抬高价格；针对未交付的功能或内容收取费用；或者在 app 内部或外部实施任何其他操纵行为。

5.6.1 App Store 评论
App Store 客户评论是 app 体验中不可或缺的一部分；因此，在回复客户的评论时，您应当对他们保持尊重。另外，您的回复应直接回应客户评论的主题，请勿在回复中包含个人信息、垃圾信息或营销广告。

利用我们提供的 API 提示用户评价您的 app：通过这项便利功能，客户无需离开 app，就可直接在 App Store 中留下评分和评论；不允许使用自定义的评论提示。

提交之后
在 App Store Connect 中提交 app 和元数据之后，您随即就会进入审核流程。请谨记以下几点：

时间：App Review 团队会尽快检查您的 app。不过，如果 app 比较复杂或者存在新的问题，则可能需要更深入的审查和考量。也请记住，如果 app 因为违反同一准则而一再被拒*，或者您曾经试图操纵 App Review 流程，您的 app 将需要更长时间才能完成审核。进一步了解 App Review。
状态更新：App 的当前状态会反映在 App Store Connect 中，所以请多留意此处。
加急请求：如果您遇到了严重的时间问题，可以申请加急审核 (英文)。请仅在您真的需要加快审核时才提出申请，以便其他开发者的加急请求不受影响。如果我们发现您滥用此系统，从此以后我们可能都会拒*您的申请。
发布日期：如果您为 app 设定了在未来某个日期发布，即使该 app 提前通过了 App Review 团队的审核，在设定的发布日期前也不会显示在 App Store 上。请注意，您的 app 可能需要长达 24 小时才能显示在所有选定的商店中。
拒*：我们的目标是公平、持续地遵循这些准则，但是人无完人。如果您的 app 被拒*，但您存在疑问，或希望提供其他信息，请使用解决方案中心，以与 App Review 团队直接沟通。这样可以帮助您的 app 出现在商店中，也可帮助我们改进 App Review 流程，并在我们的政策中发现需要阐明的部分。如果您仍对结果不满意，请提交申诉 (英文)。

1. 条款和条件

• 1.1 为App Store开发程序，开发者必须遵守 Program License Agreement (PLA)、人机交互指南（HIG）以及开发者和苹果签订的任何其他协议和合同。以下规则和例证旨在帮助开发者的程序能获得App Store的认可，而不是修改或删除任何其他协议中的条款。

2. 功能
• 2.1 崩溃的程序将会被拒*。
• 2.2 存在错误的程序将会被拒*。
• 2.3 跟开发者宣传不符的程序将会被拒*。
• 2.4 无应用文档或隐藏功能与描述不符的程序将会被拒*。
• 2.5 使用非公开API的程序将会被拒*。
• 2.6 在指定容器范围外读写数据的程序将会被拒*。
• 2.7 以任何方式或形式下载代码的程序将会被拒*。
• 2.8 安装或运行其他可执行代码的程序将会被拒*。
• 2.9 Demo版、trial版和test版的程序将会被拒*。 Beta版应用程序可通过TestFlight提交，并且必须遵守相关指南。（此前并未允许Beta版通过TestFlight提交）
• 2.10 iPhone程序必须不经修改就能以iPhone分辨率和2倍 iPhone 3GS的分辨率在iPad上运行。
• 2.11 与App Store已有程序重复的应用可能会被拒*，特别是数量很多的情况下，比如手电筒应用和爱经应用。
• 2.12 没有显著用途、不独特的应用程序或者与网站简单捆绑的应用有可能被拒；不提供任何持久娱乐价值的程序可能会被拒*。
• 2.13 内容主要是营销材料或广告的程序将会被拒*。
• 2.14 包含欺骗或虚假功能，却有没有标明的应用程序将会被拒*。
• 2.15 大于100MB无法通过蜂窝网络下载的应用（App Store会自动禁止）。
• 2.16 多任务程序使用后台服务仅限于几种目的：VoIP、音频播放、地理位置、完成任务以及本地提醒等。
• 2.17 应用程序只允许使用iOS WebKit框架和WebKit Javascript浏览web内容。
• 2.18 鼓励酗酒或使用违禁药物，或引诱青少年饮酒或吸烟的程序将会被拒*。
• 2.19 提供错误的系统诊断或不精确的设备数据的应用将会被拒*。
• 2.20 向App Store上传大量相似版本程序的开发者将会从iOS开发者计划中除名。
• 2.21 简单一首歌曲或者一部影片应用要提交到iTunes store，书籍类应用应该提交到iBookstore。
• 2.22 随意根据环境（如定位或者运营商）限制用户使用的应用会被拒。
• 2.23 应用必须遵守iOS数据储存指导方针（iOS Data Storage Guidelines ），否则应用将被拒。
• 2.24 存放在Newsstand的应用必须遵守开发者项目许可协议（Program License Agreement）的表1、表2以及表3，否则应用将会被拒。
• 2.25 类似App store，或者基于购买或者促销的目的而展示其他应用的应用将会被拒* （限制更加严格，此前经过特殊审核批准(比如健康管理、航空以及其他无障碍需求等)，或者为特殊群体用户提供具有重大意义的附加值的应用是可以通过的）
• 2.26 只有当app是出于特殊审核需要（比如健康管理、航空以及无障碍需求等）或为特殊群体用户提供具有重大意义的附加值时，才可以展示和推荐自身以外的其他应用程序，否则应用程序将会被拒*。

3. 元数据（名称、描述、评级、排名等） 近来厂商踩雷屡见不鲜，此部分请详细阅读
• 3.1 应用或者元数据中提到其他任何移动平台将会被拒。
• 3.2 带有占位符文本的程序将会被拒*
• 3.3 应用程序的名称、描述、截图或者预览与应用的内容和功能不相关将会被拒*。 （此前仅对描述有所限制 ）
• 3.4 为了不混淆用户，iTunes Connect中的应用名称应该和展示在设备上的应用名称一致。
• 3.5 不同尺寸的app icon要一致，否则会造成混淆。
• 3.6 图标、截图以及预览不符合4+年龄评级的程序将会被拒*。 （增加了对预览的限制）
• 3.7 目录与类型不适合于程序内容的程序将会被拒*。
• 3.8 开发者有责任为其程序指定适合的评级。不相称的评级可能会由苹果公司修改。
• 3.9 开发者有责任为其程序指定恰当的关键字。不恰当的关键词可能会被苹果公司修改/删除。
• 3.10试图通过伪造评论或者付费评论的方式在AppStore中操纵或者其欺骗用户评论（或者采用其他不正当方式）以提升排名的开发者将会被苹果从iOS开发者计划中除名。
• 3.11 在安装或打开应用之前，推荐用户重启iOS设备的应用将会被拒。
• 3.12 提交审核的应用程序应包含能正常运行的URL，比如支持服务URL和隐私政策URL。
• 3.13 应用程序的截图、预览或者营销文本没有清晰地指出附加内容或项目需要额外单独购买（比如使用IAP）将会被拒*。
• 3.14 App预览仅能使用从应用程序捕获的视频屏幕、旁白、文本以及design overlays，否则应用程序将会被拒*。
• 3.15 添加App预览的应用程序，未经许可展示真人个人信息将会被拒*。
• 3.16 App预览仅能使用在所有选定地区内经过授权许可、用于此目的的音乐。
• 3.17 App预览包含未经授权的通过app播放的内容（比如iTunes playlist和YouTube流媒体）的应用将会被拒*。

4. 位置
• 4.1 在收集、传输或使用位置数据之前未通知并获得用户同意的程序将会被拒*。
• 4.2 将基于位置的API用于车辆、飞机或其他设备的自动控制或自主控制的应用程序将会被拒*。
• 4.3 使用基于位置的API用于应急服务的应用程序将会被拒*。 （此处进行了描述修改，未着重指出调度和车队管理）
• 4.4 当与提供的功能或服务密切相关，或者为支持经过授权的广告时，应用程序才可以使用位置数据。

5. 推送通知
• 5.1 不使用苹果推送通知 (APN)应用接口提供推送通知的程序将会被拒*。
• 5.2 未从苹果获得Push Application ID便擅自使用APN服务的程序将会被拒*。
• 5.3 在首次推送消息或者要求运行推送通知之前未获得用户许可的应用将会被拒*。
• 5.4 使用推送通知发送敏感个人信息或机密信息的程序将会被拒*。
• 5.5 使用推送通知发送非请求消息，或用于钓鱼或群发垃圾信息用途的程序将会被拒*。
• 5.6 应用程序不可使用推送通知发送广告、促销或任何类型的直销信息。
• 5.7 应用程序不能向使用推送通知服务的用户收取费用。
• 5.8 使用推送通知会过多利用APN服务的网络流量或带宽或给设备带来过度负担的程序将会被拒*。
• 5.9 如果应用程序传送病毒、文件、计算机代码或程序，并且对APN服务的正常运行造成损害或中断，那么该程序将会被拒*。

6. 游戏中心
• 6.1 向终端用户或任意第三方显示玩家ID的程序将会被拒*。
• 6.2 将玩家ID用于任何未经游戏中心条款批准用途的程序将会被拒*。
• 6.3 试图进行反向搜索、跟踪、关联、挖掘、获得或利用玩家ID、别名或通过游戏中心获得其他信息的开发者将会iOS开发者计划除名。
• 6.4 游戏中心信息（例如排行榜分数），只能用于游戏中心批准的应用程序中。
• 6.5 利用游戏中心服务发送非请求信息，或用于钓鱼或群发垃圾邮件的程序将会被拒*。
• 6.6 过多使用游戏中心网络流量或带宽的应用程序将会被拒*。
• 6.7 如果程序能够传送病毒、文件、计算机代码或程序，并且对游戏中心服务的正常运行造成损害或中断，该程序将会被拒*。

7. 广告
• 7.1 人工刷广告浏览量或者广告点击率的应用程序将会被拒*。
• 7.2 包含空iAd广告的应用程序将会被拒*。
• 7.3 主要设计目的在于显示广告的应用程序将会被拒*。

8. 商标与商品外观
• 8.1 应用程序必须遵守”Guidelines for Using Apple Trademarks and Copyrights”和”Apple Trademark List”中说明的所有条款与条件。
• 8.2 任何误导和暗示苹果公司是该应用程序来源或提供商，或者苹果公司以任何形式表示认可其质量或功能的应用程序将会被拒*。
• 8.3 与目前已有苹果产品或者广告主题外观相似或混淆的应用程序将会被拒*。
• 8.4 在应用程序名称中将苹果产品名拼错的应用程序（例如，GPS for Iphone，iTunz）将会被拒*。
• 8.5 应用程序不得使用受保护的第三方材料（比如商标、版权以及专利），不能违反第三方使用条款。必须提供使用这些材料的授权许可。
• 8.6 若无明确授权许可，从第三方来源处（比如YouTube、SoundCloud以及Vimeo等）下载音乐或者视频内容的应用程序将会被拒*。

9. 媒体内容
• 9.1 不使用媒体播放器框架（MediaPlayer Framework）获取音乐库中媒体内容的应用程序将会被拒*。
• 9.2 用户界面模仿任何iPod或者iTunes界面的应用程序将会被拒*。
• 9.3 通过蜂窝网络传输的音频流内容每5分钟不得超过5MB。
• 9.4通过蜂窝网络传输超过10分钟的视频流内容必须使用HTTP Live Streaming协议，并且要包含一个基线为192kbps或者更低的HTTP实时流。

10. 用户界面
• 10.1 应用程序必须遵守苹果的《iOS Human Interface Guidelines》中所有的条款和条件。
• 10.2 外观与iPhone自带应用（比如App Store、iTunes Store和iBookstore）相似的应用程序将会被拒*。
• 10.3 未能按苹果《iOS Human Interface Guidelines》描述正确使用系统提供的项目（比如按钮、图标）的应用将会被拒*。
• 10.4 创建桌面/主屏幕环境或者模拟multi-App插件体验的应用程序将会被拒*。
• 10.5 修改音量大小和铃声/静音等标准开关功能的应用程序将会被拒*。
• 10.6 苹果和我们的客户高度推崇简单、精致、富有创造性以及经过精心设计的界面。虽然需要付出更多，但却非常值得。苹果设立了很高的门槛。如果你的用户界面太过复杂或者水准不高，可能会被拒*。

11. 购买与货币流通
• 11.1 使用App Store以外的渠道解锁或开启附加属性和功能的应用程序将会被拒*。
• 11.2 使用应用内支付系统（IAP）以外的系统购买内容、功能或服务的应用软件将会被拒*。
• 11.3 使用IAP购买实物商品或者用于该软件之外的商品和服务的应用软件将会被拒*。
• 11.4 使用IAP购买积分（信用点）或者其他货币必须在本应用中消费。
• 11.5 使用IAP购买已过期积分或其他货币的应用软件将会被拒*。
• 11.6 使用IAP订阅的内容至少要持续7天，而且允许在用户的其他iOS设备间共享。
• 11.7 使用IAP购买项目的应用程序必须指派正确的购买类型。
• 11.8 使用IAP购买iOS内置功能（如照相机，陀螺仪）的应用程序将会被拒*。
• 11.9 含有超过限定时间的内容或服务的应用程序将会被拒*，除经特定批准的内容（比如电影、电视节目音乐以及书籍）。
• 11.10 保险类应用程序必须免费，要遵守发布地区的法律，并且不能使用IAP。
• 11.11 一般而言，你的应用程序越贵，我们的评审会越深入。（对不起，我们国产大部分是免费网游）
• 11.12 提供订阅功能的应用必须使用IAP，苹果将会按照 Developer Program License Agreement 中的约定与开发者按30/70比例分成。
• 11.13 在应用内使用跳转至外部购买或订阅链接的应用将会被拒，比如”buy”按钮跳转至一个购买电子书的web页面。
• 11.14 只要应用内没有跳转至外部购买、订阅的按钮或链接，苹果允许这些应用读取或展示经批准的、在应用外购买或订阅内容(特别是杂志、报纸、书籍、音频、音乐、视频以及云存储内容)。苹果只能通过应用程序内的购买获得一部分收益。
• 11.15 应用程序可以只使用自动更新订阅期刊(报纸、杂志)、商业应用程序(企业类、效率类、专业创意类以及云存储类)和媒体类应用程序(视频、音频、声音)，否则应用程序将被拒*。
• 11.16 当与特定的经过审核的实体产品（比如玩具）结合使用时，应用程序可以使用获得批准的附加特性和功能，只要附加功能完全依赖于该硬件产品（比如一款用于控制望远镜的应用程序）或者也可以在不使用实物产品的情况下使用应用程序，比如成就*励或者使用IAP。
• 11.17 如果应用功能遵照各州和联邦法律，那么应用可以用来促进被认可的虚拟货币的流通。

12. 抓取和聚合
• 12.1 从苹果网站（例如apple.com、iTunes Store、App Store、iTunes Connect以及Apple Developer Programs等）抓取任何信息或者使用苹果网站内容和服务进行排名的应用程序将会被拒*。
• 12.2 应用软件可以使用获得批准的苹果RSS feeds，例如iTunes Store RSS feeds。
• 12.3 只是简单的网页剪切、内容整合或者收集链接的应用程序可能会被拒*。

13. 损害设备
• 13.1 怂恿用户以可能造成损害的方式使用苹果设备的应用软件将会被拒*。
• 13.2 快速耗光设备电量或产生过多热量的应用软件将会被拒*。
• 13.3 能导致用户人身伤害的app将会被拒*。

14. 人身攻击
• 14.1 涉及诽谤、人身攻击性质以及内容狭隘卑鄙的应用软件或者打击特定个人或组织的应用软件将会被拒*。
• 14.2 职业政治讽刺家和幽默作家不受这一条款约束。（开门，查水表）
• 14.3 展示用户创作内容（UGC）的应用程序必须提供一个过滤不良资讯的方法，一个用户可以标记侵犯性内容的机制，以及可以阻止辱骂用户的能力。

15. 暴力 （此前传禁枪的消息并未在条款中明确指出）
• 15.1 应用程序中出现人或动物被杀、致残以及枪击、刺伤、拷打等受伤情形的真实画面将会被拒*。
• 15.2 出现描绘暴力或虐待儿童等内容的应用程序将会被拒*。
• 15.3 游戏中出现的”敌人”不可指向一个特定种族、文化、一个真实存在的政府、企业或者其他任何现实中的实体。
• 15.4 对武器进行真实描述以怂恿非法使用或滥用这些武器的应用程序将会被拒*。
• 15.5包含俄罗斯轮盘赌博内容的游戏将会被拒。

16.令人反感的内容
• 16.1 应用程序中出现过于令人反感或者低俗的内容将会被拒*。
• 16.2 在设计上激怒用户或令人感到厌恶的应用程序将会被拒*。

17.隐私
• 17.1 在未经用户事先许可，或未告知用户如何使用信息以及在何处使用信息的情况下，应用程序不能传输用户数据。
• 17.2 要求用户共享电子邮箱地址和出生日期等私人信息才可使用其功能的应用程序将会被拒*。
• 17.3 仅出于遵守适用的儿童隐私法规的目的，应用程序可以要求用户的出生日期（或者使用其他年龄评级机制），但是必须包括一些有用的功能或者娱乐价值，不管用户年龄大小。
• 17.4 收集、传输以及分享未成年用户个人信息（比如名字、地址、邮件、位置、照片、视频、绘画、聊天信息以及其他个人数据，或者与以上所述相关的永久性标示符）的应用程序必须遵守应用儿童隐私法规，并且必须包含隐私条款。
• 17.5 包含账号注册或者访问用户现有账号的应用程序必须包含隐私策略，否则将会被拒*。

18. 色情
• 18.1 含有色情素材，也就是《韦氏词典》中定义的”旨在激发情欲，对性器官或性行为的明确描述或展示，而无关美学或情绪感受”的程序将会被拒*。
• 18.2 包含用户频繁提供的色情内容的应用程序（比如以前的“Chat Roulette”程序）将会被拒*。

• 19.宗教，文化与种族
o 19.1 涉及宗教、文化或种族群体的引用或评论包含诽谤性、攻击性或狭隘内容，或会使特定群体遭受伤害或暴力的应用程序将会被拒*。
o 19.2 程序可以包含或引用宗教经文，程序所提供的引用或翻译必须准确且不会引起误导。评论应该有教育意义，可以令人开阔眼界，而不应有煽动性。

20. 竞赛、赌博、彩票以及抽*
• 20.1 彩票抽*和竞赛必须由应用程序的开发者或者app所属公司发起。
• 20.2 应用程序必须展示彩票抽*和竞赛的正式规则，并声明苹果不是发起者，也没有以任何方式参与活动。
• 20.3 开发者运营一款具有抽*性质的应用必须经过法律允许，并且抽*应用必须具备以下特征：报酬、运气以及*品。
• 20.4 允许用户在应用中直接购买彩票或彩券的应用将会被拒。
• 20.5 提供真钱游戏（比如体育博彩、扑克牌、赌场游戏、赛马以及彩票）的应用程序必须有应用程序适用地区当地必要的许可和允许，必须限制在这些区域，必须可以从App Store免费下载。
• 20.6 使用IAP购买信誉或者货币，且结合真钱游戏的应用将会被拒*。

21.慈善与援助
• 21.1 包含可以向已认证的慈善组织捐赠功能的应用程序必须是免费的。
• 21.2 捐赠款项的募集必须通过Safari浏览器访问web页面或是手机短消息完成。

22. 法律要件
• 22.1 应用程序必须遵守所有发布地区当地法律，开发者有义务了解并遵守所有当地法律。
• 22.2 包含虚假，欺诈或误导性陈述的程序将会被拒*。
• 22.3 任何用于招徕、促进或鼓励犯罪或明显鲁莽行为的应用程序将会被拒*。
• 22.4 支持非法文件共享的程序将会被拒*。
• 22.5 被设计用以非法赌博工具的应用程序（包括点算牌）将会被拒*。
• 22.6 具有匿名或恶作剧拨打电话或发送类似短信/彩信功能的程序将会被拒*。
• 22.7 任何开发暗中收集用户密码或用户私人数据程序的开发者将会从iOS开发者计划中除名。
• 22.8 包含非执法机构发布的DUI检查点信息，或者怂恿/协助酒后驾车的应用将会被拒*。
• 22.9 计算药剂用量的应用程序必须由药品制造商或者认可机构发布，比如医院、保险公司以及高校。
• 22.10.在未授权的情况下使用iTunes音乐预览的应用程序将会被拒*。

23. Passbook
• 23.1 Passbook Passes可被用来支付或者接收支付，传递商业信息或者提供验证（比如电影票、飞机票、优惠券以及其他），但把Passbook Passes用于其他用途的应用程序可能会遭到拒*，并且会被撤销Passbook证书。
• 23.2 Passes必须包含有效的pass发行人有效的联系资料，否则app将会被拒*，并且Passbook证书也会被取消。
• 23.3 Passes必须经过实体签名，并基于其名字、商标或者品牌进行分发，否则应用程序将会被拒*，而Passbook证书也可能会被撤销。

24.儿童类别
• 24.1 儿童类别中的应用程序必须包含隐私政策，必须遵守适用的儿童隐私法规。
• 24.2 儿童类别中的应用程序不允许包括行为广告（比如app内部基于用户行动的服务广告），任何在应用程序中展示的上下文广告必须适合儿童。
• 24.3 儿童类别中的应用程序必须得到家长许可或使用parental gate才能链接至应用程序外部或进行交易。
• 24.4 儿童类别中的应用程序必须标明”5岁以下，6-8岁或者9-11岁”。

25.扩展
• 25.1 包含扩展的应用程序必须遵照 App Extension Programming Guide要求。
• 25.2 包含扩展的应用程序必须提供某些功能（辅助屏幕，附加设置），否则将会被拒*。
• 25.3 如果扩展的视图中包含营销推广、广告或者IAP内容，那么包含该扩展的应用将会被拒*。
• 25.4 键盘扩展必须提供一个切换至下个键盘的方法。
• 25.5 键盘扩展必须具有离线访问功能，否则将会被拒*。
• 25.6 键盘扩展必须提供和 App Extension Programming Guide 描述一致的数字和十进键盘类型，否则将会被拒*。
• 25.7 提供键盘扩展的应用必须拥有基本的功能分类和隐私政策，否则将会被拒*。
• 25.8 提供键盘扩展的应用程序只允许收集用户活动以增强键盘扩展在iOS设备上的功能，否则将会被拒*。

26.HomeKit
• 26.1 使用HomeKit框架的应用程序必须有提供家庭自动化服务的主要目的。
• 26.2 使用HomeKit框架的应用程序必须在营销文本中说明用途，同时必须提供隐私政策，否则将会被拒*。
• 26.3 应用程序不允许将从HomeKit API收集的数据用于广告宣传或者其他基于使用的数据挖掘。
• 26.4 出于其他目的使用从HomeKit API收集的数据，而不是用于提高用户体验或者家庭自动化功能中硬件/软件性能，这类应用将会被拒*。

27.HealthKit
• 27.1 使用HealthKit或者ResearchKit框架（出于健康目的用于进行人体生物学研究的框架）的应用程序，必须遵守其所有适用区域的法律，以及iOS Developer Program License Agreement中的3.3.28和3.39条款。（增加了对于ResearchKit框架的支持）
• 27.2 将虚假或者错误的数据写入HealthKit的应用程序将会被拒*。
• 27.3 使用HealthKit框架的应用程序在iCloud中储存用户健康信息将会被拒*。
• 27.4 应用程序不允许将通过HealthKit API收集的用户数据用作广告宣传或者基于使用的数据挖掘目的，除了改善健康、医疗、健康管理以及医学研究目的。
• 27.5 未经用户许可与第三方分享通过HealthKit API获得的用户数据的应用程序将会被拒*。
• 27.6 使用HealthKit框架的应用程序必须在营销文本中说明集成了Health app，同时必须在app用户界面清楚阐释HealthKit的功能。
• 27.7 使用HealthKit框架的应用程序必须提供隐私政策，否则将会被拒*。
• 27.8 提供诊断、治疗建议，或者控制诊断疾病的硬件，或者治疗疾病的应用程序，若没有根据要求提供书面的监管审批，将会被拒*。
• 27.9 收集人体生物学研究相关数据的应用程序必须要获得参与者的许可，对于未成年人，应用程序要得到其父母或者监护人的许可。许可内容必须包括：(a)研究的性质、目的以及持续性；(b)参与流程、风险以及受益（福利）；(c)信息的机密性和数据处理（包括与任何与第三方的共享）；(d)参与者问题切入点；(e) 取消方法（新增）

28.TestFlight
• 28.1 应用程序仅能使用TestFlight对以公开发布为目的的应用进行beta版测试，且必须遵守完整的App Review Guidelines。
• 28.2 当版本中包含的内容或功能有重大变化时，使用TestFlight的应用程序必须提交审核。
• 28.3 使用TestFlight的应用程序不允许分发给测试者，以作为任何形式的补偿。

29. Apple Pay
• 29.1 使用Apple Pay的应用程序必须在出售任何商品或者服务之前为用户提供所有材料的购买信息，否则将会被拒*。使用Apple Pay进行定期付款的应用程序必须提供*低限度续费期限，付费将持续直至被取消，每个阶段所付款额，费用付款归属，以及如何取消等。（增加了对于定期付款的规定）
• 29.2 使用Apple Pay的应用程序必须正确使用 Apple Pay Human Interface Guidelines 中的Apple Pay标识和用户界面元素，否则将会被拒*。
• 29.3 使用Apple Pay作为购买机制的应用程序所提供的商品或服务不能触犯任何交付地范围内的法律，也不能用作任何非法目的。
• 29.4 使用Apple Pay的应用程序必须提供隐私政策，否则将会被拒*。
• 29.5 只有为了促进或提高商品和服务的交付，或者依照法律要件，使用Apple Pay的应用程序才能与第三方分享通过Apple Pay获得的数据。

从一个小故事开始讲起

在几年前我们刚开始做 ToB 的 SDK 的时候，曾经对接过一家做社交 App 的公司，对方的技术负责人很年轻也很务实。在商务大哥给力的努力下，客户成功完成了产品的接入，并进入线上灰度阶段。

然而，在开始灰度的那天晚上，线上用户出现了很多消息延迟大的投诉，用户的一条消息需要很长时间才能发出去。客户虽然对我们很失望，但依然很努力地在配合我们排查和修复问题。

在两天的时间里，我们给客户改进了多个版本，每次给版本的时候我们都说“已经找到问题了，这个版本肯定可以”，但每次效果都不理想。两天之后，客户的技术负责人很严肃地询问了我们一个问题：“从这两天的排障过程和修复过程来看，我想确认一下你们这是一款商用级的产品吗？”

在那个晚上，我们开始冷静地思考一个问题：一款优秀的商用级 SDK 应该怎么做？

一年的努力功亏一篑

*近教育行业被政策打压地非常厉害，但在两年前，这是个 PaaS 服务的兵家必争之地。我们有一家做在线英语教学的客户，一直在对接我们的 TRTC。这个客户对质量要求非常苛刻，他们很早便引入了赛马机制，将多家 PaaS 服务商拉入到自己的供应商集群，互为灾备，并进行质量评估，看谁的质量好就用谁的产品。

在*开始对接的时候，我们的产品质量还不是很优秀，几个关键指标跟竞品都有差距。这倒不是问题，优化总要有一个过程，于是我们一个迭代一个迭代地去跟进。因为客户的版本发布速度非常慢，所以我们需要在两个版本之间都做好问题分析和优化落地，稳抓稳打地慢慢降低工单率。就这样，经过了将近一年的时间，产品各项指标都已经很不错了，我们非常有信心在下一个版本超过友商获得质量上的*地位。

但就在我们信心满满地等待客户上线的灰度反馈时，客户突然抛出一个问题：“你们的 SDK 有一个对音频模块的自动重启逻辑，这个逻辑会在切换线路时影响到其他供应商的音频模块， 这是*对不能容忍的”。因为引入多家供应商赛马的意义就在于保证可以有灾备，如果一家供应商影响了其他供应商的稳定性，这个灾备便没有了意义，因此客户对我们异常失望，放量计划无限期搁置。

面对一年的努力功亏一篑，我们开始接受一个现实：每位同事都可能会因为手滑引入缺陷，但对团队而言代价却是难以承受的，怎么办？

回到正题，接下来我会介绍一下过去的这些日子里，我们怎么去应对这个问题。不过在此之前，我需要先介绍一下我们的产品：

我们是做什么的？

我们团队所开发的是一套面向企业级客户的 SDK，包括用于实时音视频通讯的 TRTC SDK；用于消息通信的 IM SDK；用于直播推流和播放的 LIVE SDK ；以及用于短视频录制和编辑的 UGC SDK。

产品面向的客户群很多：有做泛互联网行业的，比如在社交领域长期霸榜苹果应用商店的某知名 App；也有在线教育领域的很多知名机构，教学模式包括 1V1、小班课、大班课等等；也有金融和保险领域的巨无霸，他们会使用我们的产品将现有的业务尽快地跟互联网融合；还有各行各业的中小型企业，他们虽然可能并不出名，但确实支撑我们国家互联网经济持续繁荣的基石；对了，还有做毕业设计的学生，虽然他们不会付费，但保不齐人家会在毕业后给自己的老板推荐我们的产品呢。

面对这么多行业领域的客户，有喜有忧，喜的是这是一桩很好的生意，忧的是这里有着车载斗量的压力：因为 SDK 这种形态的技术产品，如果要面向企业客户去服务，那真是打从娘胎里一出来就注定了坎坷的一生。

首先是客户群体：

• 客户所属行业分布广，教育、泛互、金融，不同的客户对产品的需求差异性大。
• 客户接入周期长，大客户在接入过程中会不断追加新需求和新特性，与此同时，客户对交付周期要求又很苛刻。

然后是产品形态：

• SDK 对专业性要求是比较高的，别人家的客户都只需要理解 http 的 get 和 post 就行了，俺们家的客户就得知道多线程安全、内存泄漏、前后台切换，苹果隐私合规要求，还有 android 的 gradle 配置方法和 windows 的 stl 兼容问题…
• 涉及平台众多，iOS、Android、Windows、Mac、Web，每个方向都需要很长时间的积累和沉淀。同时，在微信的强大的影响力面前，我们又增加了一个新的平台——微信小程序。

*后是交付成本：

• SDK 完成接入后，成不成要依赖客户的*终反馈，但往往客户的反馈周期很长，迭代周期也很长。
• SDK 版本多，平台多，这也就意味着测试工作是海量的。就说一个细节，这么多平台和版本，全量编译都需要两个小时，转测和发版就更不用说了。

面对这个问题，我们的友商做法是：加人。

当然，我们不能这么简单粗暴，毕竟粗放型经济是走不远的，我们还是得从研发体系上用集约的思想去解决问题，这就是接下来要说的重点：从研发、产品、数据和排障等四个方向去认认真真做好一款面向企业服务的 SDK 产品。

研发体系的优化

在研发体系方面，我们依然遵循腾讯倡导的需求评审=>技术评审=>开发=>测试的流程。但每个环节，我们都结合自身的特点进行了改进。

1. 怎么做需求评审？

首先是需求评审，我们团队经过这几年的打拼，总结出来*关键的一个点，就是看需求一定要看客户背后的意图。有时候客户会跟你说：“我想要你给我增加一个设置视频分辨率和码率的接口”。这个时候你要不要加呢？如果我们只是看客户的需求，那是要加的。但如果我们再问问，“您为什么需要我们加这个接口呢？” 那客户可能就会跟你说：“我觉得你们的画质不行，不够清楚，我要自己调，我要调清楚一点。” 这个时候我们就明白了，我们的需求不是“去增加一个可以设置视频分辨率和码率的接口”，而是去“提升我们的画质以满足客户的需求”。

这两者是不对等的，因为前者客户可能认为只要分辨率调到 4K 就是清晰的，但客户可能误以为“清晰度”就等同于“分辨率”，所以往往会指定一个 4K 的分辨率，却配置了一个 40Kbps 的视频码率。懂音视频的朋友都知道，这样的画面是模糊地没法看得。所以我们在简单版的 API 接口中，都不开分辨率设置接口，而仅仅是提供一个画质等级的接口，以避免客户的错误配置。但我们在得知客户的意图之后，会去了解客户为什么觉得我们画质不行，是跟哪款产品比有差距。进而分析是提升颜色矩阵转换的精度，还是在前处理的*后增加一道锐化，还是视频分辨率不匹配显示分辨率导致的问题，还是 OpenGL 的线性变换和就近变化的差异问题。

2. 怎么做技术评审？

这个部分，我们一般会鼓励大家提供两个以上的方案，然后进入“左右互搏”的模式。因为很多可爱的同事本身也是可爱的急性子，只要能早点写代码，什么都是不重要的。毕竟咱们做研发的成就感，不就来自于把功能做出来看到自己的成果吗。

但我们也不断地告诫自己，我们究竟是做“一票子买卖”还是是“百年老店的生意”。如果是前者，那大可以想到哪里代码就写到哪里；但如果是后者，则需要我们综合考虑多个方案，选择更能可持续发展的方案。

要知道在 ToB 这个领域，我们一不注意就会把自己陷入到做定制需求的套路里。面对业务压力，一开始这样是很解渴的，但随后的维护成本就让自己彻底吃不消了，每天除了救火什么都干不了的团队，也就失去了创造新价值的能力。

3. 怎么做代码合入？

在代码合入方面，我们团队在很早的时候就引入了一套非常严格的代码评审流程，即三级评审：

• CR 一级：模块的维护者来 review，这一级的目的是让模块的稳定性能够得到保障。毕竟在别人家的田间地头种自己的庄稼，你总不能背着这块地的主人搞小动作不是。
• CR 二级：自己的 leader 来 review，这是我们整个 CR 的核心基石。很幸运团队有像 taopu 一样负责和认真的 leader，会非常细致的 review 大家的每一行代码，并积*提出意见和建议，在 CR 中提升大家的技术水平。
• CR 三级：总监负责 review 和 代码合入，这一步更多是抽检，看看哪些同事是真正地爱这款产品，哪些同事则是不那么负责的架构破坏者。

4. 怎么做功能测试？

*近半年在测试团队，尤其是 svein 和俊哥的大力支持下，我们的自动化测试进步*大。不管是 native sdk 还是 webrtc sdk，自动化测试都能覆盖掉很多刁钻和难以手工覆盖的部分。比如一次通话过程中几十次的“进进出出”，或者是频繁的切换某个状态，这些都是以往手工测试很容易把人逼疯的部分。益于测试团队的持续投入，目前我们的自动化测试系统已经小有成绩。要知道，构建一个面向音视频功能的自动化测试体系，那难度可是非常高的。仔细想想就知道这里面有多少破事儿要解决：

• 怎么确认画面出来了？
• 怎么确认声音是正常的?
• 怎么构造复杂的测试流程和测试序列?
• 怎么保证测试环境的稳定和不被干扰?
• 还有*艰苦的：怎么找到足够多又耐操的手机，尤其是水果牌的。

通过需求评审、技术评审、代码审查和自动化测试的多重保护，我们*近已经很久没有再发生前面说的第二个故事里的事情了。即使有些同事一时手滑引入了一些问题，也大都能在 SDK 交付前得到暴露，只是目前我们并不能将这个概率降低到 0% 而已。

产品体系的优化

作为一款自身不带界面的 SDK，要做到产品体系的优化，就只能去优化技术本身，但这是枯燥且不好度量的。俗话说得好，“文无*，武无第二”，说的就是评判标准的问题。这就好比你画一幅画，如果没有老师指点你怎么才算好，那就会很难度量自己这段时间是水平提高了还是退步了。不然人家丢勒一个德国人，干嘛两次跑到意大利的威尼斯去学画画；又不然怎么会出现很多画家都是在那啥之后才有人开始欣赏他们的作品的呢？

所以说，作为一款面向 ToB 客户的 SDK 产品，要提升产品质量，就得有一些手段和方法，我们是这么做的：

方法一：通过场景落地来验证产品质量

我们做 TRTC SDK，我们的客户拿 TRTC SDK 的能力去做合唱，去做 K歌，去做语音聊天室，去做视频直播。那我们就只是做好自己的一亩三分地吗？

当然不行，所以我们自己也实打实地开发了一些面向行业场景的 App（也可说是 Demo），比如合唱、语聊、教育、直播等等。并在这些场景的开发过程中，不停地寻找产品的问题和不足，并持续打磨，以确保在产品交付客户之前，在产品体验上就已经达到了一个很好的水平。

比如我们在开发在线合唱的场景时，就经常有人找我问：“rex，我跟你确认一下哈，咱们团队里的同学，究竟都是写代码的程序员，还是想要通过《我是歌手》来改变人生的麦霸？”

方法二：通过数据体系来评估产品质量

构建一套靠谱的数据体系很重要，这就是把“文无*”的事情变成“武无第二”。通过数据体系，让所有的指标都变成可以比较的数字，并且依托数据分析系统，不断地提升产品质量。

虽然这个思路大家都很清楚，也都在各自的产品中有所落地，毕竟咱们腾讯的产品团队，谁家还没有一个负责数据运营的同事呢？当然有些比较大的业务，都是有自己的数据运营团队的。

但还是得说，这个事情在 toB 的方向上不好做，难在两点：

• 不同的客户关注的点是不一样：比如教育客户关注的是稳定性，电商直播关注的是清晰度，秀场直播关注的则是音质。如果我们给一个在线教育客户去过度地优化画质，客户不仅可能不买账，还可能因为我们的优化影响了其他指标而弃用我们的产品。
• 音视频的表现不是简单地靠 DAU、成功率来衡量的。比如“切课率”这个指标，影响因素非常多，比如网络波动呀，硬件发热呀，麦克风阻抗大呀，显卡驱动不匹配呀，还有可能是用户心情不好砸键盘呀。就说我们有个客户，发现上课的声音效果不好，结果客户很负责，亲自到了学生家去确认，*后发现是 iPad 的保护套把麦克风给遮住了，你说这找谁说理去？

数据体系建设

面对上述挑战，我们还是得从技术角度去解决问题，毕竟靠堆人是不行的，这生意得做出毛利率才能长久地坚持下去。

庆幸的是这方面我们还是做得不错的，尤其是我们团队一向比较在意数据，团队里还有一等一的聪明脑袋负责数据体系的建构。比如我们在自己的引擎内部的各个关键模块都做了数据“挂节点”。这些模块会每时每刻将近百个技术指标以一秒一次的频率反馈给统计模块，在统计模块进行汇总之后，再实时上传到服务器上。

基于这些海量的数据信息，仅仅靠 group by 和 count 、where 等 SQL 语句做简单的统计分析是肯定没用的，因为这样的分析得不出任何有价值的信息。

比如一次糟糕的通话体验，可能出现过一次 2s 的卡顿，但是这些数值如果仅仅是用来做大盘平均分析，那这次 2s 的卡顿就“淹没”在了海量的通话数据里，你拿到的*终的平均值甚至不会有小数点上的一个波动。

针对这个问题，团队中的 xuanyi 和 yuting 两位同事，基于对以往 badcase 的经验综合分析，构建了一套“根因分析系统”，并用了将近半年的时间，不断地打磨其准确性。到目前为止，这套系统对于 badcase 的分析已经接近人工挨个 case 分析的准确性，为团队节省了不知道多少人力。

排障体系

回到*初的小故事，客户之所以怀疑我们的产品不是一款商用级的产品，*大的问题就在排障体系上。因为客户也不是*终用户，客户在面对自己用户的反馈和投诉时，往往也是很难拿到*手信息的。如果我们将排障过程演化成了：我们 <=> 客户<=>客户的用户，之间的复杂关系，这个事情就很容易引发矛盾和冲突。

所以我们在接受了早期的失败教训之后，就励精图治建设了一套商业级的排障系统。经过这几年的努力，这套系统已经越来越强大了，也承载了越来越多的能力。目前已经能够做到分析过去两周内任何一个用户的任何一次体验问题，并能够定位到技术层面的缺陷或者环境方面的问题。

于此同时，在线日志和离线日志系统的双重保障，也让排障的信息变得更加容易获取。以往比较困难的线上死锁问题和调用时序问题，也开始不再那么可怕和束手无措。

当然，面对这么多的客户，靠一个团队的人力是不可能搞定数千个客户的技术支持和售后服务的，靠两个也不行。不过作为一款腾讯云上的老产品，我们的 TRTC 和 IM 很早就接入了腾讯云的安灯系统。借助安灯的问题跟踪和信息流转能力，中小客户的问题也得到及时的处理和沉淀。

总结

从 2016 年加入腾讯云，团队到今天已经走过了五年，我们用了五年时间去学习如何做一款商用级的 SDK。虽然现在来说，我们做得还不够好，但至少可以回答几年前客户的质问，我们现在还是有信心并且有能力做好一款商用级的 SDK 产品的，而且不止一个。

 

一、iOS

1.1、上架时需要在App Store提交的信息

因为涉及到多个部门，所以我制作了一个表格。注意：负责部门可以修改为负责人，因为我这边默认对应的就是这个部门的负责人。

注意1:App 预览和屏幕快照的图片顶栏的状态栏需要是iOS的，不要做成Android的啦。并且图片不能包含Alpha通道。

1.2、上架时需要处理的APP问题

注意2:App Store申请审核被拒的情况清单（知己知彼，防止你审核不通过）：

截图中出现了Android。 截图中出现了hack苹果的内容。 评论中出现了“屌丝”等不雅词汇。 App中包含谈论Android系统的内容。 只有第三方登录，没有自己的注册登陆功能。 您的应用包括色情内容（色情交易，色情展示）。 有微信分享功能，结果因为要强制用户安装微信，才能使用该功能。 QQ登陆功能，但是没下载QQ就不行。 有第三方支付（支付宝）果断被拒。 您的内容因为没有举报功能、含有色情内容不能通过。 有登陆注册功能，但没有提供测试账户。 存放文档的地方由于iCloud会自动备份而被拒*，只有用户自己使用和创建出来的才允许放在Document文件夹下。 游戏运行崩溃。 游戏截图中有“测试字样”。 游戏中使用其他版权图片（使用了flappybird原图）。 关键字不符合要求。 审核人员打开app无法加载内容，一般是因为国内服务器的问题。 iPad写成了IPad。 iOS写成了IOS。 因为iCloud云备份的问题被拒*，将备份功能关闭通过。 使用第三方SDK，有个提示信息遮挡了状态栏。 有竖中指的图片。 因为应用截图被拒。美术偷懒给了4张android的截图，虽然app内容是一样的，但是顶部的状态栏是Android的。 App中有积分墙。

注意3:手机icon展示“一面” 已经和评估客服确定过，App Store上显示名字和下载到手机上显示的名称可以不一致。

二、Android

2.1、上架时需要提交的信息

注意5: 可以选在3个，可自定义一个关键词。设置搜索关键词会提高应用被搜索到的机率。 如提交的关键词不合理，审核时可能会被驳回或删除。 注意6: 公司开发者上传公司营业执照、软件著作权，大小2M以内，支持JPG/PNG格式的图片。

2.2、上架时需要处理的APP问题

三、注意事项汇总

1、Android上架时需要《软件著作权》，这个需要提前去申请，并且名称需要和以后的APP名称一致。

软件著作权

2、相关资料

相关资料

3、App Store上显示名字和下载到手机上显示的名称可以不一致。

4、App 预览和屏幕快照的图片顶栏的状态栏需要是iOS的，不要做成Android的啦。

5、如果出现需要提供《互联网新闻信息服务许可证》的话，直接上传《ICP经营许可证》，是一样的东西

刚刚，在由中国信息通信院主办的「OSCAR开源产业大会」上，腾讯TAPD联合中国信息通信院及腾讯研究院，共同发布《2021年企业敏捷协作数据报告》。

在市场环境快速变化的背景下，企业的敏捷协作呈现出怎样的特点？未来敏捷协作又将迎来什么样的发展趋势？让我们先睹为快！