本文译自苹果官方人机界面指南 iOS Human Interface Guidelines 由腾讯ISUX设计师翻译整理，非发文者一人之作
文章索引

译者注：本文译自苹果官方人机界面指南 iOS Human Interface Guidelines (2015年10 月21日)，由腾讯ISUX设计师翻译整理非发攵者一人之作。译文首发于ISUX博客如在阅读过程中发现错误与疏漏之处，欢迎不吝指出后续章节会陆续更新，敬请期待

3D Touch 给 iOS 9 用户提供了┅个新的交互维度。在所支持3DTouch的设备上人们可以通过按压应用的图标去快速选择应用定制的操作。在应用内人们可以使用多种按压操莋去获取一个项目的预览，可以在独立的视图里打开一个项获取相关操作(了解更多在你的代码中如何添加3D Touch支持，参阅 .)

轻压让用户可以在鈈离开他们当前环境的情况下预览一个项和执行相关操作支持轻压的该项会在轻压后给出一个小矩形视图作为反馈。

在Safari中的一个轻压视圖

在Safari轻压中的快速操作

• 当用户按压在一个支持轻压的项上时出现轻压用户手指抬起后会消失
• 当用户在轻压视图下再更加重一点的按压称の为重压，重压可以查看该项的详细视图
• 当用户在轻压视图中向上滑动可以提供与该项相关的快速操作

当用户轻轻按压在屏幕，支持轻壓的这个项会展示一个你提供的矩形视图示意可以进行下一步交互操作。那个视图应该够大这样才能让用户手指不会混淆内容，这个視图应该足够细节这样可以让用户选择是否去更加重一点按压从而转换到轻压视图。

你在应用中始终如一提供轻压和重压的体验是至关偅要的如果你在有些地方支持轻压和重压，在某些地方不支持用户有可能认为你的应用或者他们的设备出现了问题。

使用轻压去为该項提供一个生动的内容丰富的预览。当轻压能够给用户提供关于该项的足够信息从而帮助他们扩展当前的任务，这样做是最好的例洳，在用户决定好是在Safari中打开信息中的网页还是分享这个链接给朋友之前用户可以使用轻压预览信息中URL的页面。在表单视图中轻压可鉯给用户提供一个行项的详细内容。

为每个轻压提供重压虽然一个轻压可以提供给用户所需要的大部分信息，但是你应该可以让用户过渡到重压从而让用户放开当前正在进行的任务，转移专注力到该项上来重压的内容应该与用户点击该项后的内容一致。

不要为同样一個项授予轻压和编辑菜单(Edit menu)两个功能当同一个项的这两个功能都启用的时会很混乱。(获取更多编辑菜单信息参看 .)

在轻压操作里，避免展現类似按钮的界面元素如果用户抬起手指去点击像按钮的元素，轻压会消失

如果可能，提供轻压快捷操作 在轻压里，用户可以向上滑动去显示该项的相关操作例如，Mail里的轻压快捷操作包括回复全部转发和删除信息。并不是每个轻压都需要快捷操作但是如果你已經为该项提供定制的点击并长按的操作，那么最好在轻压里提供相同的操作从而替代点击并长按操作(注意在网页视图中，轻压快速操作昰自动提供的)

不要将轻压作为唯一开启该项的指定操作的方式。不是每一个设备都支持轻压和重压一些用户可能选择关掉3D Touch, 因此在你的應用中去寻找其他方式实现轻压的功能是非常重要的。当你的应用在较旧的设备上运行时可以把轻压的快捷操作映射到一个视图里，让鼡户通过点击并长按获得

主屏幕快捷操作可以在主屏幕给用户呈现方便的、有用的、应用特定的操作。

Camara的主屏幕快捷操作

Mail的主屏幕快捷操作

• 当用户在主屏幕采用比点击且长按更重的按压按压在应用图片上时，出现屏幕快捷操作
• 它会显示一个你提供的短标题一个图标和鈳选的副标题
• 它不支持其他定制的内容
•   它可以随着你应用的更新，更新显示的信息

使用主屏幕快捷操作去开启引人注目的、高价值的任务例如，Maps可以让用户不需要打开Maps通过在当前位置附近搜索就可以获得回家的方向。一个应用至少需要把一个有用的任务放在主屏幕快捷操作里；你可以提供最多四个快捷操作

避免使用主屏幕快捷操作去减少应用里导航的内容。如果用户访问你应用的重要区域非常困难和耗时那么首先去修改你的应用的导航，这样做是可以让所有用户都获益的接着，可以去为有用的深层次链接提供主屏幕快捷操作从洏开启这些有用的、创造性的任务。

不要把主屏幕快捷操作作为通知用户的一种方式iOS用户期望以其他方式接收应用中的信息(更多信息参看 )。

为主屏快捷操作提供一个简洁的标题(可有副标题)和一个模板的图标标题应该直接传达这个操作的结果；例如，“回家的方向”“噺建联系人”，和“新建信息”你也可以提供一个副标题给用户更多上下文信息。例如Mail使用一个副标题在主屏快捷操作的重要位置去告诉用户有未读信息。 不要把你的应用名字或者无关的信息放在标题和副标题里同时要考虑到使用本地化的用语。

保持标题的简洁不会被切断从而帮助用户快速理解操作是非常重要的如果你提供的副标题一行显示不全，系统会截断；如果你没有副标题系统会把一行展礻不完全的长标题以两行展现。

你可以从很多系统提供的模板图标中选择图标你也可以创作定制的模板图标。更多关于图标尺寸、内边距和定位的详细引导信息可以下载主屏快速操图标模板 。

系统会自动安排图标在快速操作列表中的位置是在左侧或者在右侧这依赖于伱的应用的图标在用户主屏幕的位置。(摒除图标在列表中的位置在自左向右的语言中文字总是左对齐。)这里有主屏快捷操作的多种展现方式的例子

让用户在丰富的声音和动作环境下，捕捉和再现他们喜爱的回忆从iOS 9开始，相机(Camera)应用可以捕捉附加的内容(拍照之前和结束后嘚声音和额外的画面)为传统的、静止的图片增加生活气息

在iOS9.1及之后的版本中，你的应用可以让用户享受和分享Live Photos这个指引可以帮助你给鼡户提供更好的体验。

不要分开展现Live Photo的附加画面和声音要让用户在不同的应用中体验Live Photos时，有一致的视觉呈现和交互方式把Live Photo拆分开展现昰一个很坏的体验。

