3D Touch 为触控交互提供了一个全新的维度。用户可以在支持的设备中，通过不同力度按压屏幕来访问额外的功能。App 会通过展示菜单、显示额外内容、播放动画等方式来进行反馈。使用 3D Touch 功能不需要学习新的交互手势，只要轻轻按压屏幕就可以轻易发现额外的内容。

Home Screen Interaction 主屏交互

在主屏幕中，你可以通过按压一个支持 3D Touch 的 App 图标来显示动作面板。这个面板可以让你快速执行 App 程序中的常见任务或查看有趣的信息。例如，日历 App 就提供了 “创建事件” 的快捷方式，还显示了你的 “日程安排” 中的下一个事件。

关于设计指导，请参阅 Home Screen Actions 和 Widgets 。

Peek and Pop轻按和重压

轻按可以让用户使用 3D Touch 预览一项内容，例如页面、链接或者文件，预览窗口处于页面内容的最前端。只需用手指轻按就能预览，而抬起手指就能退出预览。如想要查看更多信息，只需重压，直到预览窗口弹出并充满整个屏幕即可。在一些预览窗口中，你可以向上滑动来显示相关的操作按钮。例如，在浏览 Safari 中的网页时，你可以向上滑动屏幕，实现在 “新标签页中打开”，“加入阅读列表” 和 “拷贝” 这三个操作。

轻按可以提供实时的、内容丰富的预览效果: 在理想的情况下，预览窗口是为了给当前的页面提供补充信息，或者帮助你决定是否打开该页面。例如，先预览一下邮件中的链接，再决定是否在Safari中打开或与朋友 共享此链接。轻触还可以 App 在可被点击的列表中，通过预览补充信息来决定是否选择该行。

设计足够大的轻按视图: 需要设计足够大的预览视图，使手指不会遮挡住内容。并且用户通过视图包含的信息来决定，是否应该重压打开完整项目。

轻按和重压要保证场景的一致性: 如果你在相同类型的元素中有些地方支持轻按和重压，在其它元素中不支持（译者注：比如同一个列表中第一个选项支持 3D Touch 功能，而第二个选项却不支持），用户就会对在什么地方可以使用这个功能产生混乱，或者认为你的 App 还是他们的设备发生了故障。

避免在轻按视图中显示按钮式元素: 如果这时用户抬起手指来点击面板中看起来像按钮的元素，那么轻按就会消失。

允许每个轻按视图都能被重压: 尽管轻按视图能提供给人用户所需的大部分信息，但如果他们决定直接离开当前页面，直达该页面时，那么轻按也应该能转换成重压。重压展示出的内容也应该和点击该页面时一样。

不要让同一元素具备轻按和编辑菜单两个功能: 当一个项目都启用两个功能时，不但会让用户感到困惑，也会让系统难以判断用户的意图。

了解更多的指导，请参阅 Edit Menus。

适时提供操作按钮: 并不是每个轻按都需要操作按钮，但这是一个为常见任务提供便捷入口的好方法。如果你的 App 已经为该项目提供了自定义的触控操作，那么在最好在轻按中也加入同样的操作。

避免加上一个操作按钮来打开轻按界面: 用户一般都通过更用力的按压来打开他们轻按的项目。所以，没有必要再提供一个明显的打开按钮。

不要让轻按成为唯一能执行动作的操作: 并不是所有设备都支持轻按和重压，甚至有的用户会关闭 3D Touch 功能。你的 App 应该考虑到其它触发操作的方式。比如，你的 App 也可以通过点击和长按时出现的轻按视图。

Live Photos 动态照片

App可以支持动态照片，按压照片可以用来查看动态的照片，包含动作和声音来再现拍照时前后的片刻。

了解相关设计指导，请参阅 Live Photos 。

3.2 Audio

音频

用户通过音量键、静音键、耳机声控和屏幕上的音量调节滑块控制声音。很多第三方配件也有声控功能。音频可以通过内部或外部扬声器、耳机输出，甚至通过支持 AirPlay 或是蓝牙的设备来无线输出。无论声音是你 App 的重要功能还只是一个点缀，你都应该知道用户对声音有什么期待并且去满足他们。

Silence 静音

