iOS 11 設計規範 | 第三章 用戶交互（User Interaction）

3.1 3D Touch

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）。例如，在郵件中，選擇的消息可以被拖動到導航欄的 Back 按鈕上，以到達郵箱里的其他位置。永遠不要讓彈簧載入成為激活控制項的唯一方法。把它當作一種可以被發現的小驚喜。在大多數情況下，一個彈簧載入的控制項也應該可以響應一個點擊手勢。

了解更多開發者指導，請參閱 UISpringLoadedInteraction 。

Providing Dragged Content 提供可拖動的內容

可以自定義拖動項的預覽：通常，在用戶手指下顯示被拖動的預覽效果應該是半透明內容，表明拖動正在進行中，並使用戶能夠看到被拖動內容下面的目的地。

儘可能的提供多個拖拽數據的顯示類型，從高保真到低保真排序：例如，當提供線條稿時，你的 App 可以按照順序依次提供一個PDF矢量顯示，一個具有透明度的無損 PNG 圖像，以及一個沒有透明度的有損的 JPEG 圖像。 這樣，用戶就可以選擇最高質量的顯示來導入到目的地。

將自定義對象的本地版本作為最豐富的數據形式：例如，一個允許人們拖拽圖表的 App 應該首先顯示本地的圖表對象。然後，它應該為那些不支持圖表對象的 App 提供可替代的圖像版本。

當你 App 的內容傳輸會比較耗費時間或資源密集的時候，文件要提供程序擴展（extension）功能：文件提供程序擴展，並確保完成，即使你的 App 不再運行也能做到。請注意，只有用戶放下內容後傳輸才會開始。

了解更多開發者指導，請參閱 NSFileProviderExtension 。

當你的 App 需要時間傳輸內容時請提供進度指示：如果內容需要下載或大文件需要時間複製時，請提供進度信息。至少提供內容的總大小，這樣就可以計算出剩餘的時間，並顯示恰當的進度指示器。

了解更多開發者指導，請參閱 NSProgress 。

Accepting Dropped Content 接收放下的內容

使用視覺提示來識別潛在目的地，並預覽放置內容的效果：高亮顯示、插入點游標和動畫都是識別目的地的好方法。當內容被拖過來時，視圖可以微妙地閃爍並改變顏色，或者段落可以分開為拖動的圖像騰出空間。當屏幕上有多個可能的目的地時，一次只識別一個。如果原位置和目標容器是相同的，那麼可以不需要高亮顯示，除非內容完全從原位置中拖出來，然後重新進入。當內容被放下時或不再位於目的地之上時，確保不顯示高亮。

自動滾動目的地的內容：當內容被拖到目的地的邊界之外時，你的 App 可能需要判斷滾動顯示當前視圖遮擋的內容，或者允許用戶繼續拖動到完全不同的目的地。如果你的 App 讓用戶進行滾動拖放，那就定義一個區域，當拖拽的項目被放置在上面時，這個區域會自動滾動。例如，當內容被拖到正文區域的頂部或底部時，郵件中的長草稿會自動滾動。標準文本視圖和輸入框會自動採用這種方式。

提取和展示要能展現出放置的豐富內容：例如，你的 App 可以為一個圖表提供的幾種表現形式。如果你的 App 支持圖表，它可以提取並顯示出原始圖表對象。如果你的 App 不支持圖表，它可以提取並顯示圖表的圖像版本。

只提取放置內容的相關部分：例如，如果用戶想將某個聯繫人拖到郵件的收件人中，只需提取名稱和電子郵件即可，而不用聯繫人的地址信息。

當內容放置後，在表視圖和精選視圖中顯示佔位符：佔位符會暫時指示當內容完成傳輸後，將停留在哪裡。

在放置內容需要時間進行傳輸時顯示進度：默認情況下，當 App 程序之間發生耗時的轉移時，系統會顯示一個 App 模式警報。可以使用自定義進程的顯示方式，比如在表視圖或集合視圖中顯示佔位符的進度指示器，這樣就不會阻止用戶使用你的 App 了。請注意，只有用戶放下內容後傳輸才會開始。