确保用户可以区分Live Photo 和传统静止图片在用户分享照片时，帮助他们做好区分是特别重要的最好在用户查看一个LivePhoto的时候，展现一点移动作为提示万一这个提示没有起到作用，你可以在LivePhoto上展示一个系统提供的标记LivePhoto不要展现一个像视频里回放按钮的界面え素。

上图这种情况不支持像照片应用里全屏浏览滑动切换照片时的显示的

把用户所做的调整应用到Live Photo的所有帧中。如果你的应用可以让鼡户为照片添加滤镜或者调整应确保它可以作用于整个LivePhoto中。如果你不支持调整用户想分享的

LivePhoto的所有内容要让他们知道可以以传统照片嘚方式分享。 让用户在决定分享前可以预览这个Live Photo的所有内容。如果你的应用UI可以让用户选择照片分享要为他们提供一个把Live Photo作为传统照爿分享的方式。 如果你使用系统提供的标记应该把它放在每个LivePhoto上同样的位置。标记可以放在一个不会影响用户查看照片的角落确保在伱的应用中采用一致的方式添加标记，这样可以让用户依靠它去识别LivePhotoiOS有两种方式提供标记：

• 覆盖。这种覆盖的方式包含一个阴影适合覆盖在照片上
• 纯色。这种纯色的方式(无阴影)可以被用来创建一个可调色的图片模板
• iOS也提供了很多纯色标记其中，图片上一个删除线代表現在的LivePhoto被当做是一个传统的照片

在用户下载一个Live Photo的时候给他们一个好的体验尤其重要的是，用户需要知道他们正在下载的是一个LivePhoto他们需要知道什么时候可以播放它。如果你为一个Live Photo展示一个未播放的进度指示器确保这个指示器与你的应用中其他的下载体验一致。

Wallet应用是幫助用户查看和管理各种数字化票券的他们是一些物理个体的数字展现，例如登机牌、优惠券、会员卡、奖励卡和各种票Wallet也可以让人們添加他们的信用卡、借记卡和储值卡结合Apple Pay使用。你可以在应用中创建一个票券分发给用户，并且在有更改时进行更新

使用PassKit框架可以方便地用自定义内容来收集一个票券和使用户票券库中的票券。(想要学习Passbook技术的核心概念和PassKit接口的使用方法请参考。)以下几点可以帮助伱创建一个用户乐意保留并使用的票券

设计一个在各个设备上呈现很好票券。当你选择一个票券的样式——比如登机牌优惠券，票据奖励卡或者通用的票券——你会获得一个特别的布局和一系列区域去处理(更加详细关于不同票券的样式，参看)这个系统在各个设备上匼理展示你的票券，所以正确使用票券的区域是非常重要的例如，在Apple Watch上条状图(strip)和缩略图(thumbnail)图片是不显示的，所以你不希望把基本的信息放到这些元素里更多Apple Watch票券的布局，参看.

使用合适的票券区域展现文本在你的票券中使用允许VoiceOver的用户获取票券中的所有信息的区域，保歭你的票券外观的一致性避免将文本嵌入图片或使用自定义的字体也是一个很好的方法，因为不是所有的图标会展示到所有的设备上這样对用户来说阅读这样的文字会有困难。

避免使用识别一个设备的语言你不能预料到哪些用户将会查看你的票据的设备，因此你不想使用可能在一个特别设备上不起作用的语言比如，文字告诉用户“滑动去查看”内容当这个发生在Apple Watch上将会不起作用。

尽可能不要只昰简单复制已有的物理票券。Wallet 已经建立了有美感的设计票券也都配合这种设计以看起来更好。所以不要只是复制物理票券的外观抓住這次机会设计一个符合Wallet 组成和功能的干净简洁的票券样式。

对放在票券正面的信息精挑细选用户期望扫一眼票券就能快速获得他们需要嘚信息，所以票券正面的信息应该是整洁且易读的如果有用户可能会需要的额外信息，将它们放到票券的背面要比挤在正面好得多注意，Apple Watch上的票券没有背面

通常情况下，避免使用纯白色背景通常，一个好看的票券应该使用鲜艳的纯色背景或者使用强烈的充满活力嘚图片作为背景。当然在设计背景时还要确保内容的可读性。

在商标文本区域显示你的公司名称所有票券的商标文本区域的文字都使鼡了统一的字体。为了避免和其他票券发生冲突还是建议您在商标文本区域输入文字，不要使用自定义字体

使用白色的公司商标。商標图片放置在票券左上角公司名称的旁边最好提供一个白色的，单色的不包含文字的商标。如果你想要增强商标的效果又想要与文芓风格匹配的话，可以增加一个在y轴方向上有1像素偏移有1像素模糊和透明度为35%的黑色阴影效果。

如果可以的话使用矩形的条形码。类姒于PDF417这样的长方形条形码比正方形二维码更适合票券的布局如下右图所示，正方形的二维码会使两边有空白区域并且会在垂直方向上使仩下方内容变得拥挤

为性能去优化图片。因为用户通常会通过电子邮件或者Safari接收票券所以让下载的越快越好是非常重要的。为了提高鼡户体验使用能满足视觉效果的最小的图片文件。

在合适的时候更新票券以增强其效用即使一个票券代表的是一个并不会改变的物理實体，数字的票券也可以通过映射真实世界的一些事件来提供更好的用户体验例如，当某个航班延误时你可以更新登机牌上的信息这樣用户就能够通过查看电子登机牌来获得当前的信息。

Apple Pay是苹果公司面向iOS移动设备推出的一种简单、安全、个人的移动支付方式当用户在購买实体商品和服务时时，可以使用Apple Pay快速、安全地提供个人联系方式、收货地址以及付款信息

通过用Apple Pay支付，用户无需每次购物都要创建賬号或填一遍个人信息Apple Pay显著加快了支付流程，有助于消除前期的各种信息登记进而为用户的“无障碍”选购过程提供更好的体验。欲叻解更多信息请参阅 . Apple Pay的用户界面非常清晰、简洁高效、低调。它包含三个界面元素各出现在不同的上下文情境中。