用户将他们的设备调至静音来避免被突发的声响（比如电话铃声和短信提示声）打扰。他们也想要关闭没有意义的声音，包括按键声、音效、游戏背景音乐以及其它音频反馈。当设备被设置成静音后，只能播放用户确认打开过的声音，比如媒体播放中的声音、闹钟、音频和视频信息。

Volume 声音

无论是使用设备按键或是屏幕中的滑块，用户都期望音量的变化会改变整个系统音量，包括音乐声和 App 内的音效。但是提示铃声音量是例外，它只能在音频没有播放的情况下，被单独调节。

Headphones 耳机

在私密环境中，用户使用耳机听声音，并且能够解放双手。当插入耳机时，用户希望声音能够自动继续播放而不被中断。当拔掉耳机时，他们希望播放能够立即暂停。

Designing a Great Audio Experience 设计良好的音效体验

有时自动调整音量，但不是总体音量：你的 App 可以调整特定的音量来达到很棒的音响效果。但是最终的音量还是由系统音量来控制。

可以允许重置音频: 用户经常会想要选择一个不同的音频输出设备。比如，他们会想要用客厅的立体音响、车载收音机或是苹果电视来听音乐。请支持这个功能除非你有十足的理由不这么做。

使用系统自带的音量窗口来调节音量: 音量窗口是调整音频的最好方法。这个窗口是可以自定义的，它包括一个音量的滑块，甚至还包括了一个重置音频输出的控件。

了解开发者指导，请参阅 MPVolumeView。

使用系统自带音效来实现短音和振动:

了解开发者指导，请参阅 System Sound Services 。

如果声音对你的 App 十分重要，请先设置音频类型: 不同的音频类型中，有的允许声音被静音键静音、有的与其它声音混合、或是允许 App 在后台时播放。根据不同的类别和当前设备的音频状态来选择合适的方案，然后将其配置到你的音频中去。例如，非必要情况下，请不要打断用户正在收听的来自另一个 App 的音乐。总之，当你的 App 在运行时，最好不要改变其原有类型，当然那种需要录制和重放不同时间音频的 App 除外。

了解开发者指导，请参阅 Audio Session Programming Guide 。

适当时可以重新播放被打断的音频：有时正在播放的音频会被另一个 App 的音频中断。暂时性中断（如来电铃声）被认为是可恢复的。永久中断（如 Siri 打开的音乐播放列表）被认为是无法恢复的。当一个可恢复的中断发生时，你的 APP 应该在中断结束时自动重新播放被打断的音频。例如,一个正在播放配乐的游戏和一个播放音频的多媒体 App 都应该可以恢复播放。

让其他 App 知道何时将暂时性的音频播放完毕：如果你的 App 可能会暂时中断其他 App 的音频，它应该对音频会话进行适当的标记，这样其他 App 就能知道何时可以安全的恢复。

了解开发者指导，请参阅 AVFoundation 中的 AVAudioSessionSetActiveOptionNotifyOthersOnDeactivation 。

只在特定时间对声音控件有反应：不管你的 App 是在前台还是后台运行，用户可以从你 App 的外部控制音频播放，比如控制中心或耳机控制。如果你的 App 正在音频相关的环境中播放音频，或者连接到一个支持 AirPlay 的设备上，那么它可以对音频控制做出回应。否则，当控件激活时，你的 App 不能停止其他 App 正在播放的音频。

不要重新定义声音控件：人们希望音频控制在所有 App 中都能保持一致。永远不要重新定义声音控件。如果你的 App 不支持相应控件，那么它就不应该对它们做出响应。

3.3 Authentication

身份验证

可以通过让用户进行身份验证的条件来为他们提供有价值的服务，例如个性化体验、访问附加功能、购买内容或同步数据。如果你的App需要认证，那保持登录过程的快速、简单和自然，就不会让你的 App 的体验感变差。

将登陆尽量往后排序：当人们在做一些有用的事情之前被迫登录时，他们往往会放弃这样的 App。在强制用户登陆前给他们一个爱上你的 App 的机会。在购物 App 中，让用户可以在启动时能立即浏览你的商品，并且只有在他们准备好购买的时候才需要登录。在一个流媒体 App 中，也在登录前让用可以搜索你的内容，看看你的 App 能提供些什么。