為放置的內容啟動一個進程時提供反饋：如果用戶將內容放置到發起任務的一個控制項上，例如，將視頻上傳至共享站點，就會顯示任務已經開始並通知用戶其進度。

放置失敗時通知用戶：如果放置的內容不能插入，可能是因為文件傳輸中斷，要通知用戶放置內容失敗。

用適當的樣式來放置文本：當原位置和目的地支持相同樣式的文本屬性時，放置的文本應該保留其原始字體、字型、大小和其他屬性。否則，放置文本應該採用目的地的樣式。

提供一種直觀的方式，當用戶不能立即撤銷拖放時，可以選擇退出：例如，一個分享性的 App 會在放下內容之前提供一個中間的附加表。這個附加表可以用來提供其他內容，比如狀態消息（譯者註：如內容數量和大小），同時還提供一個取消按鍵。當照片被拖進共享的照片流時， App 就顯示了這種方式。

3.6 Feedback

反饋

反饋讓用戶知道 App 現在在做什麼，發現他們下一步應該做什麼，並且了解操作的結果。

將狀態和其他類型的反饋整合到你的界面中：理想情況下，用戶可以在不操作或不被打擾的情況下獲得重要信息。例如，郵件在通過郵件箱導航時，巧妙地顯示了工具欄中的狀態信息。這些信息不會和屏幕上的主要內容搶風頭，但用戶可以在任何時候快速瀏覽。

避免不必要的警報框：警報框是一種強大的反饋機制，但應該只用於傳遞重要的信息。如果用戶看到太多包含無關緊要信息的警報框，他們很快就會學會忽略以後的警報。

了解更多指導，請參閱 Alerts 。

Haptic Feedback 觸覺反饋

觸覺技術為用戶提供了一種身體接觸的觸覺反饋，從而獲得用戶關注並強化他們的操作。系統提供的一些界面元素，例如選擇器、開關和滑塊，在用戶與它們交互時會自動提供觸覺反饋。你的 App 還可以讓系統生成不同類型的觸覺反饋。 iOS 管理著這種反饋的強度和操作。

成功：指示一個任務或動作已完成，如存放支票或解鎖車輛。

請謹慎使用觸覺反饋：過度使用會引起認知混亂並降低反饋的重要性。

一般來說，觸覺反饋是為了響應用戶發起的操作：用戶很容易將觸覺與他們所發起的操作聯繫起來。隨意的反饋會讓用戶感到不連貫，以及造成誤解。

不要重新定義反饋類型：為確保用戶有一致的體驗，請按照預期使用反饋類型。例如，不要使用 「衝突性」（impact）反饋來通知用戶一個任務已經完成。而應該是使用「通知」反饋來表示「成功」的變化。

調整好給用戶觸覺反饋的視覺體驗：提供視覺和觸覺的反饋，以在操作和結果之間建立更深的聯繫。確保動畫是清晰準確的，在視覺上符合用戶的感受。

不要依賴單一的交流方式：並不是所有的設備都支持全方位的觸覺反饋，如果可以選擇的話，用戶完全可以在設置中禁用該功能。此外，只有當設備激活，而你的 App 是在當前頁面時，觸覺反饋才會發生。通過視覺和聽覺的提示來補充觸覺，以確保重要信息不會被遺漏。

當視覺反饋被遮擋時，用戶可以使用觸覺：比如將一個對象拖到屏幕上的某個位置，被用戶的手指遮住了。這時候生成反饋，讓用戶知道何時到達特定的位置。

在開始反饋之前，確認系統已準備就緒：因為在提供觸覺反饋時可能會有一些延遲，所以最好在請求反饋之前確認系統已提前載入。否則，觸覺反饋可能有很長的延時，導致用戶感覺他們的操作與屏幕上看到的東西沒有聯繫。

同步觸覺和音效：觸覺不會自動與聲音同步。如果你想使用音效的話，要讓它和觸覺同步。

