人机界面指南三技术中
⇨⇦
文章索引
3.9 通知(Notifications)
3.10 社交媒体(Social Media)
3.11 iCloud
3.12 HealthKit
3.13 应用内购买服务(In-App Purchase)
3.14 游戏中心(Game Center)
3.15 iAd富媒体广告(iAd Rich Media Ads)
3.16 无线打印 (AirPrint)
3.17 访问用户数据(Accessing User Data)
3.18 快速查看(Quick Look)
译者注：本文译自苹果官方人机界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由腾讯ISUX设计师翻译整理，非发文者一人之作。译文首发于ISUX博客，如在阅读过程中发现错误与疏漏之处，欢迎不吝指出。后续章节会陆续更新，敬请期待。
3.9 通知(Notifications)
通知为人们提供即时的重要信息和功能。人们能在多种情况下收到通知，例如在锁屏界面中，或者在使用应用时，或者访问通知中心时。 通知中心有两种视图：通知(Notifications )和今天(Today)。
今天视图显示了一组可编辑的部件。今天部件是一个应用扩展，显示了少量及时和重要的信息或功能，这些信息或功能则是由用户所关注的应用所提供。举例来说，日历部件只显示了今天的事件。点击日历部件中的一个事件可以唤起日历应用，并打开该事件，用户接下来可以编辑该事件或管理其他的事件。想要了解更多关于设计今天部件的内容，请参见今天部件。
通知视图会显示用户感兴趣的应用所发出的最近通知。用户可以在设置(Settings)中来设置是否在通知中心显示该应用的通知。 iOS应用可以使用通知来让人们知道一些有趣的事情是什么时候发生的，例如：
收到一条消息
事件即将发生
有新的数据可下载了
某些状态发生了变化
在iOS8及之后的版本中，应用可以定义用户在通知中的操作。例如，用户可以在待办事项应用的通知中就标记该事项已完成，而无需额外打开应用。 iOS定义了两种类型的通知。
本地通知(local notification)由应用安排待发送，最终通过iOS发送到同一设备中，无论该应用当前是否正在后台运行。例如，日历或待办事项应用可以安排一条本地通知来提醒人们一个即将到来的会议或者日期。
远程通知(remote notification)(也称为推送通知(push notification))是由应用的远程服务器通过苹果推送通知服务来发送的，这类通知最终会被推送到所有安装了该应用的设备。例如，一款在线竞技类的游戏，用户可以和其他玩家竞赛的，可以更新所有玩家的最新状态。
注意：应用扩展可能会要求远程通知必须发送到它的容器应用。在这种场景下，容器应用常常会在后台运行来处理通知。想要了解更多关于应用扩展的内容，请参见应用扩展。
如果当你的应用正在后台运行时收到了本地或远程的通知，你就应该以你的应用所特有的方式将信息传达给你的用户。 为了确保用户能够自定义他们的通知体验，你应该尽可能多地支持以下的通知类型：
横幅(Banner)
警告框(Alert)
小气泡(Badge)
声音(Sound)
注意：在iOS8及之后的版本中，你必须对所有你想发送给用户的通知类型进行注册。当你第一次进行注册动作时，用户会遇到一个警告框，他们可以在其中操作来决定允许或拒绝所有来自你的应用的通知。不管用户选择的结果是什么，他们应始终能访问应用的设置来更改此项设置，或者设置他们想要接收的通知类型。
横幅(banner)是一个小而透明的视图，会出现在屏幕顶部并在几秒后消失。用户还可以看到在锁屏当中的横幅以及在通知中心中以通知形式出现的横幅。在横幅中，iOS会显示通知的内容和应用的小图标(欲了解更多关于小图标的内容，请参见 App Icon)。用户点击横幅来隐藏显示并切换到发送通知的应用。
除了默认的点击动作之外，当用户轻扫横幅时,你还可以定义两个动作按钮。点击通知动作按钮来隐藏横幅的显示并启动你的应用(可能是在后台)来执行动作。
通知警告框是显示在屏幕上的标准警告框视图，需要用户操作后才会隐藏。当用户点击Options按钮后，你需要提供并显示通知消息以及任何一个默认动作，或最多四个特定动作。警告框的背景样式不能做修改。 当用户点击警告框中的一个默认或自定义动作按钮时，iOS会同时隐藏警告框并运行你的应用(可能是在后台)。点击关闭或确定按钮会隐藏警告框而不打开应用。
小气泡(badge)是一个显示未读通知数量的红色小圆(小气泡显示在应用图标的右上角)。小气泡的大小和颜色不能做修改。 横幅、警告框和小气泡这三种通知都可以使用自定义或系统提供的声音。
在通知中谨慎使用具破坏性的动作。要确定用户有足够的上下文来避免意想不到的后果。为了帮助用户区分你所定义的破坏性动作，iOS会用红色来显示它。有时候，在应用执行破坏性动作之前，应该请求用户进行确认。举个例子，如果在锁屏的横幅(banner)中提供了一个破坏性动作，那么就应确保只有设备的主人才能执行该动作(你需要在代码上实现这一需求)。
为每个动作按钮提供自定义标题。创建一个简短的标题来描述清楚将要发生的动作。例如，游戏可能会使用＂Play＂作为标题来表明，点击这个按钮会打开应用来进行游戏。确保标题：
使用标题样式的大小写(title-style capitalization)
足够简短，能不被截断地显示在按钮内(也应确保测试各种语言文字的标题显示正常)
不要为同一个事件重复发送通知。用户可以选择处理通知项；通知项在用户未处理前会一直显示。如果为同一事件重复发送通知，通知中心列表中会满是通知，用户就有可能会关闭你的应用的通知。
不要在通知消息中包含你的应用名称。自定义信息会在警告框和横幅中显示，也会在通知中心中以通知的形式显示。你无需在自定义信息中显示你的应用名称，因为iOS会在显示信息的同时自动显示应用名称。 为了使本地或远程通知信息更有作用，你应该：
专注于信息而不是用户的行为。避免告诉人们点击哪个按钮或如何打开你的应用
足够简短，一两行就可以显示完整。较长的信息对于用户来说很难进行快速阅读，也会造成在警告框中需要滚动才能查看完整
使用句式大小写(sentence-style capitalization)，并配以合适的结束语句符号。可能的时候，可以使用一个整句
注意：如有必要，iOS会缩短你的消息以便能在各种通知发送样式下显示；为了最好的效果，你不应主动缩减你的消息。
保持小气泡的内容是最新的。当用户注意到新信息时，即时更新小气泡非常重要，这样用户就不会觉得收到了额外的通知。注意，当小气泡为0时也会移除通知中心中所有对应的通知项。
重要：不要使用小气泡做通知以外的用途。记住，用户能够关闭应用的小气泡，所以你无法确定他们一定能看到小气泡中的内容。
当收到通知时，提供用户可以选择听到的音效。当人们没有在看屏幕的时候，可以通过音效获取他们的注意。例如，日历应用可能会在显示警告框的同时播放一个音效来提醒人们一个即将到来的事件。再如，协作任务管理应用可能会在小气泡更新时播放一个音效来告知某个远程协同的同事已经完成了某个任务。
你可以提供自定义的音效，或者使用内置的警告音。如果你创建了自定义音效，请确保它是简短的、有特色的并且是经由专业制作的。(想要了解更多关于音效的技术需求，请参阅Local and Remote Notification Programming Guide中的Preparing Custom Alert Sounds。)注意，当通知发送后，你无法以编程方式来触发设备的震动，因为用户对于警告框是否伴随震动拥有支配权。
3.10 社交媒体(Social Media)
人们会期望在任何场景下都可以使用他们喜爱的社交媒体帐号。iOS以人们喜欢的方式将社交媒体的交互与你的应用进行了整合。
注意：当用户点击动作按钮时，他们会得到一个如上图的动作视图控制器。想要了解更多关于这个视图控制器的内容，请参见Activity View Controller。
动作视图控制器的中间一行显示了用户启用的和系统提供的分享应用扩展。想要了解更多关于设计分享扩展的内容，请参见 Share and Action Extensions。
考虑在你的应用中为用户提供一种简便的方式来撰写邮件。用户有可能会启用分享扩展以便能在任何地方都可以发送内容。但是你也可以使用系统提供的撰写视图控制器来呈现给用户，他们可以在其中进行编辑操作。你可以在显示给用户进行编辑之前，预先加载具有自定义内容的撰写视图(在你呈现给用户之后，只有用户可以编辑这些自定义内容)。想要了解更多关于社交框架(Social framework)的编程界面，包括SLComposeViewController类，请参见 Social Framework Reference.
如果可能，避免要求用户登录进入一个社交媒体账户。社交框架(Social framework)会和帐号框架(Accounts framework)一起来支持一个单点登录模式，所以你可以获得授权来访问用户的帐号，而无需要求他们来重新授权。如果用户还没有登录进入一个帐号，你可以显示UI来让他们进行登录。
3.11 iCloud
iCloud可以让用户随时随地用不同的设备访问他们想要的内容。将iCloud集成到应用中，用户不用进行同步操作就可以在不同场景下使用不同的设备访问并编辑私人信息。
为了提供这种体验，你可能需要重新检查你的应用中现有的信息，尤其是用户自建内容的存储、访问和展示方式。想要了解如何使用iCloud，请参考iCloud Design Guide.
iCloud用户体验的一个基本方向是透明性：理想情况下，用户不需要知道他们的信息存储在什么地方，也不需要去思考当前浏览的信息是哪个版本的。以下几点可以帮助你创建用户期望的iCloud体验。
如果可能，让用户方便地在你的应用中启用iCloud。在iOS设备上，用户可以在设置中登录iCloud账户，因此多半用户会期望应用可以自动启用iCloud。但是如果你觉得用户可能需要自主选择是否使用你应用的云服务，你可以在用户第一次进入应用时提供一个简单的选项来进行设置。大多数情况下，这个选项应该为：是否将所有内容上传到云端。
尊重用户的iCloud空间。一定要记住iCloud空间是用户花钱买来的有限资源。你应该使用iCloud来存储用户自己创建和可理解的信息，避免将可再生的应用资源和内容存储在云端。同样要记住，当用户登录了iCloud账户时，你的应用的文件夹内容也会自动备份到云端。所以为了节省用户云端空间，你最好只挑选必要的信息存储于文件夹中。
避免让用户自己选择在iCloud上存储哪些文件。一般地，用户会期望他们在意的所有信息都能够通过iCloud访问到。实际上大多数用户都不需要进行个人文件存储的管理，所以你的应用也可以不用考虑这个问题。为了提供更好的用户体验，你可能想要重新构建处理和展示内容的方式，这样就可以给用户提供更多的文件管理功能。
决定哪种类型的信息需要存储在云端。除了存储用户自建的文件和内容，你还可以存储少量的其他信息在云端，例如用户当前的状态，用户的偏好设置等等。你可以使用iCloud的关键值存储来保存这类信息。例如，用户使用你的应用看了一个杂志，你可以使用iCloud的关键值存储来保存用户浏览到的位置，这样用户在别的设备上重新打开这个杂志时就能从上次离开的地方继续浏览了。
如果你使用iCloud的关键值存储来保存用户的偏好设置，确保用户在每个设备上都是想这样设置的。例如，有些偏好设置在工作环境中比在家里要更好用。在某些情况下，将偏好设置保存在应用服务器上要比保存在云端更合理，这样偏好设置就不会受iCloud的限制。
确保iCloud无法使用时应用的行为是合理的。例如，用户退出iCloud账户，关闭应用的iCloud或者进入飞行模式时，iCloud都是无法使用的。在这些情况下，用户都进行了某些操作来禁止iCloud服务，所以你的应用可以不用再进行提醒。但是，需要告诉用户在打开iCloud之前，当前做的修改在其他设备上都无法看到。
避免给用户创建＂本地＂文件的选项。不管你的应用是否支持iCloud，都不应该给用户提供因设备而区分的文件系统。相反，你应该希望用户关注通过iCloud访问文件的普适性。
在合适的时候自动更新信息。最好不需要用户来确认他们正在访问的是最新的内容。但是，也需要在用户设备存储空间和带宽限制之间做出平衡。如果你的用户要使用非常大的文件，那么让他们自己选择是否要从云端下载一个更新的文件可能更合适。如果需要这样做的话，可以设计一种方式来指出当前在云端有一个该文件的最新版本。当用户选择更新时，如果下载时间较长最好给用户明显的反馈。
告知用户删除某文件的后果。当用户从有iCloud服务的应用上删除文件的时候，这个文件同样会从用户的iCloud账号和其他设备上删除。所以最好在执行删除操作之前告知用户删除的后果，让用户进行确认。
必要时尽可能早地告知用户冲突问题。使用iCloud编程接口，你需要在不打扰到用户的情况下解决大多数不同版本之间的冲突问题。但在有些情况下，你需要尽可能早地检测出冲突问题来避免用户在错误版本上浪费太多时间。你需要设计一种自然的方式来告诉用户有冲突存在，接着给用户提供方便的方式来区分不同版本以及做出决策。
确保在搜索中包括用户在云端的信息。使用iCloud的用户趋向于认为云端的信息是普遍可访问的，所以他们会期望搜索结果中也有云端的信息。如果你的应用允许用户搜索他们的信息，确保你使用了将搜索扩展到iCloud账户的接口。
3.12 HealthKit
在iOS 8及之后的版本中，使用HealthKit构建的应用可以利用从健康应用中获取的数据为用户提供更强大、更完整的健康及健身服务。在用户允许的情况下，应用可以通过HealthKit来读写健康应用(用户健康相关数据的存储中心)中的数据。
举例来说，用户可以允许营养应用从健康应用中获取体重及活动数据，用于告诉他们为了达到既定目标一天应该消耗多少卡路里。这个营养应用还可以通过HealthKit更新健康应用上实际消耗的卡路里数据，让用户能更容易地跟踪他们的健康计划的进展。想要了解如何将HealthKit整合进你的应用中，请参阅HealthKit Framework Reference.
下面的指南能够帮助你设计出让人信任且喜爱的健康类应用：
当且仅当你有令人信服的理由时才去访问健康应用中的数据。HealthKit是为了专注于健康及健身服务的应用而设计的。如果一个应用请求获取与其不相关的健康信息，用户不太可能会放心地将个人数据提供给这个应用。因此，你需要确保用户能够理解你的应用需要获取他们某些具体的个人健康数据的原因，并告诉他们共享这些数据的好处。
避免在用户还不知道用途前就向他们请求访问私人健康数据。当用户能够看到当前的任务和你需要访问的数据的关联性时，会更乐意给予你访问权限。举例来说，当用户在给一个减肥应用填写资料时，让他允许你访问健康应用中储存的体重数据是合理的。但如果那个减肥应用在启动时就立即提出访问体重数据的请求，用户更可能会选择拒绝分享该个人数据。
使用系统提供的用户界面来请求访问用户的数据。当用户想要向应用授予访问他们的数据的权限时，一般会期望看到如下图所示的系统权限许可列表。为了确保给用户提供良好的用户体验，应避免在应用的其他页面中重复使用权限许可列表上的信息。而是应该在权限列表中添加些自定义信息来说明为什么你的应用需要访问特定的数据(参阅HKHealthStore Class Feference可获取更多信息)的原因。确保这些信息简洁且能清晰地说明你的应用是如何利用健康应用中的数据，以及收集这些数据的好处。
注意：当用户决定停止与你的应用共享数据时，让他们可以在系统设置中即可完成变更，而不需要通过你的应用界面。
不要在你的应用界面中使用健康应用的图标、图片或者截图。和苹果所有的系统设计一样，这些图像都是受到版权保护的，不应该在你的应用中出现。
不要在你的应用中使用＂HealthKit＂这个专用术语。HealthKit是代表能够获取健康应用中储存的数据的技术框架的专用技术术语。如果你需要向用户解释你的应用和健康应用中的数据的联系，请使用＂健康应用＂这个用语。例如，你可以说你的应用＂将保存信息至健康应用中＂或＂所使用的数据是从健康应用中获取的＂。
3.13 应用内购买服务(In-App Purchase)
应用内购买服务使得用户可以在你的应用中、你所设计的商店中购买到数字产品。
例如，用户可以做这些事：
将一个应用从基础版本升级到高级版本。
每月订阅新内容。
购买虚拟商品，比如游戏中的等级或道具。
购买并下载新的书籍。
你可以使用StoreKit框架以嵌入的方式将商店添加到你的应用中，并且用来支持应用内购买服务。当用户进行购买时，StoreKit会连接到应用商店进行安全支付，然后再告知你的应用以便它可以提供用户已购买的商品。
重要:应用内购买服务只提供支付功能，其他功能由你自己提供，例如向用户展示商品，解锁内置功能，从你自己的服务器上下载内容等等。当然，你所提供的所有商品都必须在应用商店注册过。
想要了解关于在应用中添加商店的技术要求，请查看In-App Purchase Programming Guide.想要了解更多关于应用内购买的商业需求信息，请查看App Store Resource Center.当然，你还应该查看相关许可协议来确定你的应用可以出售哪些商品以及如何提供商品。
遵循以下几点规范，可以帮助你设计出用户喜欢的购买体验。
将商店的使用体验优雅地集成到你的应用中。在展示商品和处理交易时，给用户提供一种熟悉、一致的体验。你一定不希望用户在访问你的商店时感觉像是进入别的应用。
使用简单明了的标题和说明。最好能让用户在扫过一组项目时，可以快速发现感兴趣的内容。文案上不要截断隐晦，简单直白的语言和标题更容易让用户理解你所要展示的商品。
不要更改默认的确认对话框。当用户购买一个商品时，StoreKit会提供一个确认对话框(如上图所示)。这个确认对话框可以帮助用户避免买错东西，所以不要修改它。
3.14 游戏中心(Game Center)
游戏中心给用户提供玩游戏、组织多人在线游戏以及其他更多功能。玩家可以使用内置的游戏中心应用来注册账户、发现新游戏、添加好友、浏览玩家排名和战绩。
作为一名游戏开发人员，你可以使用GameKit应用接口来发布分数和战绩到游戏中心的服务器上，在你的游戏页面中显示玩家排名，帮助用户找到其他玩家。想要了解如何将游戏中心集成到你的应用中，请查看Game Center Programming Guide.
遵循以下几点规范，有助于你的应用给用户提供好的游戏中心体验。
不要使用自定义的用户界面来提示用户登录到游戏中心。如果用户在未登录到游戏中心的情况下打开了一个需要启用游戏中心的应用，系统会自动提醒他们去登录。所以没必要自定义一个登录界面，而且有可能还会让用户感到困惑。
一般情况下，使用标准的游戏中心界面。在少数情况下，可能自定义游戏中心的界面是合理的，但是这样做会有让用户感到困惑的风险。标准的游戏中心界面对于iOS和OS X的用户是熟悉的，而且它会给用户一种置身于一个庞大游戏社区的感觉。
允许用户关闭语音聊天。有些用户可能不想在进入游戏时就自动开启语音聊天，而且大多数用户希望在特定情境下可以关闭语音聊天。
3.15 iAd富媒体广告(iAd Rich Media Ads)
如果你允许你的应用中出现广告，那么你可以通过用户浏览或者点击这些广告获得收益。(如图所示，这个底部预留位置就是用来放置iAd横幅广告。)
通过iAd网络你可以在你的用户界面中以特定的视图投放一则广告。最初，这种视图可以用来承载目标横幅广告，起到引导用户进入查看全面广告详情的作用。当用户点击该横幅广告时，广告就会执行预先设定的动作，例如播放一段影片、展示可交互的内容，或者启动Safari打开目标网页。该动作所展示的内容可以遮挡住你当前的用户界面，或者使你的应用转换到后台运行。
有三种类型的横幅广告供你在应用中使用：标准(standard)、中等矩形(medium rectangle) 和全屏(full screen)。所有类型的横幅虽然在外观和行为上存在差异，但都提供同样的功能，就是引导用户进入广告。
标准横幅(standard banner)占用屏幕较少的空间，通常从始至终都可见。你可以选择在应用的哪些页面展示标准横幅，并在给这些页面设计布局时预留出空间。
所有的iOS应用都可以展示标准横幅。你可以使用ADBannerView类中的广告视图来显示标准横幅广告。
中等矩形横幅 (medium rectangle banner) 的行为同标准横幅类似，同样也可以选择展示中等矩形横幅的位置。
中等矩形横幅只能在iPad的应用中使用。你可以使用ADBannerView类中的广告视图来显示中等矩形横幅广告。
全屏横幅 (full screen banner) 会占用屏幕的大部分甚至是全屏空间，并且通常只在应用程序流的特定时间或特定位置显示。你可以选择使用模态视图来显示横幅广告，或者用独立页来展示可滚动的广告内容。(在下面的示例中，应用提供了一种杂志阅读的体验，通过翻页离开或回到全屏广告页面。)
你可以使用ADInterstitialAd类中的广告视图在你的应用中显示全屏横幅广告。
iAd框架包含了所有类型的横幅广告，并且会在右下角显示iAd的标识。iAd框架的设计固定在屏幕底部时看起来效果最佳。
为了保证广告无缝植入，并且要提供最好的用户体验，可以遵循以下几点规范。
将标准横幅广告视图尽量放置在屏幕底部或底部附近。这个位置的差别取决于屏幕底部是否包含栏(bar)以及是什么样的栏。
将中等矩形横幅广告视图放置在不会干扰内容的地方。和标准横幅一样，中等矩形横幅也最好放置在屏幕底部或底部附近。放在底部附近也能减少干扰用户的可能性。
当用户体验存在中断时请使用模态视图来展示全屏横幅广告。如果你的应用中有自然中断或情景转换，用模态样式来展示会更合适。当你使用模态样式来展示全屏横幅时(通过用presentFromViewController实现)，用户要么进入广告，要么关闭它。出于这个原因，当用户有做出转变的预期时 (比如完成了一个任务后) 用模态视图的形式来展示比较好。
应用的界面视图进行转场切换时不要使用模态样式展示全屏横幅。如果用户在使用你的应用时会频繁的进行屏幕切换操作，例如杂志翻页或翻阅一些画册图片合集，此时使用非模态的形式会更合适。当你使用非模态来显示全屏横幅时(通过使用presentInView实现)，可以在用户界面中保留栏 (bar) 使得用户可以通过应用中的控件进入或退出广告。同其他横幅广告一样，点击全屏横幅广告也会触发iAd体验，但是如果条件允许的话，你的应用也可以对横幅广告区域支持其他手势操作 (比如拖动或滑动)。
确保使用合适的动画效果来显示和隐藏非模态的全屏横幅视图。例如，杂志阅读应用可以用和杂志翻页一样的动画效果。
确保横幅广告在应用中出现的时间和位置是合理的。用户只有在不觉得广告会打扰他们正常的工作流程时才有可能去体验iAd.这点对于游戏这样的沉浸式应用尤其重要：你肯定不想将横幅放置在影响用户玩游戏的位置。
避免将横幅放置在用户只会一扫而过的页面。最好不要将横幅广告放置在用户会快速略过的页面，比如用户正要深入挖掘或前往他们所关注的内容。通常用户在一个页面停留至少1、2秒后才有可能会点击广告。
尽可能的支持双向展示横幅广告。最好让用户在使用应用时不必旋转设备就能浏览广告。当然，支持双向也能给你的广告提供更大的展示区域。想要了解如何确保转换方向时横幅广告能正常响应，请查看iAd Programming Guide.
不要让标准或中等矩形横幅广告滚出屏幕。如果你的应用需要滚动来展示更多内容，确保横幅广告一直固定在它的位置上。
当用户浏览或与广告进行交互时，暂停那些吸引用户注意力或需要操作的活动。当用户选择浏览广告时，他们不想因此错过应用中正发生的事件，也同样不想让应用打断广告体验。一个好的经验方法是像应用程序转入后台运行那样暂停当前活动。
除非有特殊情况，否则不要中断广告。一般情况下，当用户浏览并与广告进行交互时，应用还是会继续运行并接收事件，所以也有可能突然出现一个事件需要获得用户的注意力。然而，需要打断广告的场景其实非常少。有一种情景是有的应用会提供互联网语音协议服务(VoIP).在这种应用中，有电话接入时可能会取消正在运行的广告。
注意:取消广告可能会对应用能接受的广告类型以及能获取的收益有不好的影响。
3.16 无线打印 (AirPrint)
用户可以通过AirPrint无线打印应用中的内容，还可以使用打印中心应用检查打印任务。
你可以利用内置的支持程序来打印图片和PDF文件，或者可以使用特定的打印程序接口来完成自定义的格式设置和渲染设置。iOS可以处理打印机的发现、任务排序以及在指定打印机上执行打印任务。
通常来讲，用户想要打印文件的时候，只需要点击应用中的标准动作按钮(Action button)。当他们在界面视图中选择了要打印的项目后，可以接着选择打印机，设置打印属性，最后点击打印按钮开始打印。
打印中心应用是一个只有在处理打印任务时才可见的后台系统应用，用户可以用它来查看打印任务。用户可以在打印中心浏览当前打印队列，查看某个打印任务的详情，还可以取消某个任务。
只需添加少量代码就可以支持基本打印功能 (想要了解在代码中添加打印功能，请查看Drawing and Printing Guide for iOS).想要确保好的打印体验，可以遵循以下几点规范：
使用系统提供的动作按钮。用户对系统提供的按钮的含义和行为都很熟悉，所以尽可能的使用系统动作按钮。如果你的应用没有工具栏或导航栏，那就要另当别论了。在这种情况下，你就需要自己设计一个可以出现在应用主界面的打印按钮，因为动作按钮只能在工具栏和导航栏中使用。
在当前情境下打印操作是基本功能时才显示打印项(Print item).如果当前情境并不适合打印，或者用户并不想打印，就不要在由动作按钮显示的视图中将打印项显示出来。
合适的话，给用户提供更多打印选项。例如，让用户设置打印页码范围或打印份数。
如果用户不能打印，则不要显示特定的打印用户界面。在向用户展示有打印项的界面前，确保用户的设备是支持打印的。想要了解如何在代码中实现，请查看UIPrintInteractionController Class Reference.
3.17 访问用户数据(Accessing User Data)
位置服务允许应用获取用户当前大致的地理位置，设备指向的方向以及用户移动的方向。其他系统服务，例如通讯录、日历、备忘录和相册等，同样也允许应用访问用户存储在里面的数据。
虽然获取了用户数据的应用能带来一定的方便，但还是需要为用户提供维持信息私密性的功能。例如，用户喜欢应用自动给内容加上位置标签，或者可以找到附近的好友，但用户也需要能在不想分享位置的时候关闭这些功能。(想要学习如何给应用增加获取位置功能，请参阅Location and Maps Programming Guide.)
以下几点可以帮助您以用户不反感的方式获取用户数据。
确保使用户理解分享私人数据的原因。如果没有明显的需要，用户自然会对私人信息的请求感到怀疑。为了避免用户反感，确保在用户使用明显需要个人信息的功能时再进行提醒。例如，即使没有打开位置服务用户也可以使用地图，但是在用户使用定位或导航功能时就会有提醒。
应用需要个人信息的原因不明显时向用户做出解释。你可以在提醒框中给出文字性的描述，例如＂这个应用需要访问你的通讯录＂或者＂是否允许应用获取你的地理位置？＂。这些文案最好明确且有礼貌以让用户无压力的理解为什么需要访问他们的信息。
讲述原因的文案应该遵循以下原则：
不要包含你的应用名称，因为系统提供的提醒框已经包含了。
清楚地描述你的应用为什么需要这些数据。如果可以的话，你也可以解释不会用这些数据做什么。
使用以用户为中心的术语并且进行本地化。
在易于理解的情况下越短越好。尽可能避免超过一句话。
使用句式大小写(sentence-style capitalization).(句式大小写指的是第一个单词大写，除了专有名词和专有形容词以外的词都小写。)
只有当你的应用没有用户数据就无法提供基础服务时，才在一开始就征求用户的许可。如果你的应用在知道了用户私人信息后才能提供主要功能是显而易见的话，用户不会因此觉得烦扰。
避免在用户选择需要数据的功能之前调用触发提醒框的程序。这样，就可以避免用户疑惑为什么在使用不需要私人数据的功能时有请求提醒。(注意，检查用户位置服务的设置并不会触发提醒。)
检查位置服务的设置来避免触发没必要的提醒。你可以使用核心位置的程序接口来实现(想要学习如何做，请参阅Core Location Framework Reference).使用这些知识，可以尽可能地在使用需要位置信息的功能时才进行提醒，或者完全避免提醒。
3.18 快速查看(Quick Look)
通过使用Quick Look，用户可以在你的应用内预览文件，即使你的应用是打不开这个文件的。举例来说，你可以允许用户预览一些从网站上下载或从其他来源获得的文件。
想要学习如何在应用中加入Quick Look文件预览功能，请参阅Document Interaction Programming Topics for iOS.
在你的应用内预览文件之前，用户可在你定制的视图中查看该文件的信息。例如，用户从一封邮件中下载了附件之后，邮件应用(Mail)会在邮件中使用定制的视图展示文件的图标、标题和大小。用户可以通过点击它来预览文件。
你可以在应用中用一个新的视图来展示文件预览，或者使用全屏模态视图。展示的形式取决于你的应用运行在什么设备上。
在iPad上使用模态视图来显示文件预览。iPad的大屏幕适合在一个方便用户离开的沉浸式环境中展示文件预览。缩放操作(zoom transition)很适合展示预览。
在iPhone上使用专用的视图，最好是导航视图来显示文件预览。这样可以使用户在应用情境中通过导航进入文件预览，不至于迷失。虽然也可以在iPhone应用中使用模态显示，但不推荐这样做。(注意缩放操作在iPhone上并不适用。)
另外要注意的是，在导航视图中显示文件预览意味着允许Quick Look在导航栏上放置特定的预览控件。(如果你的视图中包含工具栏，Quick Look会将预览控件放在工具栏上。)
相关阅读：
iOS 9人机界面指南（一）：UI设计基础
iOS 9人机界面指南(二)：设计策略
iOS 9人机界面指南(三)：iOS 技术 (上)
iOS 9人机界面指南(三)：iOS 技术 (下)