「告別跳轉」：Linq 助攻 iMessage 變身超級應用，支付、遊戲、訂票一站搞定

你是否曾在使用通訊軟體時，為了完成某項任務（例如付款、預訂機票或玩遊戲），卻被迫跳轉到另一個應用程式或網頁瀏覽器？這種中斷的體驗，不僅耗時，也可能讓使用者感到不便。現在，訊息基礎設施新創公司 Linq 正透過其創新的 iMessage Apps 功能，徹底改變這一切，讓蘋果 iMessage 搖身一變成為一個能處理複雜工作流程的「超級應用」。

過去，開發者或代理人主要透過發送連結來引導用戶前往其他平台完成操作。然而，Linq 的 imessage_app 部分（part）徹底消除了這種「交接」的必要。它允許開發者直接在 iMessage 對話氣泡中，嵌入可點擊、互動的迷你應用程式。這意味著，用戶從購物、玩遊戲、預訂航班到支付款項，所有環節都能在不離開 iMessage 對話的情況下完成，無需任何深層連結（deep link）到外部瀏覽器，也無需點擊「點此在應用程式中完成」的提示。

iMessage Apps 如何運作？

從技術層面來看，iMessage App 是一個可點擊的卡片，能在原地開啟互動體驗。這張卡片本質上就是你的應用程式，直接運行在訊息氣泡內部。它是一種新的訊息部分，類型為 "imessage_app"，取代了傳統的文字、媒體和連結部分。當收件人安裝了你的訊息擴充功能（Messages extension），它就能從你提供的 URL 中繪製出豐富的互動內容。

Linq 作為提供此 API 的訊息基礎設施新創公司，其平台讓 AI 代理程式能夠透過 iMessage、RCS 和 SMS 與用戶溝通。要讓 iMessage App 卡片正確呈現，有幾個關鍵細節需要注意：

• 應用程式身份是渲染的關鍵： 應用程式物件會攜帶 team_id 和 bundle_id 欄位，這些欄位會告知 Messages 應用程式應該使用哪個擴充功能來渲染卡片。team_id 是應用程式的 10 個字元大寫識別碼。如果 team_id 和 bundle_id 與已安裝的擴充功能不符，卡片將會靜默地退化為純文字的標題，而不會拋出錯誤訊息。
• 開發者控制標題，應用程式控制圖片： 卡片上顯示的文字內容由 layout 物件控制，而照片、圖示和互動式使用者介面則來自你的擴充功能。至少需要設定一個欄位，否則卡片將呈現為空白氣泡。
• 互動旗標控制即時與靜態體驗： interactive 旗標預設為 true。當設定為 true 時，已安裝應用程式的收件人將看到即時的互動卡片。若設定為 false，則始終顯示靜態的佈局卡片。

結合應用程式的安裝狀態和 interactive 旗標，會產生三種不同的結果：

1. 已安裝應用程式，interactive: true： 擴充功能從你的 URL 渲染出豐富的互動卡片。
2. 已安裝應用程式，interactive: false： 收件人看到靜態的佈局卡片。
3. 未安裝應用程式： 收件人只看到你設定的佈局標題。你可以設定 app_store_id 來提供「取得應用程式」的提示。

發送與更新互動卡片

發送卡片可以透過建立新聊天（Create Chat）或將其發布到現有聊天（Send Message）來實現。更具創新性的是「原地更新」功能。已發送的卡片可以透過引用原始訊息來原地替換內容。這項功能對於需要即時狀態變化的應用場景至關重要，例如在遊戲中，每一步棋的移動都能即時更新棋盤畫面，而無需發送新的訊息。

更新卡片時，只有 url、fallback_text、interactive 和 layout 可以改變，應用程式身份在卡片的生命週期內保持固定。每次更新都會作為一條新訊息傳送，並帶有新的訊息 ID。值得注意的是，interactive 旗標不會被繼承，因此每次更新都需要重新發送。

iMessage Apps 的廣泛應用潛力

Linq 描繪了 iMessage Apps 的多種應用場景，這些都展示了其將 iMessage 轉變為多功能平台的潛力：

• 遊戲： 玩家可以發送一個動作，然後棋盤會立即更新。一場即時比賽可以透過對單一訊息氣泡的連續更新來進行。
• 支付： 將結帳或付款請求作為卡片發送。收件人無需重新導向即可完成支付。
• 票務： 一張卡片可以從「參加/不參加」的選項，原地更新為已確認的門票。
• 航班預訂： 顯示票價，讓用戶選擇座位，然後將卡片更新為登機證。
• 音樂： 投放一首歌曲，讓用戶在對話中直接播放。這張卡片是一個播放器，而不是一個連結。
• 約會： 讓用戶在他們已經聊天的環境中滑動瀏覽個人資料並探索匹配對象。

iMessage Apps 與其他訊息部分的權衡

imessage_app 部分以犧牲觸及率來換取互動性。以下表格展示了這種權衡：

功能	imessage_app	text (文字)	media (媒體)	link (富連結)
在氣泡內互動	是	否	否	否
原地更新	是 (透過 /update)	否	否	否
由誰繪製	你的 Messages 擴充功能	Messages	Messages	Messages
未安裝應用程式可見	僅標題	總是	總是	總是
可退化為 SMS 或 RCS	否	是	是	是
可與其他部分結合	否 (必須是唯一部分)	是	是	是

從表格中可以看出，如果你的目標是讓所有收件人都能看到圖片，那麼使用媒體或富連結會是更好的選擇，因為它們服務於不同的目的。iMessage Apps 的核心優勢在於其「原地互動」和「原地更新」的能力，這使得複雜的多步驟工作流程得以在通訊軟體內無縫進行。

優勢與挑戰

Linq 的 iMessage Apps 帶來了顯著的優勢：

• 原地更新： 將單一卡片轉變為有狀態、多步驟的工作流程。
• 無縫體驗： 互動式工作流程在對話串中運行，無需瀏覽器重新導向。
• 簡潔的 API： API 介面小巧，主要包含發送、更新和接收，以及網路掛鉤（webhooks）。
• 優雅的退化機制： 對於未安裝應用程式的收件人，標題提供了優雅且可預測的退化顯示。

然而，這項技術也面臨一些挑戰：

• iMessage 限定： 僅限 iMessage 平台，不支援 SMS 或 RCS 退化，這限制了其全球觸及率。
• 依賴應用程式安裝： 豐富的渲染效果取決於收件人是否安裝了你的 Messages 擴充功能。
• 靜默的錯誤模式： team_id 和 bundle_id 不匹配時會靜默退化為純文字，而非明確的錯誤提示，這可能增加開發者的除錯難度。
• 平台風險： 建立在蘋果的平台上，必然伴隨著一般的平台風險。

總體而言，Linq 的 iMessage Apps 為開發者提供了一個強大的新工具，可以在 iMessage 生態系統中創造更豐富、更整合的使用者體驗。儘管存在一些限制，但其將複雜任務直接帶入對話氣泡的能力，無疑為對話式商務和應用程式的未來開闢了新的可能性。