HIG iOS 翻譯 App Architecture｜App架構
App Architecture App架構
Launching 啟動
Onboarding 初次造訪
Loading 讀取
Modality
Navigation 瀏覽、導覽
Accessing User Data and Resources 存取使用者數據與資源
Settings 設定
Requesting Permission 要求權限（原文已刪除）Launching 啟動
啟動體驗會對使用者對App的感受產生重大影響。不論人們使用的設備或距離上次打開App有多久，啟動體驗應感到快速且無縫
以下指南可以幫助你設計愉快的啟動體驗。開發者指南請參閱Responding to the Launch of Your App
提供啟動頁面 系統在你的App啟動時顯示啟動頁面。啟動頁面的功能意在給予App的第一印象，在啟動內容讀取時感到快速且反應靈敏。為確保從你的啟動頁面無縫的轉換，設計類似App中第一個畫面的素面頁面，且不會吸引太多注意。更多指南請參閱Launch Screen
在適當方向啟動 若App支援垂直及水平方向，啟動畫面應呼應當前方向。若App只支援單一方向，應以該方向啟動畫面，只在必要狀況下才旋轉畫面。除非有令人信服的理由，水平模式中的App應自行旋轉，不論裝置是否左轉或右轉。相關指南請參閱Adaptivity and Layout
避免要求設定訊息 使用者多數只預期App運作。為多數人設計App，並為少數需要更多調整設定之使用者提供進階設定。盡可能地從裝置設定和預設設定中獲取設定資訊，或透過同步服務，如iCloud。如果您一定要要求設定，在App提供第一次提示，並讓用戶稍後可以在您的應用設定中對進行修改
避免顯示App內許可協議、免責聲明 在App Store中顯示許可協議、免責聲明，若必定要顯示資訊，整合資訊在App中，避免打斷使用者體驗
重開App時顯示上次使用畫面 別讓使用者重複步驟以到達先前位置，保留並恢復使用者上次離開之畫面
不鼓勵重啟 重新啟動耗費時間且使你的產品另人感到不信任。若非記憶體或其他問題，別重啟App
別太著急或頻繁要求使用者評價 太快或太經常地要求評價令人厭惡且減少有意義的回饋。給予使用者時間建構意見。永遠提供意見回饋管道，不強迫使用者評價
Onboarding 初次造訪
Onboarding是新使用者第一次造訪或者使用者回歸的畫面。快速、有趣、具教學性的Onboarding可以幫助人們避免遇到問題
提供幫助人們使用App的Onboarding，而非只是設定好 人們期望了解更多關於App，但同時他們也可能只期望它可以運作。避免在Onboarding安排設定或協議細節。相關說明請參閱Launching
快速採取行動 在App畫面取代啟動畫面後，立即讓人們進入並使用App。如果你需要提供教學或介紹，提供可以跳過的方法且不會再次向使用者展示
預備幫助 主動地尋找可能卡住的點。例如遊戲，當角色沒有在前進或暫停時提供隨機的提示。若使用者錯過某些教學，提供重播
教學中的要點 為初學者提供教學很棒，但它無法取代好的設計。若提供太多冗長的必要教學，需重新審視App的設計
有趣且可探索的教學 比起條列式教學，在過程中學習更有趣、更有效。搭配動畫、互動進行教學，避免顯示靜態的螢幕截圖
Loading 讀取
當內容讀取時，空白或靜止的畫面讓你的App看起來像是當機，將造成使用者的困惑且可能會離開
清楚地顯示讀取狀態 至少要顯示Activity Spinner以表示讀取狀態。更好的方法，顯示明確的進度讓人們估計等待時間
盡快顯示內容 不要讓人們看到內容前等待內容讀取。立即顯示畫面，並使用佔位符、圖像或動畫來表示還不可用的內容。當內容讀取完成時取代佔位符。盡可能在背景預載接續的內容，例如在播放動畫或使用者在瀏覽選單時
用教學或有趣的內容來填滿等待讀取的時間 考慮在遊戲中顯示提示、娛樂的影片片段、有趣的佔位圖像
客製讀取畫面 雖然標準的進度指示器已足夠，有時它讓人感到格格不入。考慮以自訂動畫和元素來設計更沉浸的體驗以搭配你的App風格
相關說明請參閱Progress Indicators
Modality
Modal獨立顯示臨時內容和當前狀態分開，在明確動作後退出。顯示Modal內容可以：
- 幫助使用者專注於單一畫面或多個關聯選項
- 確保使用者接收，必要時顯示緊要訊息
iOS提供Alerts、 Activity Views（或 Share sheets）、 Action sheets使用
Sheet
Sheet顯示如卡片的外觀，覆蓋部分下方內容、使其他未覆蓋內容變暗以避免互動。當卡片打開時人們可以透過前個畫面可見的頂部部分來回想剛才暫停的畫面。以下列方法離開sheet：
- 從螢幕最上方往下滑
- 當卡片正往上滾動時從任何位置往下滑
- 點擊離開按鈕
在不含複雜工作的非沉浸式Modal使用Sheet
Fullscreen 全螢幕
全螢幕呈現覆蓋整個螢幕的畫面，先前的畫面會被完全覆蓋，最少化的視覺干擾，人們點擊按鈕來離開
在沉浸式內容使用全螢幕Modal View，例如：影片、照片、相機、複雜工作如標注文件、編輯相片
注意
若你在分割顯示、Popover、或其他非全螢幕中的當前Modal View顯示Modal內容，你應當在窄環境中顯示Modal內容轉換為Sheet合理使用Modal 只在需要使用者專注於當前動作（如做出選擇、執行任務）使用Modal。Modal將帶使用者離開當前語境，需一個供離開之動作，因此只在明確需要時使用Modal
使用Alert以傳達重要且可操作的訊息 因為Alert打斷使用體驗、需要點擊以離開，通常Alert只出現在發生錯誤，讓使用者了解此Alert的必要性非常重要。相關說明請參閱Alerts
保持Modal簡潔俐落 避免在App中建立App。若Modal太過複雜，使用者極可能失去方向。謹慎建立Modal及階層，避免使用者忘記如何回溯上一步。若Modal中包含子視圖，在階層中提供完整的單一路徑。避免在任務完成以外的情況下使用“完成”按鈕
務必在Modal中保留Dismiss按鈕 例如，使用“完成”或是“取消”以確保Modal提供輔助技術及離開的方式
必要時，在使用者關閉Modal前進行確認，以避免資料遺失 不論使用者是否使用離開按鈕，若動作將導致使用者產生的內容遺失，提供Sheet來說明並提供解決方法
不要將Card顯示於Popover之上 雖然可以在Popover中顯示Card，除了Alert之外不應在Popover顯示其他物件。在少數情況中，你必須在人們Popover採取動作後顯示卡片，在顯示卡片前關閉Popover
顯示足以辨識Modal內容的標題 當人們從前一個頁面轉換進入Modal，足夠的說明表達新的頁面很好。你必須提供文字以充分的描述或提供導引
整合Modal和App 例如，Modal中包含Navigation bar，應使用和App中的Navigation bar相同的外觀
合理的使用Modal過換風格 使用相同過換風格於App中並增強對臨時頁面轉換的認知。預設的轉換方式，Modal從螢幕底部垂直上滑；在離開時垂直下滑。在整個App中使用一致的Modal轉換
Navigation 瀏覽、導覽
人們往往不會意識到App的Navigation直到遇見不如預期。你的工作是建立支援不引人注意之架構及目標的Navigation。Navigation應當得宜自然，不應壓迫內容或吸引目光，在iOS中有三種主要Navigation樣式
- Hierarchical Navigation 階層式
- Flat Navigation 扁平式
- Content-Driven or Experience-Driven Navigation 內容、經驗導向
Hierarchical Navigation 在每個頁面做一次決定以達到目的地，回溯步驟或從頭開始以達到其他目的地，Setting和Mail使用此種Navigation
Flat Navigation 在多種內容種類切換，如Music和App Store
Content-Driven or Experience-Driven Navigation 在頁面間自由移動，或由內容自定義Navigation，如Books、遊戲、沈浸式App。某些App合併多種Navigation樣式。例如App以Flat Navigation啟用每個種類中的Hierarchical Navigation
提供明確路徑 使用者必須知曉自身在App中的位置、如何到達目的地。不論Navigation樣式，路徑必須合乎邏輯、可預測、易於遵循。一般來說，每個頁面皆透過一個路徑到達，若需要在畫面中看多個Context，考慮使用Action Sheet、Alert、Popover、Modal。檢視Action Sheets、Alerts、Popovers、Modality來了解更多
建立簡單快速獲得內容的資訊架構 以最少的點擊、滑動、頁面來組織資訊架構
使用流暢的觸控手勢 以最少的摩擦使得穿梭介面變得簡單。例如：從邊緣滑動來回到上一頁
使用標準Navigation Components 盡可能使用標準Navigation Component，如Page Control、Tab Bars、Segmented Controls、Table Views、Collection Views、Spilt Views。使用者已熟悉以上操作並直覺的使用
以Navigation Bar瀏覽階層性資料 Navigation標題可以顯示階層中的當前位置，返回按鈕將容易的回到上一頁面。特定說明請參閱Naviigation Bars
使用Tab Bar瀏覽同等級的類別或功能 讓使用者快速地切換類別，無論當前位置為何。特定說明請參閱Tab Bars
在多個相同樣式內容的頁面使用Page Control Page Control清楚顯示多個頁面，以及當前頁面，如天氣App使用Page Control演示特定地區頁面。特定說明請參閱Page Controls
提示
Segmented controls和Toolbars無法應用於Navigation。Segmented control將資訊組織在不同分類。Toolbar提供與當前頁面的操作。關於這些元素的更多資訊請參閱Segmented Controls和ToolbarsAccessing User Data and Resources 存取使用者數據與資源
使用者隱私權非常重要。為了讓使用者對於App感到信任，關於隱私相關的數據、資源的使用方式應保持透明且關重要且。例如，你必須先請求存取：
- 個人資訊包括位置、健康、財務、聯絡資料和其它個人身份訊息
- 個人產出內容如Email、訊息、行事曆資料、聯絡資料、遊戲資訊、Apple Music活動、HomKit數據及影音相片內容
- 受保護的資源如藍芽連接設備、居家自動功能、Wi-Fi連接、區域網路
- 裝置功能如相機及麥克風
要點
在iOS14.5及iPadOS14.5之後，如果需要追蹤或存取設備的廣告識別碼*¹你必須以AppTrackingTransparency framework來請求使用者的允許當你提交新的App或更新項目，必須提供關於隱私條例、隱私相關數據的細節，而App Store將在你的產品頁面顯示該資訊。（任何時候你都可以在App Store Connect管理資訊）使用者將以產品頁的隱私權細節來決定是否下載App。更多訊息請參閱App privacy details on the App Store。
Requesting Access Permission 請求存取權限
在你能夠使用使用者數據或受保護的資源前，你必須獲取使用者的允許。
當你的App對數據及資源有明確需求時才請求權限 使用者很自然地會對請求個人資訊或存取裝置功能產生猜疑，特別是沒有明顯需求時。理想情況，等待使用者確切需要使用某些App功能時才請求允許。關於位置請求，使用位置按鈕來分享他們的即時位置；相關指南請參閱Using the Location Button。
只在App功能需要數據或資源啟動時才請求權限 當App有明顯需求時，人們不太會因為在App啟用時被請求允許而感到困擾。如果您想在人們啟動您的應用程序後立即追蹤，您必須在收集任何追蹤數據之前顯示系統提供的Alert
系統提供標準Alert，讓人們檢視向隱私資訊或受保護資源存取的請求。你提供一段敘述闡明為何App需要這些，系統將在Alert中顯示敘述。人們也可以在「設定」>「隱私權」中檢視你的敘述及更新他們的選擇。
清楚撰寫你如何使用這些數據和資源。在顯示App名稱後、允許或拒絕請求的按鈕前，標準Alert將顯示你的說明（稱為 目的字符串 或 用法描述字串）。簡短而完整的句子直接了當、易於理解。使用句子、避免被動語態、在句尾寫上句號。更多開發者指南請參閱Requesting Access to Protected Resources和App Tracking Transparency.
Ｏ
範例目標字串：App將在夜間偵測打呼聲並錄音
提示：主動句清楚描述App如何級為什麼收集數據
Ｘ
範例目標字串：存取麥克風已獲得更加體驗
提示：被動句提供模糊、未定義的理由
Ｘ
範例目標字串：開啟麥克風連接
提示：祈使句未提供任何理由
這裡有幾個標準系統Alert的範例：
使用位置按鈕
在iOS15之後，Core Location提供按鈕，讓人們允許你在作業程序需要時暫時存取他們的位置。儘管位置按鈕的外觀可因App的 UI 而有不同樣式，但始終以可立即識別的方式表現位置分享的設計。
位置按鈕令你的App請求暫時存取裝置位置。若你的App沒有授權狀態，當使用者在標準Alert選擇 允許一次 時，點擊位置按鈕有相同效果。若先前使用者已經選擇 允許在使用App時存取 ，點擊位置按鈕不會改變App狀態。開發者指南請參閱LocationButton (SwiftUI)和CLLocationButton (Swift)
The first time people open your app and tap a location button, the system displays a standard alert. The alert helps people understand how using the button limits your app’s access to their location, and reminds them of the location indicator that appears when sharing starts.
系統在使用者第一次打開App並點擊位置按鈕時顯示標準Alert。Alert幫助人們理解如何限制你的App存取他們的位置，並在開始分享位置時以位置指示器*²提醒他們。
在人們了解按鈕動作後確認，他們只需要點擊位置按鈕即可一次性授權App使用他們的位置。雖然授權將在每一次關閉App後失效，他們不需要再次確認對於按鈕所致行為的理解
考慮以位置按鈕提供人們簡單的方式分享位置來使用App功能。例如，你的App能夠幫助人們連結位置來傳送訊息、貼文、找尋店家或識別該位置的建築、動植物。若你知道人們經常授權App 允許一次 的選擇，考慮使用位置按鈕而非Alert。
考慮設計與你的UI相符的位置按鈕。具體來說，你可以：
- 使用與你的App功能最相應的系統提供文字，例如“現在位置”或“分享我的即時位置”
- 使用填滿或框線的字符*³
- 為標題文字與字符使用背景顏色
- 調整按鈕邊角圓角
為了讓人們記得並信任位置按鈕，其他視覺元素無法客製。系統也會警告提醒你確保位置按鈕的易讀性，像是低對比色彩或是太多半透明。除了修正這些問題外，你需要確保文字符合按鈕，例如，按鈕文字在所有所有輔助功能的字級大小或是其他語言的翻譯時將符合長度不會被截斷。
重要 系統將會識別客製位置按鈕的一致性問題，當人們點擊時並不會連接設備位置。雖然這樣的按鈕能夠啟動App特定操作，若你的位置按鈕沒有如預期運作，人們可能會對App失去信任。在ShazamKit App中使用麥克風
ShazamKit將透過聲音樣本與ShazamKit目錄或自訂音效目錄識別。在iOS15之後，App可以以ShazamKit來使用功能如：
- 透過與播放音樂種類相應的圖像來增強使用體驗
- 透過與聲音同步的隱藏式字幕或手語，讓聽力障礙者也可以看見內容
- 將App體驗與線上學習和零售等等的虛擬內容同步
若你需要裝置麥克風來取得聲音樣本以識別，你必須請求允許來使用。就像所有請求權限一樣，讓人們了解為何要求存取非常重要，相關指南請參閱Requesting Access Permission
在你收到允許連接麥克風之後即可啟用ShazamKit，遵循以下指引。
適當錄音 當人們允許你的App錄音來識別，他們不會預期麥克風一直保持錄音。為保障隱私，只錄音你所需要的長度
give people a way to first approve this action. Even though both the Music Recognition control and the Shazam app show your app as the source of the recognized song, people appreciate having control over which apps can store content in their library.
讓人們選擇將識別結果的歌曲儲存在iCloud資料庫 若你的App能將識別的歌曲儲存於iCloud，提供在第一次操作此動作的方法。儘管Music和Shazam都將您的App顯示為已識別歌曲的來源，人們仍希望由自己控制哪些App可以在資料庫中儲存內容
更多開發者指南請參閱ShazamKit
在Alert之前顯示自訂訊息
理想情況，基於使用情境，人們已經知道為何你會請求允許，但如果有必要提供額外細節，你可以在Alert出現前顯示自訂訊息。
明確表示跳出系統Alert是人們可以在您的自訂訊息畫面中的唯一可執行的操作。人們可以理解以事先提醒作為拖延，讓自訂訊息可以快速略過並檢視系統Alert。如果你將自訂畫面置於隱私相關請求之前，必須提供唯一動作來顯示系統Alert。在按鈕使用文字“繼續”；不要使用“允許”或其他文字，可能會讓人們以為他們在你的自訂畫面中授予他們的權限或執行其他操作。
闡明追蹤請求
App追蹤是個敏感的問題。某些情況下，顯示自訂訊息清楚描述追蹤的好處是合理的
切勿在系統提供Alert之前顯示困惑的、誤導的自訂訊息。有時候人們僅僅只是沒有閱讀文字而略過Alert。利用此類行為影響選擇的自訂訊息畫面將導致App Store審核拒絕。
There are several prohibited custom-messaging designs that will cause rejection. Some examples are offering incentives, displaying a screen that looks like a request, displaying an image of the alert, and annotating the screen behind the alert (shown below). For guidance, see
這裡有幾個被禁止的自訂訊息範例。某些範例提供獎勵、顯示和請求相似的畫面、顯示Alert圖像、在Alert後方註解（如下）。相關指南請參閱App Store Review Guidelines: 5.1.1 (iv)
提供獎勵 不要為了獲得權限提供獎勵。你不能為了許可而提供補償，且你不能在人們允許追蹤前隱藏功能或讓App無法使用
仿製請求 不要顯示模仿系統Alert的自訂訊息。特別是，不要在按鈕上顯示“允許”或類似話語，人們無法在預警畫面下允許任何權限
Alert圖像 不要顯示標準Alert的圖像或以任何形式修改它
Alert註解 不要設計視覺指引，將人們引導至“允許”按鈕
Settings 設定
部分的App都需要提供設定或組織性的選擇，但大多數的App都避免或延後跳出設定的時間。成功的App在人們正確使用下良好的運作，也提供方便調整的體驗。在設計符合人們期待的App時減少對設定的需求
從系統功能推斷所需資訊 若你需要使用者資訊、設備或環境，盡可能先詢問系統而非向使用者要求。例如，避免使用者自行輸入郵遞區號，你可以顯示本地選項，要求存取位置的許可。若使用者拒絕則以手動方式輸入
App中的第一個設定選擇必須審慎思考 App中的主要畫面是放置最重要或經常調整選項的地方，次要畫面適合放置偶爾調整之設定
在Setting中顯示較少使用調整設定 Setting App是系統中提供結構調整的中心，而你的使用者必須離開App來到Setting，在App中調整設定比起轉移至Setting方便許多。若非常需要提供極少設定之需求，請參閱開發者指南Preferences and Settings Programming Guide中的Implementing an iOS Settings Bundle
適時的提供至設定App的快捷 若你的App中提供文字指引如：打開設定>我的App>隱私權>位置服務。提供快捷按鈕直接連接至該設定頁面。開發者指南請參閱UIApplication中的openSettingsURLString
Requesting Permission 要求權限
（原文已刪除）
使用者必須允許要求程式才得以存取個人資訊，包括 現在位置、行事曆、聯絡資訊、提醒事項、照片。雖然使用者期待方便的連接資訊以使用App，他們也預期能掌控自身隱私。例如，人們希望能自動在照片中標記位置、找尋附近的朋友，但他們也能選擇不使用這些功能。
在有確切需求下才要求個人資料 要求權限必然引人疑惑，特別是在沒有明確需要的情況。確保要求權限只出現在使用特定功能時。例如，在啟動定位追蹤功能時才要求存取現在位置
解釋為何需要這些資料 提供文字說明解釋目的、描述用途，顯示在系統的要求權限Alert中並包含範例。文字精簡且具體，使用Sentence Case、禮貌且嚴謹的文字。無需包含App名稱 — — 系統已辨認你的App。開發者指南請參閱Protecting the User’s Privacy
Ｏ App將在您夜間時段偵測打呼聲並錄音
Ｘ 打開麥克風以獲得更加體驗
Ｘ 打開麥克風權限
只在有App功能性需求時才要求權限 使用者不會因為要求正當存取權限而感到困擾。
別在非必要時要求存取位置資訊 在索取位置資訊前確認系統位置服務是否已啟用。獲得訊息後，你可以延後要求權限在有特定功能需要時，或者也許能完全免去Alert。如何啟動位置功能請參閱Mapkit和Location and Maps Programming Guide
使用系統提供的Alert 你可以在標準Alert中自訂說明，避免增加超出Alert功能或外觀的提示
*¹ 廣告識別碼：Advertising identifier
*² 位置指示器：Location Indicator
*³ 字符：Glyph下一篇
上一篇