了解更多開發者指導，請參閱 Animation and Haptics 。

3.7 File Handling

文件處理

用戶在創建、查看和操作文件時不用考慮文件系統。如果你的App需要運行文件時，儘可能地減少文件處理的時間。

讓用戶相信文件即時保存，除非主動取消或刪除：一般來說，不要讓用戶去即時保存文件。相反，在用戶打開和關閉文件，以及切換到另一個 App 程序時，會定期自動地保存更改。在某些情況下，例如在編輯現有文件時，保存和取消選項可能仍然是有意義的，因為它們可以幫助確認何時編輯的內容已經被保存。

不要提供創建本地文件的選項：用戶通常希望所有的文件都可以在他們的所有設備上使用。只要有可能，你的 App 就應該通過 iCloud 等服務來支持雲文件存儲。

設計一個直觀的圖形文件瀏覽界面：理想情況下，使用用戶熟悉的系統文檔應用來瀏覽。如果你設計了一個自定義的文件瀏覽器，請確保它是直觀且高效的。文件瀏覽器在高度圖形化的情況下運行得最好，也提供了文件的可視化展示。為了高效引導用戶，可以考慮提供一個新的文檔按鍵，這樣用戶就不必去其他地方創建新文檔了。

讓用戶在不離開 App 程序的情況下預覽文件：你可以使用 Quick Look 功能讓用戶查看來自 Keynote、Numbers 和 Pages 的內容，以及 PDF 文檔、圖片或某些其它格式的文件，即使你的 App 並沒有真正打開它們。

請參閱 Quick Look 。

與其他App共享文件：如果可以的話，你的 App 可以通過文檔的擴展功能（ document provider extension ）與其他 App 共享文件。也可以讓用戶瀏覽和打開其他 App 的文件。

了解更多開發者指導，請參閱 Document Picker Programming Guide 。

3.8 Gestures

手勢

用戶通過在觸摸屏上使用手勢來與 iOS 設備交互。操作手勢與內容產生了緊密的個人聯繫，增強了對屏幕的直接操縱感。

一般使用標準操作手勢：用戶熟悉了標準的手勢，就不喜歡被迫學習不同的方法來做相同的事。在遊戲和某些沉浸式App中，自定義手勢是這種體驗的樂趣之一。在一般 App 中，最好使用標準的手勢（standard gestures），這樣用戶就不用費力去發現或記住它們了。

避免使用標準手勢執行非標準操作：除非你的 App 是一個極具可玩性的遊戲，否則重新定義標準手勢會變得混亂和複雜。

不要禁用系統的屏幕邊緣手勢：除了標準的手勢之外，一些額外的手勢還可以調用全局操作，比如在屏幕的邊緣通過滑動屏幕來顯示主屏幕(在支持的 iphone 上)、控制中心、通知中心和Dock (在 iPad 上)。用戶依靠這些手勢來操作每一個 App 程序。在極少情況下，像遊戲這樣的沉浸式 App 可能需要自定義的屏幕邊緣手勢，這些手勢優先於系統的手勢操作——第一次滑動調用此 App 的自定義手勢功能，而第二次則調用系統手勢。這種行為(被稱為邊緣保護)應該要盡量避免，因為這會使得用戶難以訪問系統操作。

基於界面的導航和操作提供補充性的快捷手勢，而不是替換：只要有可能，提供一種簡單、直觀的方法來引導或執行操作，即使這意味著需要額外的點擊。許多的系統 App 提供了清晰可點的返回上一頁的按鈕的導航欄。但用戶也可以通過從屏幕的一側滑動來返回。在 iPad 上，用戶可以按下 Home 鍵退出到主屏幕，或是使用四指捏合的手勢。

使用多點手勢來增強 App 的體驗：雖然涉及多個手指同時操作的手勢不適用於每一個 App，但是他們能夠豐富一些 App 的體驗，譬如遊戲和繪圖 App。例如，一個遊戲可能包含多個屏幕控制，比如操縱桿和發射按鈕，就可以同時進行操作。