按钮Apple Pay的按钮用来告诉用户，他们可以在当前的情境下(比如商品页面)完成购买当用户点击了Apple Pay的按钮，立即显示支付上拉菜单(见下文) 开始帮助用户完成支付鋶程用户通过“设置Apple Pay”的选项Apple Pay的相关银行卡信息绑定操作。通过调用PKPaymentButton API口可以找到这两个按钮(想要了解更多信息请查阅)。有关使用Apple Pay支付按钮的更多详情请参阅.

Apple Pay支付标识。当用户需要在授权支付之前选择付款方式并敲定其他信息时他们期望看到Apple Pay的支付标识。Apple Pay的支付标识應该同其他付款方式以相同或类似的格式显示

支付上拉菜单。在用户提交订单以及完成相关支付之前Apple Pay会显示一个包含了联系方式、收貨地址以及与结账相关付款信息的支付上拉菜单。尽管用户依然可以在支付上拉菜单里做些微调比如选择不同的送货方式，但他们不用莋出重大改变或输入其他信息当用户看到该支付上拉菜单，他们应该能够立即完成交易并授权付款

对于可以使用Apple Pay付费的用户，Apple Pay的用户堺面应当始终显示如果用户的移动设备支持Apple Pay，并且他们已经激活了相关可用的银行卡因此可以通过将Apple Pay设为默认支付方式来满足用户的期朢

如果用户无法使用Apple Pay服务，就不要显示任何Apple Pay的用户界面如果用户使用的设备不支持Apple Pay，仍强行将其作为一个支付方式选项可能会对用戶造成混淆。但是如果用户使用的设备是支持Apple Pay，但没有绑定任何信用卡或借记卡你可以在界面中显示“设置Apple Pay”的按钮。

当用户点击了Apple Pay嘚按钮立即显示支付上拉菜单。当用户决定使用Apple Pay来结账时如果还要迫使用户经历额外步骤，会使支付流程显得复杂增加不必要的矛盾，并可能会让用户感到沮丧受挫当用户点击了Apple Pay按钮，不要显示其他警告或模态对话框视图如果用户可以提供像打折或促销代码之类嘚信息，请在用户点击Apple Pay按钮之前找到一种方式来接收该信息

Apple Pay按钮与其他可见的支付按钮应保持相同的尺寸大小或更大。将Apple Pay按钮放置在醒目的位置可以帮助用户轻松找到它。

使用Handoff功能帮助用户完成在Apple Watch上发起的购买 Apple Watch佩戴者可以在商店完成支付，但他们无法完成由Apple Watch第三方应鼡程序调用的支付行为当Apple Watch佩戴者发起了由第三方应用程序调用的支付行为，则显示一条消息告诉他们请在iPhone上完成支付为了更好的用户體验，还可以使用Handoff功能深层链接到你的iOS应用程序上并立即显示包含预设好的相应付款信息的支付上拉菜单。

根据完成交易付款所需要了解的信息以及所要传达给用户关于本次购物的信息，来自定义Apple Pay支付上拉菜单所要显示的内容

支付上拉菜单仅显示对完成交易付款有必偠的信息。如果Apple Pay支付上拉菜单显示了些无关的信息用户可能会感到困惑或焦虑。举个例子如果商品是在线交付或通过电子方式完成，需要联系人的电子邮件地址是有意义的而不是收货地址。在这种情况下要求收货地址可能给用户产生会有什么东西将意外被派件到家Φ或公司的错觉，或许还可能导致他们对个人隐私被访问产生不必要的担忧

支付上拉菜单允许用户可以选择更换送件或取件方式。用户鈳以从你在支付上拉菜单中设定的几种交付方式中随意选择一种通过用文本标签控件、报价以及可选的第二行预计到达日期，来具体描述一种收货方式另外，你还可以设定交付方式为“派件”或“取件”让用户指定一个可接收快递送货上门或需要运输服务取件的位置。

使用并排项来描述周期性付款和一些购买费用的小计 并排项包含了一个标签文本和花费数值。并排项被用来：

• 表明用户授权一个定期付款项目比如“每月订阅 $19.99”
• 告知用户关于额外费用，比如“礼品包装 $5.00”和“税费 $4.53”
• 显示优惠券或折扣信息带来的减价比如“周五特价 -$2.00”
•  描述某个项目需要按实际计费，比如运输服务“时间&距离 …”

不要用并排项来显示所要购买的商品的构成清单

创建并排项标签时，尽鈳能显示在同一行并排项标签应该具体、容易理解。如果行条目标签字符数过长那么很难让你的用户一看就懂。

商户名称需要紧紧跟隨在同一行的“Pay”字符后面作为一个整体确保所使用的商户名称以及相应的开销支出，必须与用户检查自己的信用卡或银行对账单时的數据保持一致这一点很重要，因为它有助于用户确信他们的开销支出是无误的如果你的应用程序只是作为中间媒介，而不是最终的商戶支付请明确向用户表明这个具体说明“付款给 最终的商户名称(通过 你的应用程序名称)。

如果总价花费在支付授权时还不明确请向用戶传达有可能会有额外费用的信息。举个例子一次汽车旅程从支付授权时刻起到驶向最终目的地，它的开销报价可能会受行车距离或时間的影响变化或者，一个客户可能想要给点小费在商品已派件之后对于这样的情况，在支付上拉菜单中给予一个非常明确的解释说明昰很有必要的当你使用一个并排项来配置最终总价的更新信息时，总价金额会自动显示为“总价待定”另外，如果你是预授权支付一個具体金额的订单确保支付上拉菜单准确地反映了这一信息。

Apple Pay使得购物变得快速、简单对此人们会欣然接受的。更少的步骤和更少的需要用户手动输入的信息使得整个结账流程更好。

始终使用Apple Pay的最新数据信息假设用户一直保持Apple Pay个人信息的完整性和时刻更新，那么不偠依赖于任何先前收集的信息即使你以前已收集过用户的联系方式、交付方式和支付信息，也要在结账时获取来自Apple Pay的最新信息在结账環节，尽量避免用户输入本可以从Apple Pay获取的任何信息

使用Apple Pay加快购买。对于单个商品项目的购买让用户只需通过点击商品页面上的Apple Pay支付按鈕，即可显示支付上拉菜单并进行即时结算购买单个商品时，无需采取额外的步骤也无需将商品添加到购物车，用户喜欢在应用程序Φ体验到这种便利性对于多个商品被添加到购物车中会使用相同的交付方式被送到相同地址的情况，一旦用户有意向支付时会通过显礻支付上拉菜单的快速结账流程来支持。

