「接手」保安
Apple 安全地處理原生 App 和網站之間的接手，無論是從一台裝置到另一台裝置，甚至是大量資料的接手。
「接手」如何安全運作
當用户的 iOS、iPadOS 和 macOS 裝置彼此接近時，用户可以使用「接手」功能，自動將正在處理的內容從一部裝置傳送到另一部裝置。用户可以使用「接手」功能來切換裝置並立即繼續操作。
當用户在第二部支援「接手」功能的裝置上登入 iCloud 時，兩部裝置會透過 APNs 來建立頻外低耗電藍牙（BLE）4.2 配對。每則訊息的加密方式類似於 iMessage 中的訊息。裝置配對後，每部裝置都會產生對稱的 256 位元 AES 密鑰，並儲存在裝置的鑰匙圈中。此密鑰可加密和認證 BLE 廣播，其會在 GCM 模式下使用 AES256 並採用重播保護措施，將裝置目前的活動傳遞給其他已配對的 iCloud 裝置。
裝置首次接收到來自新密鑰的廣播時，會建立與起始裝置之間的 BLE 連線，並執行廣播加密密鑰的交換。此連線使用標準的 BLE 4.2 加密方式以及將個別訊息加密的方式（與 iMessage 的加密方式類似）來進行保護。在部份情況下，這些訊息會使用 APNs 而不是使用 BLE 傳送。活動的承載資料會使用與 iMessage 相同的方式進行保護和傳輸。
在原生 App 和網站之間使用「接手」功能
「接手」功能允許 iOS、iPadOS 或 macOS 的原生 App 繼續用户在由 App 開發者合法控制之網域中網頁的活動。「接手」也允許原生 App 的用户活動在網頁瀏覽器繼續進行。
為協助阻止原生 App 要求繼續取用非受開發者控制的網站，App 必須證明擁有要繼續取用的網域之合法控制權。對網站網域的控制是使用共用網頁憑證的機制來建立。如需詳細資料，請參閲：App 對已儲存密碼的存取權限。在允許 App 接受使用「接手」功能的用户活動前，系統必須驗證 App 的網域名稱控制。
使用「接手」功能傳送的網頁來源可以是任何採用了「接手」API 的瀏覽器。當用户檢視網頁時，系統會使用加密的「接手」廣播位元組來廣播網頁的網域名稱。只有用户的其他裝置能夠解密該廣播位元組。
在接收裝置上，系統會偵測到已安裝的原生 App 接受了來自已廣播網域名稱的「接手」，並將該原生 App 圖像顯示為「接手」選項。啟動後，原生 App 會接收完整的 URL 和網頁標題。瀏覽器中的其他資料則不會傳送到原生 App。
相反地，如「接手」接收裝置未安裝相同的原生 App，原生 App 可指定後援 URL。在此情況下，系統會將用户的預設瀏覽器顯示為「接手」App 選項（如該瀏覽器已採用「接手」API）。要求使用「接手」時，系統會啟動瀏覽器並接收來源 App 提供的後援 URL。後援 URL 並不一定要限制為由原生 App 開發者控制的網域名稱。
使用「接手」傳送較龐大的資料
除了使用「接手」的基本功能外，部份 App 可能會選擇使用支援傳送大量資料的 API（透過 Apple 建立的點對點 Wi-Fi 技術，與 AirDrop 非常類似）。例如，「郵件」App 會使用這些 API 來支援接手功能，以傳送可能包含較大附件的郵件草稿。
當 App 使用這些 API 時，兩部裝置間會開始交換，如同使用「接手」傳送一樣。不過，在使用低耗電藍牙（BLE）收到初始承載資料後，接收裝置會透過 Wi-Fi 來啟用新的連線。此連線是加密的（使用 TLS），其透過「iCloud 鑰匙圈」共享的身份獲得信任。證書中的識別標誌會針對每位用户的身份進行驗證。其他承載資料會透過此加密的連線進行傳送，直到傳輸完成為止。
通用剪貼板
「通用剪貼板」運用「接手」安全地跨裝置傳送用户的剪貼板內容，因此他們可以在一部裝置上複製並在另一部裝置貼上。剪貼板內容會如其他「接手」資料一樣受到保護，並依照預設與「通用剪貼板」分享，除非 App 開發者選擇不允許分享。
無論用户是否已將剪貼板內容貼至 App 中，App 皆可取用剪貼板資料。透過「通用剪貼板」，此資料存取權限會延伸至用户在其他裝置上執行的 App（必須以 iCloud 登入裝置來建立此存取權限）。