了解更多開發者指導，請參閱 UIGestureRecognizer 。

Standard Gestures 標準手勢

用戶通常期望以下的標準手勢在整個系統和每個 App 程序中都是相同的。

• 點擊：激活一個控制項或者選擇一個對象。
• 拖拽：讓一個元素從一邊移動到另一邊，或者在屏幕內拖動元素。

• 滑動：快速滾動或平移。
• 橫掃：單指返回上一頁，顯示分屏視圖中的隱藏視圖，滑出列錶行中的刪除按鈕，或在輕按顯示操作列表。在 iPad 中四指操作用來切換 App。

• 雙擊：放大並居中內容或圖片，或者縮小已放大過的。
• 捏合：向外張開時放大，向內捏合時縮小。

• 長按：當在可編輯或可選文本中執行時，顯示用於游標定位的放大視圖。在某些與集合視圖類似的視圖中操作，進入對象可編輯的狀態。
• 搖晃：撤銷或重做。

3.9 Near Field Communication

NFC 近場通信技術

NFC 使設備能夠在幾厘米的範圍內進行無線信息交換。在支持此項功能的設備上運行 iOS App，可以使用 NFC 掃描來讀取現實世界相關的電子標籤上的數據。例如，用戶可以掃描一個玩具來連接視頻遊戲，購物者可以掃描店內的標誌來拿到優惠券，或者零售員工可以掃描產品來跟蹤庫存。一個 App 可以支持單個或多個對象的掃描，當用戶需要掃描某件東西時，系統會彈出一個掃描表。

不鼓勵用戶接觸物理對象：要掃描標籤，iOS 設備只需簡單地靠近標籤，而不需要觸碰。當要求用戶掃描對象時，使用「掃描」和「靠近」等術語，而不是「點擊」和「觸碰」。

使用通俗易懂的術語：一些人可能不熟悉 NFC 這個概念。為了讓它變得通俗易懂，應避免提及技術上的、面向開發者的術語，比如核心 NFC 、近場通信、NFC 和標籤。相反，要使用大多數人都能明白的友好會話式的術語。

應該這樣不應該這樣請掃描【對象名稱】請掃描 NFC 標籤請把你的 iPhone 靠近【對象名稱】以了解更多。請使用 NFC 掃描，點擊手機上的【對象】

為掃描提供簡潔的指導說明：提供完整的帶有結束標點符號的句子。確定要掃描的對象，並適當地修改文本以便進行後續掃描。保持文本簡短，避免截斷。

第一次掃描後續掃描把你的 iPhone 靠近【對象名稱】以了解更多。現在，把你的iPhone 靠近另一個【對象名稱】

了解更多開發者指導，請參閱 Core NFC 。

3.10 Undo and Redo

撤銷和重做

許多 App 允許用戶通過搖晃設備來撤銷和重做某些操作，比如打字或刪除。當以這種方式啟動時，會出現一個警告框提示用戶確認或取消撤銷（重做）。

簡要描述一下將要撤消或重做的操作：撤銷和重做的警告提示框標題會自動地包含「撤銷」或是「重做」這樣的前綴（以及後面的空格）。你需要在前綴後面提供額外的一兩個詞語用來描述什麼會被撤銷或是重做。例如，你可以創建警告提示，例如「撤銷名稱」或「重做地址更改」。

如果你已經使用搖晃手勢進行撤銷和重做，則不要將其用於其他操作：儘管你可以通過編程方式給搖晃手勢賦予多種功能，但卻冒著讓用戶困惑的風險，這樣就會讓你的 App 更難用。

節制地使用撤銷和重做按鈕：當 App 提供多種方法來執行相同的任務時，會讓用戶感到困惑。如果你的 App 真的需要專有的撤銷和重做按鈕，請使用標準系統提供的圖標，並將它們放在一個預期的位置，比如導航欄中。

只在當前情境中執行撤銷和重做操作：撤銷和重做必須對當前的（而非之前的）情境有明確直接的影響。

了解更多開發者指導，請參閱 Undo Architecture 。