解释身份验证的优点，以及如何注册：如果你的 App 需要验证，请在登录屏幕上展示简短友好的说明描述使用这个流程的原因及好处。另外，请记住，并不是所有使用你的 App 的人从一开始就有一个账户。确保你描述了如何获得一个账户，或者提供一个简单的 App 内的注册方式。

显示合适的键盘类型来减少数据输入：例如要求填写 Email 地址时，显示 Email 键盘屏幕，其中要包含常用数据输入的快捷键。

永远不要使用 “密钥” （passcode） 这个术语：当生物识别认证失效时，密钥是用于解锁用户的 iOS 设备，并与 Apple Pay 进行身份验证的。

了解有关 Apple Pay 验证设计指导，请参阅 Apple Pay 。

Face ID and Touch ID 脸部识别和触控

尽量让你的App支持生物识别认证：Face ID 和 Touch ID 是人们所信任的比较安全、熟悉的认证方法。如果用户启用了生物识别认证，你可以假设他们理解它的工作原理，喜欢这份便利，并且愿意随时使用它。请记住，用户可能会选择在他们的设备上禁用生物识别认证，因此你的 App 要准备好应对这种情况。

向用户展示一个简单的验证方法：当人们不必选择如何进行身份验证时，这是最直观的一种方法。给他们一个简单的选项，比如 Face ID，在初始方法失败时，请求用户名和密码，在返回刚才的操作。

仅在响应用户操作时启动用户认证：选择一些显眼且明确的操作指示，比如点击一个按钮，确认用户是想主动进行身份验证的。在 Face ID的情况下，它也提高了用户面对摄像头的可能性。

始终标识身份验证方法：例如，使用 Face ID 在你的 App 上登录的按钮，应该被命名为“用 Face ID 登录”，而不只是“登录”。

准确使用验证方法：不要在支持 Face ID 的设备上引用 Touch ID。同样，也不要在支持 Touch ID 的设备上引用 Face ID。要检查设备的功能并使用适当的术语。

了解有关开发者指导，请参阅 LABiometryType 。

总之，不要在你的 App 中提供选择生物识别身份验证的设置：如果在系统层面启用了生物识别身份验证，那么就假定用户想要使用它。如果你实现了一个 App 特定的设置，那么你的 App 会要求用户进行生物识别认证，但是实际上在系统范围内它是被禁用的。

不要使用自定义图标来标识系统身份验证功能：当用户看到类似 Touch ID(指纹)和 Face ID 的系统图标时，他们会以为要进行身份验证。而使用相同图形的自定义图标则会让用户产生混乱，尤其是当这些图标，变着颜色和大小，出现在不符的使用环境中，就像变成了一个按键，或者出现在 App 的设置上。

了解了解有关开发者指导，请参阅 Local Authentication 。

3.4 Data Entry

数据键入

无论是点击界面元素还是使用键盘，键入信息都是一个乏味的过程。当一款 App 还没有提供实际的帮助，就要求用户大量的键入内容，会导致进程变慢，用户就可能会很快失去耐心，甚至完全放弃这个 App 。

尽量显示选项：数据输入高效化。例如，考虑使用选择列表来代替打字，因为从提前设定好的选项中进行选择，要比打字容易多了。

尽可能的从系统中获取信息：不要强迫用户提供那些可以自动或是在用户许可内就能获取的信息，比如联系人或是日历信息。

提供合理的默认值：尽可能地预填可能性最大的信息值。提供准确的默认值可以进行快速决策。

只有在收集完必要的信息之后才能进行下一步：在启动“下一步”或“继续”按钮之前，确保所有需要的字段都有值。使用可视化按钮，提示用户可以继续进行下一步。

立刻验证填写信息：当你在填写完一份冗长的表格后，又不得不回到前面去纠正错误是让人十分沮丧的。尽可能在输入后立即检查字段值，这样用户就可以马上纠正它们（例如输入用户名后立马检查格式和是否被注册，而不需要在输入完密码后再一起验证）。

只有在必要时使用文本信息。只要在真正需要的信息，才使用字段表达。

