一、3D Touch
3D Touch为触摸交互增加了额外的维度。在支持的设备上，用户可以通过向触摸屏施加不同程度的压力来访问额外的功能，应用程序会通过显示菜单、显示附加内容或播放动画回应。用户不需要学习新的手势来交互3D Touch。当他们在屏幕上轻轻按下并得到响应时，他们很快就会发现额外的交互维度。
1.1 主屏幕交互
在主屏幕按下支持3D Touch的应用程序图标，会显示一个动作视图。此视图让用户快速执行常见的APP任务，并查看有趣信息。例如，日历提供了创建事件的快捷方式，还显示了您日程中的下一个事件。设计指南请参阅 Home Screen Actions和Widgets.
1.2 Peek和Pop（预览和详阅）
Peek允许用户在当前视图中使用3D Touch预览项目，比如页面、链接或文件。要查看支持此功能的项目，请用手指对该项目施加一点压力，只需抬起手指即可退出预览。要打开该项目并查看更多细节，请更用力按压，直到项目弹出并填充屏幕。在一些Peek视图中，您可以向上滑动来显示相关的操作按钮。例如，当用户在Safari中预览链接时，可以向上滑动，从而显示打开后台链接、将链接添加到阅读列表中以及复制链接的操作。
使用Peeking提供实时、内容丰富的预览。理想情况下，peeking提供了足够的信息来增加当前任务，或者帮助您决定是否完全参与项目。例如，决定在Safari中打开或与朋友共享链接之前，在邮件中的预览。在选择行之前，表中经常使用Peeking来查看详细的行信息。
设计足够大的预览视图。设计一个足够大的预览视图，这样手指就不会模糊它的内容。让预览更加详细，这样用户能更好决定是否更用力按压去打开(详阅)这个项目。
始终采用Peek和Pop。如果你在某些地方支持Peek和Pop，某些地方又不支持，人们就不知道在哪里可以使用这个功能，而且可能会认为你的应用程序或他们的设备存在问题。
避免在预览视图中显示按钮样的元素。如果用户为了敲击一个看起来像按钮的元素举起手指，预览就会消失。
允许详阅每个预览。尽管预览提供给了用户需要的大部分信息，但如果用户决定放弃当前任务并专注于这个项目，要始终能让他们转向详阅模式，点击项目详阅也应如此。
不要在同一项目同时启用预览和编辑菜单。当同一项目两个特性都支持时，用户和系统很难检测到用户意图。更多指导请参阅 Edit Menus。
在适当的时候提供操作按钮。不是每个peek都需要操作按钮，但操作按钮是为常见任务提供快捷方式的好方法。如果您的应用程序已经为项目提供了自定义的触摸操作，那么最好在peeks中有相同的操作。
避免在预览中提供打开项目的操作按钮。人们通常通过更用力按压去打开他们正在预览的项目，因此不需要提供明显的打开按钮。
不要让peek成为执行项目操作的唯一方法。不是每个设备都支持peek和pop，有些人可能会关闭3D Touch。你的应用程序应该在类似的情况下提供其他的方式触发项目操作。例如，你的应用程序可以在用户触摸和按住某个项目时，在视图中反映peek的快速动作。
1.3 实况照片
应用程序支持实况照片，将压力融入照片观看体验中。当你按下照片的时候，你就可以用动作和声音来展示照片拍摄前后的瞬间。设计指导请参阅Live Photos。
二、音频
人们通过音量按钮、静音开关、耳机控制和屏幕音量滑动器来操纵声音。许多第三方配件也包括声音控制。音频可以通过内部或外部扬声器、耳机，甚至通过无线播放或蓝牙设备进行无线传输。无论声音是你应用程序体验的主要方面还是一种修饰，你都需要知道用户期待何种声音以及如何满足这些期望。
2.1 静音
用户将设备切换为静音，以避免被意外的声音干扰，如铃声和消息提示音。他们同时也希望禁用一些非必需的声音，包括键盘声音、音效、游戏音效和其他声音反馈。当设备设置为静音时，只需显式启动声音，例如在媒体播放、闹钟和音频/视频消息。
2.2 音量
无论使用物理设备按钮还是屏幕滑块，用户都期望音量的变化会影响所有的声音系统，包括音乐和应用内的声音效果。唯一的例外是铃声音量，它总是在音频没有播放时单独调整。
2.3 耳机
用户使用耳机私下听声音，并能解放双手。当插入耳机，用户期望声音能自动不间断；当拔下耳机，他们希望立即暂停播放。
2.4 设计一个很棒的音频体验。
在必要时自动调整级别，但不是所有音量。你的应用程序可以调整相对独立的音量级别来实现音频的混合，然而，最终的输出应该始终由系统音量控制。
允许适当时重播音频。用户通常想要选择一个不同的音频输出设备。例如，他们可能想通过客厅的立体声音响、汽车收音机或苹果电视来听音乐。除非有令人信服的理由，否则支持这种性能。
使用系统提供的音量视图进行音频调整。为调整音频提供接口控制的最好方法是使用音量视图。这个视图是可自定义的，包括音量大小滑动，甚至还包括重播音频的输出控制。开发指导请参阅 MPVolumeView。
短声音和振动使用系统自带的声音服务。开发指导请参阅 System Sound Services。
如果声音对你的应用程序至关重要，可以对音频分类。不同的音频类别允许声音被静音开关屏蔽，允许声音与其他音频混合，同时允许声音在应用程序后台播放。根据声音含义和设备当前音频状态选择一个音频类别，并将其分配到相应音频会话。例如，如非必要，不要让用户停止听其他应用的音乐。一般来说，除了在不同时间记录和播放音频的应用程序例外，最好避免在应用程序运行时更改类别。开发指导请参阅Audio Session Programming Guide。
在中断发生后恢复音频播放。有时，当前播放的音频会被另一个应用程序的音频打断。临时中断，比如来电，是可恢复的；永久的中断，比如由Siri发起的音乐播放列表，是不可恢复的。当一个可恢复的中断发生时，如果音频在中断启动时正在播放，应用程序应在中断结束时恢复播放。例如，在播放音频的过程中，正在播放声音的游戏和媒体应用程序都应该恢复。
让其他应用程序了解你的应用程序何时结束播放临时音频。如果你的应用程序可能会暂时中断其他应用程序的音频，它应该适当地标记音频会话，这样其他应用程序在安全恢复时就会得到通知。开发指导请参阅AVFoundation中的内容 AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation。
只有在有意义的时候才对音频控制作出响应。不论你的应用是在前台还是后台，用户要能控制你的应用程序界面之外的音频播放，比如控制中心或耳机上的控制。如果你的应用程序正需要在清晰的音频环境中播放音频，或者连接到了支持airplay的设备，那对音频控件的响应就很好。否则，你的应用程序不应该中止另一个应用程序的音频，当控制被激活时，它可能正在播放。
不要将音频控制。用户期望音频控制在所有应用程序中保持一致性。永远不要重新定义音频控制。如果你的应用程序不支持某些控件，那么根本不用响应它们。
三、Authentication（认证）
要求用户进行身份验证，以交换价值，例如个性化体验、访问附加功能、购买内容或同步数据。如果你的应用程序需要认证，保持登录过程快速、简单且不引人注目，这样不会降低你的应用的乐趣。
尽可能长时间延迟登录。如果用户在未做任何有价值事情之前被迫登录，他们往往会放弃这个应用程序。在做出承诺之前，给用户一个爱上你的应用的机会。在购物应用程序中，让用户在启动后立即浏览你的商品，只有当他们准备购买时才要求登录。在一个流媒体应用程序中，让用户探索你的内容，看看在你签约之前你要提供什么。
解释认证的好处以及如何注册。如果您的应用程序需要身份验证，在登录屏幕上显示简短友好的说明，说明需要认证的原因及其好处。此外，请记住，不是每个使用你的应用程序的人从一开始就有一个账户。确保你解释清楚了如何注册，或者提供了简单注册方式。
显示合适的键盘来最简化数据输入。例如，当询问电子邮件地址时，显示电子邮件键盘屏幕，其中包括有用的数据资料快捷输入方式。
永远不要使用“密码”这个术语。当生物身份验证被禁用时，才把密码用于解锁用户的iOS设备或苹果支付认证
Apple Pay认证设计指导，请参阅 Apple Pay。
3.1 Face ID和Touch ID
只要可能，支持生物认证。Face ID和Touch ID是人们信任的安全、熟悉的身份验证方法。如果用户启用了生物特征认证，您可以认为他们理解了它的工作原理，喜欢它的便利，并希望尽可能地使用它。请记住，用户可能会选择在他们的设备上禁用生物特征认证，因此你的应用程序也应该准备好处理这种情况。
提供给用户单一的认证方法。当用户不必选择如何进行身份验证时是最直观的。只给他们一个单一的选项，比如Face ID。只有初始方法失败时，才提供其他选项，比如请求用户名和密码。
仅在响应用户操作时启动认证。比如点击按钮的明显操作，确保用户想要进行身份验证。在启用Face ID的情况下，这也增加了用户面对摄像头的可能性。
始终确定认证方法。例如，使用Face ID登录到你的应用程序的按钮应该被命名为“Face ID登录”而不是“登录”。
引用准确认证方法。不要在支持Face ID的设备上引用Touch ID，相反，也不要在支持Touch ID的设备上引用Face ID。检查设备的性能，并使用合适的术语。开发指导请参阅LABiometryType。
一般情况下，避免在你的应用程序中提供选择生物认证的设置。如果在系统级别启用了生物认证，那么就认为用户想要使用它。如果您在应用程序中提供了特定设置，用户可能会有在你的应用中能使用生物认证，但在系统层面实际不能使用的状态。
不要使用图标来识别系统认证功能。当用户看到像系统的Touch ID (指纹)和Face ID图标的图标时，他们认为应该进行身份验证。使用图标来识别身份验证特性会造成不一致性，并导致混淆，特别是当图标被着色，用大尺寸展示，并脱离上下文时。
开发指导请参阅Local Authentication。
四、Data Entry（数据录入）
无论是轻按界面元素还是使用键盘，输入信息都是一个冗长乏味的过程。当一个应用程序未体现任何价值之前，就要求用户大量的输入而减慢了这个过程，用户会很快气馁，甚至可能完全放弃这个应用。
在合理情况下，提供选项。使数据录入尽可能高效。例如，考虑使用选择器或表，而不是文本字段，因为从预定义选项列表中选择比键入响应更容易。
尽可能从系统中获取信息。不要强迫用户提供可以自动收集或用户权限允许下可以收集到的信息，比如联系人或日历信息。
提供合理的默认值。在可能的范围内，用最有可能的值预填充字段。提供良好的默认值可以使决策选择最简化并加快进程。
仅仅在收集到必要数据后才能进行升级。在启用“下一步”或“继续”按钮之前，确保所有必需的字段都有数值。启用这个按钮作为可进行下一步的视觉提示。
动态验证字段值。当填完一份冗长的表格后还必须回去改正错误，这会很令人沮丧。只要有可能，在输入后立即检查字段值，这样用户就可以马上更正它们。
只有在必要时才需要字段值。只在必要的情况下使用必需的字段。
通过值列表轻松导航。尤其在表格和选择器中，选择一个值应该是很容易的。考虑按字母顺序或以另一种逻辑方式排序值列表，以便快速扫描和选择。
在文本输入框中显示提示以帮助用户理解。当文本输入框中没有其他文本时，文本框可以包含占位符文本，如“电子邮件”或“密码”。使用占位符文本空间充足时，不要使用单独的标签来描述文本输入框。
五、Drag and Drop（拖放）
用一个手指将照片、文本或其他内容从一个位置拖到另一个位置，随后抬起手指完成拖放——用户可通过这一操作移动或复制选定内容。
触摸并按住选中内容会使它看起来在上升并粘附在用户的手指上。当内容被拖动时，动画和视觉线索识别可能的目的地。系统同时会显示何时不能拖放、或将导致复制内容而不是移动内容的标记。开发指导请参阅 Drag and Drop 和 UIKit。
5.1 来源和目的地
拖拽和拖放涉及将选中内容从源位置移动到目的地。这些位置可以在同一个容器中，比如文本视图，也可以在不同的容器中，比如在分屏视图的两端的文本视图。例如，在备忘录中，用户可以将选定的文本拖动到同一个备忘录中的新位置。在提醒事项中，用户可以将个人提醒从一个列表中拖出来，并将其放入另一个列表中。
在iPad上，源和目的地的位置也可以存在于不同的应用程序中，这就使得能跨应用程序交互，比如从Safari的网页拖出一张照片到一个新的邮件。拖动内容时，用户可以通过多任务处理、退出到主屏幕或从屏幕底部向上滑动来显示Dock，从而访问另一个应用程序。
注意：在应用程序之间拖放内容总是导致内容重复，而不是移动。
5.2 支持拖放
拖放有直观高效的特性，用户期望在整个系统中普遍实现。如果你的应用程序包含产生文本、照片、视频、音频或其他用户想要移动、复制或插入的内容，那应该支持拖放。
对所有可选择和可编辑的内容可进行拖放。可选择的内容应该是可拖放的，可编辑的内容也应该接受拖放。还要确保你的应用程序支持在这些区域复制粘贴。
允许内容在适当的时候被拖放。一般来说，能数据输入或选择(比如文本字段)的配置控件可以拖放内容。
尽可能使用标准文本视图和文本字段。这些系统提供的元素包括对拖放的内置支持。有关指南，请参阅 Text Fields和 Text Views。发者指南请参阅 UITextField 和 UITextView。
为了提高效率，考虑支持多项目拖放。在许多应用程序中，用户可以在用一个手指拖动一个项目时，用另一个手指通过点击选择其他项目，选中的项目移动到一起，并显示在拖动原始项目的手指下方。然后，用户将这些项拖放到一个组中，将它们放在想要的位置。例如，主屏幕允许选择多个应用程序图标，并将其拖放到一个文件夹中。像照片等应用程序，提供了一种可在拖放前选择多个项目的选择模式。
确定在应用程序中拖放内容是否会导致移动或复制。一般来说，当源容器和目标容器是相同的(在文档中拖动文本)时导致内容移动，而当它们不同(在文档之间或应用程序之间拖动)时导致内容复制。然而，情况并非总是如此。最重要的是，拖放应该是直观的。在提醒事项中，在列表之间拖动提醒会移动它们而不是复制它们，因为这是用户所期望的。而在应用程序之间拖放内容通常会造成复制。
尽可能让用户能取消拖放。通常，当用户无意中拖放内容到错误目的地时，他们应该能够使用“撤销”将您的应用程序返回到之前的状态。也就是说，拖放的内容应该被清除，而如果内容是从你的应用程序的其他地方转移来的，将它修复到原始位置。
考虑启用弹簧加载。在弹簧加载下，用户可以通过拖动选定的内容到某些控件上，并在不放下内容的情况下短暂暂停，从而激活这些控件，比如按钮和分段控件。例如，在邮件中，可以将选定的消息拖到导航栏的“返回”按钮上，以到达邮箱层次结构中的其他位置。永远不要使弹簧加载成为激活控件的唯一方法，只把它当作能被发现的点缀。在大多数情况下，弹簧负载控制也应该响应点击手势。开发指导请参阅UISpringLoadedInteraction。
5.3 提供拖放内容
根据需要自定义拖动项预览。一般来说，在用户手指下显示的预览应该是被拖动内容的半透明显示。预览外观提供了情景，显示拖放正在进行中，并使用户能看到拖放内容下面的目的地。
尽可能提供多个拖放数据的表现形式，从高到低依次排序。例如，在提供line art时，您的应用程序可以按照以下顺序，提供一个PDF矢量表示，一个具有透明度的无损PNG图像，以及一个没有透明度的有损的JPEG图像。这样，终端可以选择可导入的最高质量表示。
在适用时，将自定义对象的本地版本作为最丰富的数据形式。例如，一个可以让人们拖动图表的应用程序应该首先呈现本地图表对象。然后，它应该为那些不支持图表对象的应用提供可替代的图像版本。
当内容转移到您的应用程序是消耗时间的或资源密集时，实现文件提供程序扩展（Implement a file provider extension）。文件提供程序扩展管理传输过程并确保它完成，即使您的应用程序不再运行。注意，直到用户完成拖放内容，传输过程才开始。开发指导请查阅NSFileProviderExtension。
需要时间进行应用程序的内容传输时，提供进度信息。如果内容必须下载或大文件需要时间复制，提供进度信息。至少，提供内容的总大小，以便终端计算剩余的时间，并显示合适的进度指示器。开发指导请查阅 NSProgress。
5.4 接受拖放内容
使用视觉提示来识别潜在的目的地，并预览拖放内容的效果。突出显示、插入点指示器和动画都是确定潜在目的地的好方法。当内容被拖到视图上时，视图可以巧妙地闪动并改变颜色，或者段落可以移开来为一个被拖动的图像腾出空间。当屏幕上有多个可能的目标时，一次识别一个。如果源容器和目标容器是相同的，那么突出显示可能是不必要的，除非内容被完全地从源容器中拖出并且重新输入。当内容被放下或不再位于目的地之上时，确保清除高亮显示。
在适当时自动滚动目的地内容。当内容被拖到目的地的边界之外时，您的应用程序可能需要决定是滚动目的地的内容还是允许用户继续拖动到完全不同的目的地。如果您的应用程序允许用户继续拖动，考虑定义一个区域，当拖动的项位于它上面时，该区域会自动滚动。例如，当内容被拖到正文区域的顶部或底部时，邮件中冗长的消息草稿会自动滚动。标准文本视图和文本字段自动采用这种行为。
提取和显示拖放内容最丰富的表现形式。例如，您的应用程序可能会被提供几个图表的表现形式，如果您的应用程序支持图表，它可以提取并显示本机图表对象。如果你的应用程序不支持图表，它可以提取并显示图表的图像版本。
适当只提取拖放内容的相关部分。例如，若用户在邮件信息中拖放联系人到收件人框中，只使用名称和电子邮件地址，而不提取联系人的地址信息。
拖放内容后，在表视图和集合视图中显示占位符。临时占位符显示内容在完成传输后驻留的位置。
当拖放内容需要时间传输时显示进度。默认情况下，当应用程序之间发生耗时的传输时，系统会显示一个app-modal alert（应用程序模式警报）。考虑自定义显示进程的方式，比如在表视图或集合视图中显示占位符的进度指示器，这样用户就不会被阻止使用你的应用程序。注意，直到用户完成拖放内容，传输过程才开始。
当拖放内容启动一个进程时，提供反馈。如果用户将内容拖放到发起任务的控件上，例如，将视频上传到共享站点，显示任务已经开始，并让用户知道其进度。
拖放失败时通知用户。如果无法插入拖放内容，可能是因为文件传输中断，通知用户拖放未成功。
应用适当的样式拖放文本。当源和目的地支持相同样式的文本属性时，拖放文本应该保持其原始字体、字样、大小和其他属性。否则，拖放的文本应该采用目的地的样式。
在用户不能立即撤销拖放时，考虑提供一种微妙又直观的方式撤退。例如，共享应用程序可能会在发布拖放内容之前提供中间共享表单。这个共享表单可以通过一种方式提供如状态消息等附加内容，同时还提供一个取消按钮。当照片被拖动到共享照片流中时，也会如此显示。