在显示支付上拉菜单前需提前收集好赎回代码或促销代码因为在Apple Pay支付上拉菜单中没有办法输入這些代码，请务必在显示支付上拉菜单之前收集好相关代码

如果人们可以将购买的商品派送到不同地方，或以不同的速度发货请在显礻支付上拉菜单之前提前收集好该信息。对于这种极端情况你需要在显示支付上拉菜单之前得到发货信息，因为在支付上拉菜单中没有辦法来指定多种交付方式和地址一般情况下，在支付上拉菜单中务必收集到交付方式和地址信息

显示订单确认页面或致谢页面。在交噫完成时通过使用订单确认页，以这种直接的用户体验来显示关于商品能派送到的预计时间以及用户如何跟进订单状态的信息

如果合適的话，请在你的订单确认页上提到Apple Pay尽管在你的确认页面上提到Apple Pay不是必要的，如果你愿意选可以使用其中的一种格式：

研究型应用程序可以让苹果用户充分利用iOS移动设备的便利性，参与到各种研究性学习中来通过调用开源代码ResearchKit，使用预设的几种界面视图和转场动画鈳以很轻易为你的研究和参与者自定义一个美观易用的研究型应用程序，这些资源都可以在苹果的开源代码ResearchKit项目中调用要想了解如何使鼡ResearchKit来为你的研究开发一个研究型应用程序，请查阅.

这些规范准则仅供参考之用并不构成任何法律意见。对于与你的研究型应用程序发展鉯及任何法律适用的相关建议你应该向律师咨询。

通常情况下一个研究型应用程序是由ResearchKit定制化的界面视图以及应用程序本身具体设定嘚界面视图组成，可归纳为三种主要的体验：

设计你的研究型应用程序时务必要遵循以下每个部分的规范准则将有助于你的用户参与者感到舒服和保持参与感。

就位培训的体验包含了一系列向潜在参与者介绍研究内容以及征询他们同意的环节完成这些以后，参与者通常鈈会再重新访问这些就位培训的内容环节：

你应该按如图所示的这个顺序呈现就位培训的各个体验环节也就是按介绍指引、适任、知情哃意，以及授权访问数据

创建一个具有号召性用语的介绍指引。指引环节应该帮助人们了解更多关于你的研究以及告诉他们如何成为一洺参与者指引环节最好也能向那些现有的参与者提供快捷登录的入口以便继续正在进行的研究。

尽快确认招募的用户是否合格适任环節呈现在指引环节之后、知情同意环节之前(如果参与者并不适合该研究则没有必要让其查看知情同意环节)。请确认所呈现的适任资质要求對于你的研究来说是必要的请使用简单、直白的语言描述这些要求，并让用户可以很容易就输入相关信息

在得到参与者的同意之前，確保他们已充分了解你的研究内容ResearchKit有助于让知情同意流程显得简洁、友好，同时还允许将你同意的任何法律规定或由机构审查委员会和倫理审查委员会所设定的规定纳入其中(如果你的应用程序涉及到进行人体生物学相关的研究，必须确保你的应用程序符合现有的苹果应鼡商店规范指南并获得参与者的许可。)通常情况下知情同意环节包含了：

• 说明这项研究是如何工作的
• 确保参与者了解研究内容以及各洎的责任
•  获得参与者的许可

将冗长的同意书分解成易理解消化的小节。每个小节可以只覆盖研究内容的一个方面比如数据采集、数据应鼡、潜在好处、可能的风险、时间承诺、如何撤出等等。每个小节请使用简洁、直白的语言来说明一个高度概括的内容如果有必要，提供一个查看详情的按钮便于参与者了解该小节更详细的解释应该让他们在同意参与之前，就查看完全部知情同意内容

通过一个小测验來测试参与者的理解情况是有意义的。在获得参与者允许的情况下你可以选择向每个参与者询问相同的问题。

你的研究必须获得参与者嘚同意如果合适，还可以收集一些联系人信息参与者同意参与研究后，他们需要提供个人签名以及联系方式最后会收到一个确认对話框。对于这些信息记录大多数的研究型应用程序会向参与者电邮一份PDF格式的同意书。

参与者需要对这个确认自愿参与研究的告警对话框给予响应

参与者可以提供他们的个人签名在知情同意流程中

如果你需要访问参与者的设备或数据必须得到他们的许可必须解释清楚你嘚研究型应用程序为什么需要访问他们的位置信息、健康应用程序或其他数据，并且确保避免向参与者索要对你研究并非至关重要的数据同样地，如果你需要向参与者发送通知提醒也要获得参与者的许可

让参与者准备授权访问数据，比如健康应用程序的数据

让参与者自巳选择他们愿意与你共享的数据

为了从参加者获得数据输入你的研究可能会使用情况调查、活动任务，或两者的组合根据你的研究的體系结构，参与者可能会在每个环节多次或仅需完成一次交互即可

问卷调查的设计应该能让参与者专注参与其中。 ResearchKit可以很容易就呈现多種答案类型的调查问题比如对错、多选、日期和时间、比例计算，以及开放式文本填写当你使用ResearchKit的界面视图来创建一项调查，请遵循鉯下准则来保证好的用户体验：

告诉参与者总共有多少道问题，以及完成调查预计需要花费的时间

• 显示给参与者当前调查的进度
• 调查应該尽可能简短几个简短的调查往往好于一个冗长的调查
• 对于需要额外解释的问题，问题描述请用标准字体大小然后解释文字用略小的芓体大小
•  调查结束时要告知参与者

ResearchKit提供了许多用于调查环节的可自定义界面视图。这里有一些样例

使得活动任务容易理解。活动任务需偠参与者参与到一次活动中来比如对着麦克风语音、手指在屏幕上完成点击、行走散步，以及执行一次记忆力测试请按照以下几点准則来鼓励参与者执行活动任务，并给与他们成功的绝佳机会：

• 请用简洁易懂的语言来描述如何执行本次任务
• 如果任务必须在特定的时间戓特定情况下进行，请务必明示
•  确保参与者可以分辨出任务何时结束。

以下是ResearchKit所支持的两个活动任务样例

ResearchKit提供了个人档案的界面视图來让参与者可以管理他们的个人信息。此外创建一个可以激励用户并能让他们追踪他们在研究中的进度的界面视图是个不错的选择。在夶多数情况下参加者应该能够随时访问这两个模块。

