2. Performance

• 2.1 App Completeness
• 2.2 Beta Testing
• 2.3 Accurate Metadata
• 2.4 Hardware Compatibility
• 2.5 Software Requirements

------------------------

2。性能

2.1应用程序的完整性

2.2测试

2.3准确的元数据

2.4硬件兼容性

2.5软件要求

--------------------------

2. Performance

• 2.1 App Completeness

  Submissions to App Review should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login. If you offer in-app purchases in your app, make sure they are complete, up-to-date, and visible to the reviewer, or that you explain why not in your review notes. Please don’t treat App Review as a software testing service. We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.

• 2.2 Beta Testing

  Demos, betas, and trial versions of your app don’t belong on the App Store – use TestFlight instead. Any app submitted for beta distribution via TestFlight should be intended for public distribution and should comply with the App Review Guidelines. Note, however, that apps using TestFlight cannot be distributed to testers in exchange for compensation of any kind, including as a reward for crowd-sourced funding. Significant updates to your beta build should be submitted to TestFlight App Review before being distributed to your testers. To learn more, visit the TestFlight Beta Testing.

• 2.3 Accurate Metadata

  Customers should know what they’re getting when they download or buy your app, so make sure your app description, screenshots, and previews accurately reflect the app’s core experience and remember to keep them up-to-date with new versions.

  • 2.3.1 Don’t include any hidden or undocumented features in your app; your app’s functionality should be clear to end-users and App Review. Egregious or repeated behavior is grounds for removal from the Developer Program. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to follow suit; if you’re dishonest, we don’t want to do business with you.
  • 2.3.2 If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases.
  • 2.3.3 Screenshots should show the app in use, and not merely the title art, log-in page, or splash screen.
  • 2.3.4 Previews are a great way for customers to see what your app looks like and what it does. To ensure people understand what they’ll be getting with your app, previews may only use video screen captures of the app itself. Stickers and iMessage extensions may show the user experience in the Messages app. You can add narration and video or textual overlays to help explain anything that isn’t clear from the video alone.
  • 2.3.5 Select the most appropriate category for your app, and check out the App Store Category Definitions if you need help. If you’re way off base, we may change the category for you.
  • 2.3.6 Answer the age rating questions in iTunes Connect honestly so that your app aligns properly with parental controls. If your app is mis-rated, customers might be surprised by what they get, or it could trigger an inquiry from government regulators.
  • 2.3.7 Choose a unique app name, assign keywords that accurately describe your app, and don’t try to pack any of your metadata with trademarked terms, popular app names, or other irrelevant phrases just to game the system. App names must be limited to 50 characters and should not include terms or descriptions that are not the name of the app. Apple may modify inappropriate keywords at any time.
  • 2.3.8 Metadata should be appropriate for all audiences, so make sure your icons, screenshots, and previews adhere to a 4+ age rating even if your app is rated higher. For example, if your app is a game that includes violence, select images that don’t depict a gruesome death or a gun pointed at a specific character. Remember to ensure your metadata, including app name and icons (small, large, Apple Watch app, etc.), are similar to avoid creating confusion.
  • 2.3.9 You are responsible for securing the rights to use all materials in your app icons, screenshots, and previews, and you should display fictional account information instead of data from a real person.
  • 2.3.10 Make sure your app is focused on the iOS, Mac, Apple TV or Apple Watch experience, and don’t include names, icons, or imagery of other mobile platforms in your app or metadata, unless there is specific, approved interactive functionality.
• 2.4 Hardware Compatibility
  • 2.4.1 To ensure people get the most out of your app, iPhone apps should run on iPad whenever possible. We encourage you to consider building universal apps so customers can use them on all of their devices. Learn more about Universal apps.
  • 2.4.2 Design your app to use power efficiently. Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources.
  • 2.4.3 People should be able to use your Apple TV app without the need for hardware inputs beyond the Siri remote or third party game controllers, but feel free to provide enhanced functionality when other peripherals are connected. If you require a game controller, make sure you clearly explain that in your metadata so customers know they need additional equipment to play.
  • 2.4.4 Apps should never suggest or require a restart of the device.
  • 2.4.5 Apps distributed via the Mac App Store have some additional requirements to keep in mind:
    • (i) They must be appropriately sandboxed, and follow macOS File System Documentation. They should also only use the appropriate macOS APIs for modifying user data stored by other Apps (e.g. bookmarks, Address Book, or Calendar entries).
    • (ii) They must be packaged and submitted using technologies provided in Xcode; no third party installers allowed. They must also be self-contained, single application installation bundles and cannot install code or resources in shared locations.
    • (iii) They may not auto-launch or have other code run automatically at startup or login without consent nor spawn proceses that continue to run without consent after a user has quit the app. They should not automatically add their icons to the Dock or leave short cuts on the user desktop.
    • (iv) They may not download or install standalone apps, kexts, additional code, or resources to add functionality or significantly change the app from what we see during the review process.
    • (v) They may not request escalation to root privileges or use setuid attributes.
    • (vi) They may not present a license screen at launch, require license keys, or implement their own copy protection.
    • (vii) They must use the Mac App Store to distribute updates; other update mechanisms are not allowed.
    • (viii) Apps should run on the currently shipping OS and may not use deprecated or optionally installed technologies (e.g. Java, Rosetta)
    • (ix) Apps must contain all language and localization support in a single app bundle.