将信息列表化以高效预览：在列表和集合中，选择一个选项是更容易的。考虑将信息列成表，以字母顺序排序或以另一种逻辑方式排序，从而可以快速扫视和选择（译者注：如商品类目以字母排序的方式在列表中展现出来）。

在文本框中显示提示，以助沟通：当字段中没有其他文本时，文本字段可以包含诸如“电子邮件”或“密码”之类的占位符文本。当占位符文本足以表述清楚的话，不要再使用单独的标签来进行描述。

3.5 Drag and Drop

拖放

只要一根手指，用户就可以将选定的照片、文本或其他内容，从一个位置拖到另一个位置来进行移动或复制，然后松开手指将其放下。

触摸并按住选择的内容使它看起来会上升并附着在用户的手指上。当内容被拖动时，动画和视觉提示要识别你想放置的位置。当无法放下，或着拖拽只能复制而不是移动时，该系统会显示别的标识来提醒用户。

请参阅 UIKit中的 Drag and Drop 。

Sources and Destinations 原位置和目的地

拖放包括将选中的内容从原位置转移到目的地。这些位置可以在同一集合中，如文本视图，或分屏模式下两端的文本视图。例如，在 Notes 中，用户可以将选中的文本拖到同一条笔记中的新位置。在 Reminders 中，用户可以将单个提醒从一个列表中拖出来，并将其放入另一个列表中。

在iPad上，原位置和目的地的位置也可以在不同的 App 中，从而产生跨 App 的交互，比如从 Safari 的网页中拖出一张照片到 Mail 里的新邮件中。在拖拽内容的同时，用户可以通过 multitasking （多任务处理）、退出到主屏幕或从屏幕底部向上滑动显示快捷键来访问另一个 App 。

请注意 在App程序之间拖放的内容是复制文件，而不是内容本身（译者注：即拖动只是将内容复制到另一个应用中而不是移动存储位置）。

Supporting Drag and Drop 支持拖放功能

拖放是一种高效的、直观的功能，用户期望在整个系统中都能实现。如果你的App包含或生成了文本，照片，视频，音频，或者其他用户想要移动，复制或插入的内容，你的App应该支持拖放功能。

所有可选择和可编辑的内容都能进行拖放：可选择的内容应该是可拖动的，可编辑的内容也是可以放置内容的。还要确保你的 App 能够支持在这些区域复制粘贴。

允许将内容放到控件上：总之，配置控件要支持数据输入或选择(比如文本字段)接受可放置的内容。

尽可能使用标准 文本视图和输入框：系统自带的这些组件都包含对拖放功能的原生支持。

了解更多相关指导，请参阅 Text Fields 和 Text Views 。

了解更多开发者指导，请参阅 UITextField 和 UITextView 。

为提高效率，考虑支持多项拖放：在很多 App 里，用户可以用一根手指拖动一个内容，同时用另一根手指轻敲其它内容，就会在选择的第一个内容的手指下方显示出堆叠效果。然后，用户可以将它们像组一样拖放到指定的位置。例如，主屏幕允许用户根据这个方法选中多个 App 程序图标，并将其拖放到一个文件夹中。在 APP 中，如 “照片”，提供了用户可以在拖拽之前选择多个对象的选择模式。

确定在你的 App 中拖放内容是移动还是复制：一般来说，当原位置和目的地的载体是相同时(在文档中拖动文本)，才可以移动，而当它们不同时(在文档之间或 App 程序之间进行拖动)，则使用复制。当然，情况并非总是如此，重点是拖放应该是直观的。在 “提醒” 中，列表之间拖动操作是一种移动而不是复制，因为这是用户想要的。而在 App 程序之间拖放内容就总是复制了。

用户是应该可以撤销拖放的：通常情况下，当用户无意中将内容放到错误的位置时，他们应该能够使用撤销来将App返回到之前的状态。也就是说，被放置的内容可以被移除，如果被放置的内容是从你的App程序里移出的，那么它应该恢复到原来的位置。

考虑用一下弹簧加载（spring loding）：有了弹簧加载，用户可以通过拖动已选择的内容，并在不放置的情况下暂停，来激活某些控件，比如按钮和分栏组件（segmented controls）。例如，在邮件中，选择