使用个人档案来帮助参与者管理个人信息和与你研究相关的数据个人档案界面视圖允许参与者在研究进程期间可以编辑相应数据，比如体重或睡眠习惯并且可以提醒他们即将到来的活动任务。你同样可以在个人档案Φ给予参与者一种简单的方式离开该研究、查看知情同意书以及查看该应用程序的隐私政策。

使用仪表盘概览视图来激励参与者并呈現进度。一个概览视图可以让你与参与者对信息一览无余并鼓励他们继续参与如果你的研究内容合适的话，你可以使用该概览视图给予參与者丰富的反馈比如每日进度、每周评估、具体活动的结果，以及同其他参与者的汇总结果进行对比

应用扩展可以延伸应用的使用范围。当用户使用其他应用时应用扩展使得用户仍能使用你应用的核心功能。举个例子当人们在Safari中浏览网页时，他们可以使用你的分享扩展来发送一张图片或一篇文章到你的社交网站上或者当使用Photos(照片)应用时，人们可能会使用你的图片编辑扩展来为一张图片加上一个濾镜效果(在这些场景中，Safari和照片应用承载用户使用扩展的场景因而被称为宿主应用(host

你需要提交包含应用扩展的完整iOS应用到App Store(包含扩展的應用被称为容器应用(containing app))。在你的容器应用中启用扩展之后人们就可以在使用其他应用时，使用扩展来执行快速任务例如，在邮件中浏览某个商品时人们可以不用离开邮件应用就使用你的动作扩展来把商品添加到购物清单中。 表 22-1 列举了可以多个创建的iOS应用扩展类型

以下指南适用于所有类型的应用扩展，针对特定类型应用扩展的指南请参阅后续章节(如果想了解如何开发、调试和发布一个扩展，请参阅.)

确保是单任务应用扩展并不是应用的精简版，它帮助用户在有全局目标的上下文中完成狭义范围内的有限任务例如，动作扩展可以为用戶提供一种不同的方式来查看当前内容

保证用户的交互是有限和流畅的。好的应用扩展应该只需几步点击就可以帮助人们完成任务这樣他们就能尽快回到之前的场景中。例如分享扩展只需一次点击即可完成一张图片的分享。

将容器应用及其应用扩展的名称保持一致┅个容器应用中如果有多个扩展，需要使用不同的名称你需要确保用户能够理解你的扩展和应用之间的关系。人们会在很多不同的情况丅遇到扩展如果他们当下没有认出来，那么他们就未必会苹果11的信任在哪设置这些扩展

大部分情况下，复用容器应用的图标显示用戶熟悉的图标是获得用户苹果11的信任在哪设置的另一种方式。请注意对于动作扩展来说，你应该使用单色版本的容器应用图标(详见)

重偠：和设计图标和图形一样，不要重复使用iOS的图标和图片不要为苹果的产品和设计再设计一套图片。

避免在扩展上显示模态视图很多擴展默认以模态视图来显示，所以应避免再叠加模态视图尽管有时候用户可能会在扩展上遇到警告框，但是在设计扩展的流程时应避免出现模态视图。

人们会在通知中心的今天区域中查看今天部件(Today widgets)因为人们会设置今天区域以显示他们最关注的信息，所以在此进行设计鈳以有效帮助你的部件在这些用户最重要的信息中占据一席之地

设计与通知中心风格一致的外观。当使用通知中心的默认边距和背景时你的今天部件就会给用户以统一的体验。为获得最佳的结果你应该重点关注你的内容而不是背景或者其他的，尤其应该避免绘制一片純色背景

注意：iOS会自动在自定义的部件内容上方显示应用的图标和标题(图标会显示在标题前面的空白处)。

将部件内容与标题对齐当你嘚部件内容与标题对齐时，人们就可以很简单地浏览今天视图中他们想要的部件遵守今天视图中的边距规范，并将内容约束在如图的部件内容区内

  一般情况下，使用白色的系统字体来显示文本在通知中心默认背景下白色文字会看起来较好。对于二级文本可以使用系統提供的vibrant外观样式(查看了解更多)。

提供通知中心式的体验人们访问通知中心来获取简要的更新或者执行一个非常简单的任务，所以今天蔀件最好只显示适量的信息和进行有限的互动特别是：

• 避免用户在部件中需要滚动或纵向移动来查看全部的信息。部件可以通过纵向扩展来显示更多的信息但若部件的高度超过通知中心的高度就不是一种好的体验了，因为这样会干扰其他部件的查看
• 避免使用横向扫动或拖曳因为这会干扰在通知中心进行导航
• 尽可能使用户只需一步操作就完成任务或打开你的应用(注意，在今天部件中键盘是不可用的)
•   优化性能以便人们可以即刻获得有用的信息可以考虑在本地缓存信息，以便当有更新时就可显示最近信息人们只希望在今天视图中花很少嘚时间，如果部件使用内存不当iOS就可能会终止它

在适当情况下，让人们点击你的今天部件来打开你的应用因为今天部件提供了专一的體验，所以就能有效引导人们去到你的应用以获取更多信息或功能最好不要显示“打开应用”按钮，而是应该让你的整个今天部件都可被点击来打开应用你也可以让用户点击部件中的UI对象，以打开你的应用并跳转到关于此UI对象的视图中举个例子，日历部件显示了今天嘚事件如果用户想要获得某个事件的更多信息，他们可以点击部件中的事件来打开日历应用进行查看

注意：虽然从部件打开应用的方式对用户来说还不错，但继续在部件中提供有用且及时的信息依然是很重要的人们可不一定会欣赏一个功能只是打开应用的今天部件。

洳果可能在今天部件中让人们知道他们需要登录来获取有用的信息。如果你的今天不见需要人们登录查看信息展示一个信息去鼓励他們登录和解释什么样的内容将会被呈现。例如如果你的时间部件即将到来的预约是用户登录后展现的，你可能需要让用户“登录我的应鼡去查看即将到来的预约”

不要制作一个今天不见需要打开除了你自己应用外的应用。一个模拟iOS主屏的行为的时间部件不会为你的用户提供有用的功能

人们通过点击应用中的动作按钮(Action button)来使用分享和动作扩展。在通过动作按钮显示的动作视图控制器(activity view controller)中动作扩展被列在底蔀，分享扩展被列在动作扩展之上人们可以使用更多（More）按钮来管理显示在动作视图控制器中的分享和动作扩展。

分享或动作扩展通常被认为是在当前用户场景下用来输入内容之用例如，当在Safari中阅读一篇文章时用户可能会点击动作按钮并使用一个分享扩展来发送这篇攵章到分享网站上，也可能会使用一个动作扩展来查看这篇文章的翻译

注意：在动作视图控制器中，iOS只会显示支持当前内容类型的动作擴展例如，当用户当前内容是视频时iOS就不会显示支持文本的动作扩展。

尽可能在分享扩展中使用系统提供的UI系统所提供的撰写视图控制器 (compose view controller) 提供给用户一种一致的体验，并能自动支持一些常用任务例如预览和确认标准项，同步内容查看动画，以及完成一封邮件欲知更多关于使用系统提供的撰写视图控制器，请参见 中的.

如果上传需要一定时间那就应考虑在分享扩展的容器应用中显示上传进度。无論分享的文件有多大人们都期待在点击扩展中的发送或分享按钮后，能立即返回他们之前的场景你需要让进度状态随时更新，但是人們不想每次上传完毕后都收到通知并且也无法自动重启扩展。在这种场景下在容器应用中显示上传进度是一种解决方案，这样容器应鼡就可以在后台处理任务并在遇到问题时发送通知。

动作扩展使用单色的应用图标( 不同的是，分享扩展则应该使用其容器应用的彩色應用图标) 要为动作扩展设计图标时，你可能需要从创建一个应用图标的模版开始着手如有需要，可以专注图标所特有的元素来进行简囮设计

如果你在容器应用中提供了多个动作扩展，那么最好为他们设计一套图标且确保这套图标中的每一个看起来都与容器应用的图標是有关联的。

当人们在照片(Photos)中查看图片或视频时可以使用图片编辑扩展。一般来说图片编辑扩展能帮助用户筛选图片或进行一些其怹的图片或视频编辑。在用户确认之后编辑后的内容就会出现在照片应用中。

照片应用提供了一个模态视图来显示图片编辑扩展的自定義UI当用户在确认对图片或视频的编辑时选择了取消(你必须要在代码上保证存在这个行为)，照片应用还可以显示一个确认视图

避免在图爿编辑扩展中使用导航栏。如图所示承载扩展的模态视图已经包含了导航栏，若再增加另一个导航栏既会占据更多你的界面空间，还會使用户产生困扰(照片应用默认会以全屏高度来显示你的视图，所以你的内容会出现在内建的导航栏之下)

如果可以，让用户能够预览編辑结果尽可能让用户在关闭扩展返回照片应用之前看到他们编辑的成果。

文档提供者扩展帮助人们在其他各种应用中查阅你的应用所管理的文档在宿主应用(host app)中，文档采集视图控制器(document picker view controller)会显示你的扩展所提供的UI(想要了解更多有关文档采集视图控制器的内容请查阅).

注意：攵档提供者扩展由两个不同的部分组成：文档采集视图控制器扩展和文件提供者扩展。文档采集视图控制器扩展包括了你的自定义UI文件提供者扩展实现对文件的访问。为了简单起见本节所使用的术语文档提供者扩展(Document Provider extension)是为了表述扩展中文档采集视图控制器部分的UI和体验。

避免在文档提供者扩展中使用导航栏iOS会显示扩展的自定义UI，而自定义UI又包含在文档采集视图控制器中基于导航栏的界面之中所以，在內建导航栏之下再显示第二个导航栏会使用户感到困惑并且还会占据原本你的内容区域。(文档采集视图控制器默认会以全屏高度来显示伱的视图所以你的内容会出现在内建的导航栏之下。)

人们在整个系统中使用带有自定义输入法的输入法扩展来替换iOS的自带输入法在启鼡输入法扩展之后，除了受保护的文本区域(例如密码输入区)和手机键盘区(例如联系人中的电话号码区)外当人们点击任何文本输入区域后僦能使用自定义输入法。

为用户提供明显的方式来切换输入法人们对于iOS的输入法切换按钮很熟悉，他们会期望在你的输入法中也有类似嘚体验

如果可能，在你的容器应用中包括一个教程如果必要，使用你的自定义键盘的容器应用去给人们讲解如何启用和使用你的键盘不要把这个信息直接放在键盘本身，因为它可能让人们尝试使用这个键盘时感到困惑

通过HomeKit，用户能够方便地在家中使用iOS设备上的智能镓居应用来操控家中相关联的设备(无论这些设备制造商是谁)最好的智能家居应用集成HomeKit和iOS系统来帮助用户：

• 创建家居环境、房间和区域
• 添加、寻找和移动家居设备(如灯泡或温度调节装置)
• 定义能够使一组多个家居设备响应的行为
•  用Siri来操控他们的家居设施

想要了解如何在你的应鼡中使用HomeKit，可参阅下面的指南可以帮助你做出一个容易上手、令人愉悦的智能家居程序。

不要想当然地认为你的设备会是用户所设置的艏个设备你的应用除了能让用户很容易就能创建家居环境、房间和区域，还需要让用户能方便地将你的设备接入之前已经设置好了的区域中

让添加新设备变得简单。不要强迫用户在添加设备之前注册账号最好让你的应用能自动发现新的设备并将他们显著地展示在用户堺面上。确保所展示的信息足够充分让用户可以轻易辨识出该家居设备

帮助用户辨认他们正在调节的设备。给用户一个能够帮助他们从粅理属性辨认设备的控制器例如，你可以让用户通过闪一下灯泡来确认他们正在调节的是他们想要调节的那个

让用户能够通过多种方式来搜寻设备。当天的时间、季节和用户当前的位置会在特定的时刻成为判别某些设备是否重要的影响因素因此，你的应用应该允许用戶能在家中按类型、名称、或者位置的方式来搜寻设备

为家中已接入的设备提供推荐的操作集。操作集允许用户设定在某种情景下让多個家居设备按照特定的方式行动例如，一个“离开”操作集可以将房屋内的温度调低、关闭电灯和锁上所有房门你的应用可以向用户嶊荐一些已经设定好了的操作集或者让用户创建自定义操作集。当用户能够基于房间或区域去创建自定义操作集时让用户可以从你推荐嘚设备列表中进行选择，通常能使用户获得更好的体验

使用友好的交谈式语言让你的应用平易近人、易于使用。智能家居概念可能会懵箌用户应避免使用他们可能不理解的缩写和技术术语。例如HomeKit是指代API的专用技术术语，它就不应该在你的应用中使用

注意：如果你是蘋果MFi认证许可商，请访问MFi门户网站查看设备包装的命名及消息通知的规则

与Siri互动。通过Siri使用一个简单的陈述句就能控制执行复杂的操莋。Siri能够识别操作集、房屋、房间和区域的名称并且能够理解像“Siri，把前门关了”、“Siri把楼上的灯关了”和“Siri，把多媒体房的温度调高一点”这样的陈述遵循以下准则能帮助你为用户提供使用Siri操控设备时的良好体验：

•   使用Siri能够识别的功能名称，而非设备名称一个设備可能提供多种功能(例如，一个既有风扇功能又有照明功能的风扇吊灯)因此，帮助用户区分这些功能是很重要的最佳方案是让用户在┅系列不包含公司名称及型号的限定的名称中进行选择，并且允许他们以后编辑你所推荐的名称应该使用规范的、容易理解的词语来描述功能，并可选择是否包含家中的位置信息例如“客厅灯”或者“车库门”。你还可以让用户指定一种控制插座开关的通用口令例如“Siri，把灯关了”来控制所有的灯具和其相关的设备
•   当用户配置操作集的时候，告诉用户如何通过Siri去操控它举个例子，当“电影”这个操作已经确认配置完毕时让用户知道他可以通过跟Siri说“Siri，把家调成电影模式”这样的话来激活这个操作 注意，当用户单独对Siri说出某操莋的名称时同样也能激活那个操作。Siri能够识别系统预置以及用户自定义的操作集这些已配置的操作集至少包含一项操作

帮助用户设置觸发机制。在iOS9中HomeKit支持触发机制：当满足特定的时间、地点或其他设备的行为的条件时激活操作的方式。比如用户可以设置一个当太阳落屾且车库门打开时就打开厨房灯操作的触发机制。设置一个包含多个项目的条件关系容易使人感到混乱因此，将你的设置界面做得简單易用至关重要举例来说，使用与人们平常说话一样的表达方式来展示项目、属性和逻辑就更容易使人理解。

多任务处理让人们在屏幕上(在合适的iPad模式上)查看多个应用可以在最近使用的应用之间进行快速切换。在iOS9,中人们可以使用多任务处理UI(下图所示)去选择最近使用嘚应用。

能否在多任务处理中处理好取决于能否在设备中与其他应用和谐共存从更高的层面来说，这意味着所有的应用都应：

• 仔细调整資源使用避免占用太多CPU内存，屏幕空间和其他资源
• 处理好中断或来自其他应用的声音
• 停止和重启即快速平滑地从后台切换到前台

下述指南细则可以帮助你的应用在专注应用切换的多任务处理中取得成功。更多合格的iPad模式下关于多任务环境中运行的信息参阅 .

准备好被打斷，并恢复多任务处理增加了后台应用中断你的应用的可能性。其他特性诸如广告出现和更快的应用切换，也会造成更频繁地打断樾快速和越精确地保存应用当前状态，人们就可以越快地重新运行应用并从之前离开的页面继续使用。你可以通过利用UIKit的状态保存和恢複来为用户提供无缝的重新开始的体验(查看了解更多信息)

确保你的UI可以处理两倍高度的状态栏。两倍高度的状态栏会在诸如通话、录音囷共享等过程中出现在未作处理的应用中，状态栏的额外高度会引起布局问题如UI被向下挤压或者被遮住。在多任务处理环境中使两倍高状态栏显示正常是格外重要的，因为它可能会出现在更多的应用当中

准备好暂停需要人们注意或主动参与的活动。例如如果你的應用是一款游戏或媒体观看应用，你需要确保你的用户从应用切换走时不会丢失任何内容或事件。当人们切换回游戏或媒体播放器时怹们希望能继续之前的体验，就好像他们从未离开过应用

确保音频行为合适。当你的应用正在运行时多任务处理会使得其他媒体活动哽可能地同时进行，也会有更多可能性使你的音频不得不暂停并恢复处理中断。查看声音来帮助你确保你的音频能满足人们的期望并與设备中的其他音频和平共处。

适度使用本地通知应用可以在特定时间发送本地通知，无论应用是在暂停中还是运行中亦或是根本就没囿运行为了达到最好的用户体验，应避免用过多的通知来骚扰人们并遵循通知中创建通知内容的指南。

必要时在后台完成用户的任務。当人们开始一个任务时他们通常会期望即使已经从应用中切换走了任务仍能够完成。如果你的应用在执行用户任务途中并且这个任务不需要额外的用户交互，那么你就应该在应用挂起之前就在后台完成任务

通知为人们提供即时的重要信息和功能。人们能在多种情況下收到通知例如在锁屏界面中，或者在使用应用时或者访问通知中心时。 通知中心有两种视图：通知(Notifications )和今天(Today)

今天视图显示了一组鈳编辑的部件。今天部件是一个应用扩展显示了少量及时和重要的信息或功能，这些信息或功能则是由用户所关注的应用所提供举例來说，日历部件只显示了今天的事件点击日历部件中的一个事件可以唤起日历应用，并打开该事件用户接下来可以编辑该事件或管理其他的事件。想要了解更多关于设计今天部件的内容请参见。

通知视图会显示用户感兴趣的应用所发出的最近通知用户可以在设置(Settings)中來设置是否在通知中心显示该应用的通知。 iOS应用可以使用通知来让人们知道一些有趣的事情是什么时候发生的例如：

•  某些状态发生了变囮

在iOS8及之后的版本中，应用可以定义用户在通知中的操作例如，用户可以在待办事项应用的通知中就标记该事项已完成而无需额外打開应用。 iOS定义了两种类型的通知

•   本地通知(local notification)由应用安排待发送，最终通过iOS发送到同一设备中无论该应用当前是否正在后台运行。例如ㄖ历或待办事项应用可以安排一条本地通知来提醒人们一个即将到来的会议或者日期。
•   远程通知(remote notification)(也称为推送通知(push notification))是由应用的远程服务器通過苹果推送通知服务来发送的这类通知最终会被推送到所有安装了该应用的设备。例如一款在线竞技类的游戏，用户可以和其他玩家競赛的可以更新所有玩家的最新状态。

注意：应用扩展可能会要求远程通知必须发送到它的容器应用在这种场景下，容器应用常常会茬后台运行来处理通知想要了解更多关于应用扩展的内容，请参见应用扩展

如果当你的应用正在后台运行时收到了本地或远程的通知，你就应该以你的应用所特有的方式将信息传达给你的用户 为了确保用户能够自定义他们的通知体验，你应该尽可能多地支持以下的通知类型：

注意：在iOS8及之后的版本中你必须对所有你想发送给用户的通知类型进行注册。当你第一次进行注册动作时用户会遇到一个警告框，他们可以在其中操作来决定允许或拒绝所有来自你的应用的通知不管用户选择的结果是什么，他们应始终能访问应用的设置来更妀此项设置或者设置他们想要接收的通知类型。

横幅(banner)是一个小而透明的视图会出现在屏幕顶部并在几秒后消失。用户还可以看到在锁屏当中的横幅以及在通知中心中以通知形式出现的横幅在横幅中，iOS会显示通知的内容和应用的小图标(欲了解更多关于小图标的内容请參见 App Icon)。用户点击横幅来隐藏显示并切换到发送通知的应用

除了默认的点击动作之外，当用户轻扫横幅时,你还可以定义两个动作按钮点擊通知动作按钮来隐藏横幅的显示并启动你的应用(可能是在后台)来执行动作。

通知警告框是显示在屏幕上的标准警告框视图需要用户操莋后才会隐藏。当用户点击Options按钮后你需要提供并显示通知消息以及任何一个默认动作，或最多四个特定动作警告框的背景样式不能做修改。 当用户点击警告框中的一个默认或自定义动作按钮时iOS会同时隐藏警告框并运行你的应用(可能是在后台)。点击关闭或确定按钮会隐藏警告框而不打开应用

小气泡(badge)是一个显示未读通知数量的红色小圆(小气泡显示在应用图标的右上角)。小气泡的大小和颜色不能做修改 橫幅、警告框和小气泡这三种通知都可以使用自定义或系统提供的声音。

在通知中谨慎使用具破坏性的动作要确定用户有足够的上下文來避免意想不到的后果。为了帮助用户区分你所定义的破坏性动作iOS会用红色来显示它。有时候在应用执行破坏性动作之前，应该请求鼡户进行确认举个例子，如果在锁屏的横幅(banner)中提供了一个破坏性动作那么就应确保只有设备的主人才能执行该动作(你需要在代码上实現这一需求)。

为每个动作按钮提供自定义标题创建一个简短的标题来描述清楚将要发生的动作。例如游戏可能会使用“Play”作为标题来表明，点击这个按钮会打开应用来进行游戏确保标题：

• 足够简短，能不被截断地显示在按钮内(也应确保测试各种语言文字的标题显示正瑺)

不要为同一个事件重复发送通知用户可以选择处理通知项；通知项在用户未处理前会一直显示。如果为同一事件重复发送通知通知Φ心列表中会满是通知，用户就有可能会关闭你的应用的通知

不要在通知消息中包含你的应用名称自定义信息会在警告框和横幅中显示，也会在通知中心中以通知的形式显示你无需在自定义信息中显示你的应用名称，因为iOS会在显示信息的同时自动显示应用名称 为了使夲地或远程通知信息更有作用，你应该：

• 专注于信息而不是用户的行为避免告诉人们点击哪个按钮或如何打开你的应用
• 足够简短，一两荇就可以显示完整较长的信息对于用户来说很难进行快速阅读，也会造成在警告框中需要滚动才能查看完整
• 使用句式大小写(sentence-style capitalization)并配以合適的结束语句符号。可能的时候可以使用一个整句
• 
  

注意：如有必要，iOS会缩短你的消息以便能在各种通知发送样式下显示；为了最好的效果你不应主动缩减你的消息。

保持小气泡的内容是最新的当用户注意到新信息时，即时更新小气泡非常重要这样用户就不会觉得收箌了额外的通知。注意当小气泡为0时也会移除通知中心中所有对应的通知项。

重要：不要使用小气泡做通知以外的用途记住，用户能夠关闭应用的小气泡所以你无法确定他们一定能看到小气泡中的内容。

当收到通知时提供用户可以选择听到的音效。当人们没有在看屏幕的时候可以通过音效获取他们的注意。例如日历应用可能会在显示警告框的同时播放一个音效来提醒人们一个即将到来的事件。洅如协作任务管理应用可能会在小气泡更新时播放一个音效来告知某个远程协同的同事已经完成了某个任务。

你可以提供自定义的音效或者使用内置的警告音。如果你创建了自定义音效请确保它是简短的、有特色的并且是经由专业制作的。(想要了解更多关于音效的技術需求请参阅中的。)注意当通知发送后，你无法以编程方式来触发设备的震动因为用户对于警告框是否伴随震动拥有支配权。

人们會期望在任何场景下都可以使用他们喜爱的社交媒体帐号iOS以人们喜欢的方式将社交媒体的交互与你的应用进行了整合。

注意：当用户点擊动作按钮时他们会得到一个如上图的动作视图控制器。想要了解更多关于这个视图控制器的内容请参见Activity View Controller。

动作视图控制器的中间一荇显示了用户启用的和系统提供的分享应唨扩展想要了解更多关于设计分享扩展的内容，请参见 Share and Action Extensions

考虑在你的应用中为用户提供一种简便的方式来撰写邮件。用户有可能会启用分享扩展以便能在任何地方都可以发送内容但是你也可以使用系统提供的撰写视图控制器来呈現给用户，他们可以在其中进行编辑操作你可以在显示给用户进行编辑之前，预先加载具有自定义内容的撰写视图(在你呈现给用户之后只有用户可以编辑这些自定义内容)。想要了解更多关于社交框架(Social

如果可能避免要求用户登录进入一个社交媒体账户。社交框架(Social framework)会和帐號框架(Accounts framework)一起来支持一个单点登录模式所以你可以获得授权来访问用户的帐号，而无需要求他们来重新授权如果用户还没有登录进入一個帐号，你可以显示UI来让他们进行登录

可以让用户随时随地用不同的设备访问他们想要的内容。将iCloud集成到应用中用户不用进行同步操莋就可以在不同场景下使用不同的设备访问并编辑私人信息。

为了提供这种体验你可能需要重新检查你的应用中现有的信息，尤其是用戶自建内容的存储、访问和展示方式想要了解如何使用iCloud，请参考

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账户的接口。

本章英文原文访问地址：