• 2.5 Software Requirements
  • 2.5.1 Apps may only use public APIs. Learn more about public APIs.
  • 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, macOS, or tvOS apps.
  • 2.5.3 Apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the operating system and/or hardware features, including Push Notifications and Game Center, will be rejected. Egregious violations and repeat behavior will result in removal from the Developer Program.
  • 2.5.4 Multitasking apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc. If your app uses location background mode, include a reminder that doing so may dramatically decrease battery life.
  • 2.5.5 We will be reviewing on an IPv6 network, so if your app isn’t compatible with the IPv6 addressing, it may fail during review.
  • 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
  • 2.5.7 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps HTTP Live stream.
  • 2.5.8 Apps that create alternate desktop/home screen environments or simulate multi-app widget experiences will be rejected.
  • 2.5.9 Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user interface elements or behaviors will be rejected.
  • 2.5.10 Apps should not be submitted with empty ad banners or test advertisements.
  • 2.5.11 SiriKit
    • (i) Apps integrating SiriKit should only sign up for intents they can handle without the support of an additional app and that users would expect from the stated functionality. For example, if your app is a meal planning app, you should not incorporate an intent to start a workout, even if the app shares integration with a fitness app.
    • (ii) Ensure that the vocabulary and phrases in your plist pertains to your app and the SiriKit functionality of the intents the app has registered for.
    • (iii) Resolve the Siri request in the most direct way possible and do not insert ads or other marketing between the request and its fulfillment. Only present interstitial UI when required to complete the task (e.g. asking the user to specify a particular type of workout).

---------

2。性能

2.1应用程序的完整性

提交审查程序应与所有必要的元数据版本最终和全功能的网址收录；占位符文本，空的网站，和其他临时内容应擦洗之前提交。确保您的应用程序已测试设备的bug和稳定性，然后提交，并包括演示帐户信息（并打开您的后端服务！）如果您的应用程序包括登录。如果你在应用程序中提供应用程序的购买，确保他们是完整的，最新的，可见的审稿人，或者你解释为什么不在你的审查笔记。请不要把程序审查当作软件测试服务。我们将拒绝不完整的应用程序包和二进制文件崩溃或表现出明显的技术问题。

2.2测试

演示版，试用版本的应用程序不属于App Store–使用TestFlight相反。提交β分布通过TestFlight App应该用于公共分配和应遵守的程序审查指南。注意，然而，使用TestFlight不能应用分布到任何形式的补偿交换测试，包括来自公众的资金奖励。你的测试版本重大更新前应发给你的测试人员提交TestFlight应用程序审查。要了解更多信息，访问的试飞测试

2.3准确的元数据

客户应该知道他们要当他们下载或购买你的应用，所以一定要确保你的应用程序的描述，以及预览截图，准确地反映软件的核心经验和记住他们最新的新版本。

2.3.1不包含任何隐藏或无证功能在您的应用程序；应用程序的功能应明确最终用户和应用程序审查。过分的或重复的行为是从开发商拆除方案的理由。我们努力使App Store成为一个值得信赖的生态系统，并期望我们的应用程序开发人员效仿，如果你不诚实，我们不想做生意与你。

2.3.2如果你的应用包括应用内购买，确保你的应用程序的描述，以及预览截图，清楚地表明，任何特色项目，水平，是否需要额外购买订阅，等。

2.3.3截图应该显示在使用的应用程序，而不仅仅是标题艺术，登录网页，或闪屏。

2.3.4预览是一个伟大的方式为客户看到你的应用程序看起来和它做什么。为了确保人们了解他们会得到与你的应用程序，可以使用视频预览屏幕捕捉程序本身。贴纸和iMessage的扩展可能会显示在邮件应用程序的用户体验。您可以添加视频或文字叙述和叠加，有助于解释什么不清楚单从视频。

2.3.5选择适合您的应用程序最合适的类别，并检查了App Store的分类定义如果你需要帮助。如果您是基地，我们可以改变类别为您。

2.3.6回答年龄评级问题在iTunes Connect真的使你的应用程序的正确对齐与家长控制。如果您的应用程序是错误的评级，客户可能会惊讶于他们得到的，或者它可能引发政府监管机构的调查。

2.3.7选择一个独特的应用程序名称，分配，准确地描述你的应用程序的关键字，不要把你的任何元数据与商标而言，流行的应用程序的名称，或其他无关的短语只是游戏系统。应用程序名称必须限于50个字符，不应包括术语或描述，不是应用程序的名称。苹果随时可能修改不恰当的关键词。

2.3.8元数据应适合所有的观众，所以确保你的图标截图预览，并坚持一个4岁以上的等级，即使你的应用程序是更高的评价。例如，如果你的应用程序是一个游戏，包括暴力，选择图像，不描绘一个可怕的死亡，或用枪指着一个特定的字符。请记住确保您的元数据，包括应用程序名称和图标（小，大，Apple Watch应用程序等），类似，以避免造成混乱。

2.3.9您有责任确保在你的应用程序图标，利用所有资料的权利的截图，和预览，你应该从一个真实的人虚构的帐户数据信息显示。

2.3.10确保你的应用是专注于iOS，Mac，苹果或苹果电视观看体验，而不包括名称、图标或图像的其他移动平台的应用程序或数据，除非有特定的交互功能，批准。

2.4硬件兼容性

2.4.1确保人们得到最出你的应用程序应该运行在iPad，iPhone的应用程序尽可能。我们鼓励您考虑建立通用应用程序，以便客户可以使用他们的所有设备。了解更多关于通用应用程序。

2.4.2设计你的应用程序使用的功率效率。应用程序不应该迅速耗尽电池，产生过量的热量，或把不必要的应变设备资源。

2.4.3人应该能够使用您的Apple TV应用程序没有硬件投入超越Siri远程或第三方游戏控制器的需要，可随时提供增强的功能，当其他外设连接。如果您需要游戏控制器，请确保您清楚地解释，在您的元数据，让客户知道他们需要额外的设备发挥。

2.4.4应用程序不应该建议或要求重新启动设备。

2.4.5程序通过Mac应用商店有一些额外的要求，要牢记：

（我）他们必须适当的沙箱，并遵循MacOS文件系统文件。他们也应该只使用适当的MacOS API修改由其他应用程序存储的用户数据（如书签、地址簿和日历条目）。

（ii）他们必须打包和使用提供技术在Xcode提交；没有第三方安装程序允许。它们还必须是自包含的单个应用程序安装包，不能在共享位置安装代码或资源。

（iii）他们可能不会自动启动或有其他代码自动运行在未经同意的启动或登录和产卵过程继续运行而不同意在用户退出应用程序。他们不应该自动添加他们的图标到码头或留在用户桌面上的捷径。

（四）不得下载或安装独立的应用程序，关闭，一些额外的代码或资源添加功能或显著改变应用程序从我们所看到的在审查过程中。

（五）不得要求升级或使用setuid root权限属性。

（vi）在发射时可能不提供许可证屏幕，需要许可密钥，或实现自己的副本保护。

（七）他们必须使用Mac应用程序商店分发更新；其他更新机制是不允许的。

（八）应用程序应该运行在目前航运系统不得使用过时的或随意安装技术（如java，罗塞塔）

（九）应用程序必须包含所有语言和定位在一个单一的应用程序包支持。

2.5软件要求

2.5.1应用程序只能使用公共API。了解更多关于公共API。

2.5.2程序应该在束是独立的，可以不读或写数据指定容器区外，不得下载、安装或执行代码，包括iOS，WatchOS，MacOS或TVOS的应用。

2.5.3应用程序发送病毒、文件、计算机代码或程序，可能会损害或破坏操作系统和/或硬件功能的正常运行，包括推送通知和游戏中心，将被拒绝。令人震惊的侵犯和重复的行为将导致开发商拆除方案。

2.5.4多任务应用程序才可以使用后台服务为他们的目的：VoIP、音频播放、地点、任务完成、地方等通知，如果你的应用程序使用位置的背景模式，包括一个提醒，这样会大大降低电池的寿命。

2.5.5我们将在IPv6网络审查，所以如果你的应用程序不兼容的IPv6地址，它可能会失败，在回顾。

2.5.6应用程序，浏览网页，必须使用适当的WebKit框架和WebKit Javascript。

2.5.7视频流媒体内容通过无线网络超过10分钟必须使用HTTP流媒体直播，包括基线192 kbps的HTTP直播流。

2.5.8应用创建备用桌面/主屏幕环境或模拟多应用程序部件的经验将被拒绝。

2.5.9程序改变制式的交换机的功能，如音量和铃声/静音开关，或其他本地用户界面元素或行为将被拒绝。

2.5.10应用程序不应该提交空的广告横幅广告或测试。

2.5.11 SiriKit

（我）应用程序集成SiriKit应该只签了意向他们可以处理没有额外的应用程序和用户的支持，希望从上述功能。例如，如果你的应用程序是一个膳食规划应用程序，你不应该纳入一个意图，开始锻炼，即使应用程序与健身应用集成股份。

（ii）确保你的plist的词汇和短语属于你的应用程序和应用程序的意图已注册为王后的功能。

（iii）解决的最直接的方式可能Siri请求不插入的要求及其实践之间的广告或其他营销。只有在需要完成任务的时候才出现间质UI（例如要求用户指定特定类型的锻炼）。