Apple 就藐視法庭裁定向最高法院提起上訴？App 與 Web 支付路由解析

Apple 是否會就 Epic 藐視法庭裁定在最高法院面臨挑戰？2026 年 9 月 14 日，Apple 向美國最高法院遞交了 Apple Inc. v. Epic Games, Inc. (案號 25-1311) 的開庭陳述書，請求高等法院撤銷或廢除針對其「防規避」(anti-steering) 合規架構的民事藐視法庭判決。此上訴重點不在於重新審理 2021 年的反壟斷判決，而是聚焦於司法藐視權的程序限制：特別是第九巡迴法院是否在未依據禁制令明確條文，僅憑「精神」層面即裁定當事人藐視法庭，是否屬於判決錯誤。對於行動軟體架構師、計費工程師及使用者獲取團隊而言，這場關於 App-to-Web 支付路由 的法律糾紛具有重大的架構參考意義。隨著開發者部署外部支付流程以提供標準 App 內購買 (IAP) 以外的替代付費機制，工程團隊必須設計具備韌性的雙向路由管道，提供可靠的返回上下文處理，讓原生 App 能透過通用連結 (Universal Links) 從後端計費服務重新獲取權威的交易狀態。

最高法院上訴：藐視法庭權與 75 字禁制令

最高法院審理的爭點在於根據《聯邦民事訴訟規則》第 65(d) 條及聯邦衡平法既定判例，實施民事藐視法庭處分所需的法律標準。

2021 年 9 月，美國加州北區地方法院裁定，Apple 在聯邦反壟斷法下並非非法壟斷者，但認定其禁止導流的開發者指南因造成資訊損害，違反了加州的《不公平競爭法》(UCL)。為糾正該違規行為，地方法院發佈了一項 75 字的永久禁制令，禁止 Apple 阻止開發者在 App 中加入「除了 App 內購買以外，引導客戶使用購買機制的按鈕、外部連結或其他號召性用語 (CTA)」。

重點摘要

• 最高法院陳述書已遞交：2026 年 9 月 14 日，Apple 就 Apple Inc. v. Epic Games, Inc. (案號 25-1311) 遞交了調卷令申請後的開場陳述書，挑戰第九巡迴法院將禁制令的「精神」作為正當化藐視法庭裁決的作法。
• 核心問題：最高法院僅就問題 1 批准審理：當禁制令未明確規定相關行為時，民事藐視是否能僅基於禁制令未述明的「目的」？或者藐視法庭是否必須依據「無合理疑慮」的既定標準 (Taggart v. Lorenzen) 提供明確通知？
• 操作觸發點：藐視法庭的爭議源於 Apple 2024 年 1 月的合規計畫，該計畫允許外部購買連結，但針對七天內的導流交易收取 12% 至 27% 的佣金，並規範了按鈕的呈現方式。
• 上訴法院處置：第九巡迴法院以「精神」準則肯定了藐視法庭的裁定，但撤銷了地方法院對導流佣金的永久禁令，並發回重審費用事宜。儘管地方法院的重審程序仍在進行，Apple 的上訴旨在徹底撤銷藐視法庭判決及其隨附的發回重審指示。

據 MacRumors 與 AppleInsider 的報導，由 Latham & Watkins 律師事務所的 Gregory G. Garre 所撰寫的 Apple 陳述書主張，最初的 75 字禁制令並未針對導流佣金及特定按鈕樣式做出規範。Apple 已取消對導流的全面禁止，建立了「外部購買連結」(External Purchase Link) 指南，並允許開發者加入外部連結。當 Epic 對佣金與設計要求提出質疑時，下級法院認定 Apple 藐視法庭，理由是其作法阻礙了該判決所追求的競爭目標。

Apple 辯稱，將民事藐視脫離明確的文字命令，違反了第 65(d) 條的明確性要求，並剝奪了受規管方獲得公平通知的權利。根據官方 最高法院案卷，Epic Games 預計將於 2026 年 11 月 13 日遞交回應書，口頭辯論時間將由法院定於 2027 年進行。

Epic v. Apple 反規避訴訟時程表

建構 App-to-Web 支付迴圈

無論最高法院如何解決民事藐視的程序界限，工程組織面臨的現實已然確立：開發者可以實施外部購買連結，將使用者引導至 Web 結帳頁面。然而，執行此移交過程需要區分商店特定的架構與行動 Web 結帳工程的通用需求。

商店架構：美國政策 vs. 地區性 StoreKit 外部購買框架

常見的架構誤區是認為所有外部支付連結都依賴相同的系統 API。開發者必須根據商店所在地區與適用的計畫來解耦實作方式：

• 美國商店架構：根據 2021 年的禁制令，Apple App Store 審核指南允許美國商店內的 App 包含引導使用者至 IAP 以外購買機制的按鈕、外部連結或其他 CTA，且無需使用專門的「StoreKit 外部購買連結權限」(StoreKit External Purchase Link Entitlement)。商業條款、級別評估及報告機制仍由適用的開發者協議規範。
• 地區性 StoreKit 外部購買框架：在美國境外，實作模型因司法管轄區與 Apple 計畫而異。某些商店（如特定的歐洲經濟區或俄羅斯的外部連結計畫）使用特定的 StoreKit 權限，呼叫 ExternalPurchaseLink.open() 時會顯示續接畫面，並將 Apple 產生的外部購買權杖 (token) 附加到 URL 以供稽核。其他司法管轄區與計畫（如南韓的替代付費或歐盟不斷演進的商業條款）採用不同的 StoreKit API、通知畫面與報告管道。此外，Apple 已宣佈歐盟將於 2026 年 10 月 1 日過渡至統一的商業條款，這意味著開發者在實作時，必須根據其適用的商店與協議來評估權限、API、佣金與報告需求。

建構雙向 Web 結帳迴圈

下方的架構展示了一個由商戶設計的通用外部連結流程。在受專門平台計畫規範的商店中，若有必要，區域專屬的 StoreKit API 可能會取代或包裝出站傳送步驟。

1. 出站瀏覽器導引：應用程式呈現符合資格的 CTA 或連結按鈕。當使用者互動時，App 使用標準系統處理器（或區域權限 API 所規定的 StoreKit 畫面）發送外部 URL。應用程式附加一個不透明、短期的結帳會話參考（例如 https://checkout.example.com/pay?session_ref=chk_99182）以連結使用者的意圖。敏感個人資料或原始帳號憑證絕不能以明文形式放在 URL 查詢字串中。
2. Web 端交易處理：Web 支付閘道接收會話參考，處理客戶身份驗證，並透過外部支付服務供應商（例如 Stripe 或 Adyen）執行支付流程。
3. 商戶後端確認：一旦外部處理器確認支付，商戶後端會在授權資料庫中標記訂單為已履行，並記錄完成收據。
4. 入站返回導覽（通用連結）：支付完成後，Web 完成頁面會提供或發起返回原生 App 的流程，使用經驗證的 Apple 通用連結 (Universal Links)（例如 https://checkout.example.com/payment-complete?order_ref=ord_8812）。
5. 裝置端場景處理與權限更新：作業系統攔截 HTTPS 通用連結，並透過 scene(_:continue:) 或 scene(_:willConnectTo:options:) 將負載傳遞給 UIWindowSceneDelegate。原生應用程式解析不透明的訂單參考，透過驗證過的 API 查詢其後端以核實交易所有權，並相應地更新使用者權限。

+-------------------------------------------------------------------------+
|                  雙向 APP-TO-WEB 支付管道架構                           |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 原生 iOS App: 使用者選擇外部購買選項 ]                                |
|         |                                                               |
|         |-- (透過 UIApplication.shared.open 發送出站連結)              |
|         v                                                               |
|  [ Safari / 預設網頁瀏覽器: 開啟結帳入口網站 ]                          |
|  URL: https://checkout.example.com/pay?session_ref=CHK_99182            |
|         |                                                               |
|         v                                                               |
|  [ Web 支付閘道: 處理外部交易 ]                                         |
|         |                                                               |
|         |-- (商戶後端確認支付並記錄收據)                                |
|         v                                                               |
|  [ Web 完成頁面: 發起驗證後的通用連結返回流程 ]                         |
|  URL: https://checkout.example.com/payment-complete?order_ref=ORD_8812  |
|         |                                                               |
|         v                                                               |
|  [ iOS 攔截 HTTPS 網域關聯 (已驗證 AASA) ]                              |
|         |                                                               |
|         +---------------------------------------+                       |
|         | (App 在記憶體執行)                    | (App 冷啟動)          |
|         v                                       v                       |
|  [ scene(_:continue:) ]                 [ scene(_:willConnectTo:) ]     |
|         |                                       |                       |
|         +-------------------+-------------------+                       |
|                             |                                           |
|                             v                                           |
|  [ App 查詢商戶後端以重新獲取權威權限 ]                                 |
|                             |                                           |
|                             v                                           |
|  [ 場景階層顯示確認畫面並解鎖數位商品 ]                                 |
|                                                                         |
+-------------------------------------------------------------------------+

此架構強調了一個關鍵的安全邊界：URL 查詢參數絕不能作為支付的權威證明。 入站的通用連結僅提供返回路由的上下文；權威性的數位履行必須始終直接從商戶的後端計費服務中重新獲取。

// 展示安全返回路由的 Swift 實作範例。
// 在 UIWindowSceneDelegate 中驗證入站通用連結，解析不透明訂單參考，
// 並查詢權威後端計費服務以更新權限，而非依賴瀏覽器 Cookie。

import UIKit

struct CheckoutCompletionPayload {
    let orderRef: String
}

final class PaymentReturnRouter {
    static let shared = PaymentReturnRouter()
    
    // 白名單主機以強制執行深度防禦路由邊界
    private let authorizedHost = "checkout.example.com"
    private let authorizedPathPrefix = "/payment-complete"

    private init() {}

    /// 解析並驗證入站通用連結，提取非權威性的支付完成提示
    func parseReturnURL(_ url: URL) -> CheckoutCompletionPayload? {
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true),
              components.scheme == "https",
              components.host == authorizedHost,
              components.path.hasPrefix(authorizedPathPrefix),
              let queryItems = components.queryItems else {
            return nil
        }

        guard let orderRef = queryItems.first(where: { $0.name == "order_ref" })?.value else {
            return nil
        }

        return CheckoutCompletionPayload(orderRef: orderRef)
    }

    /// 指導檢視階層導覽，並將權威交易驗證委派給後端
    func handlePaymentCompletion(payload: CheckoutCompletionPayload, in window: UIWindow?) {
        // 注意：URL 查詢參數不能作為支付證明。
        // 無論查詢參數如何，原生 App 皆透過驗證通道查詢權威後端服務。
        BackendBillingService.shared.verifyExternalOrder(orderRef: payload.orderRef) { result in
            DispatchQueue.main.async {
                guard let nav = window?.rootViewController as? UINavigationController else { return }
                
                switch result {
                case .success(let orderState):
                    if orderState.isPaid {
                        let successVC = OrderSuccessViewController(orderRef: payload.orderRef, entitlements: orderState.entitlements)
                        nav.pushViewController(successVC, animated: true)
                    } else {
                        let pendingVC = OrderPendingViewController(orderRef: payload.orderRef)
                        nav.pushViewController(pendingVC, animated: true)
                    }
                case .failure(let error):
                    print("權威訂單驗證失敗: \(error.localizedDescription)")
                    let failureVC = OrderFailureViewController()
                    nav.pushViewController(failureVC, animated: true)
                }
            }
        }
    }
}

// 監控冷啟動與熱啟動期間通用連結傳遞的 SceneDelegate
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    // 場景 1: 從 Safari 返回時啟動或啟動場景
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = scene as? UIWindowScene else { return }
        
        let window = UIWindow(windowScene: windowScene)
        let navigationController = UINavigationController(rootViewController: StorefrontViewController())
        window.rootViewController = navigationController
        self.window = window
        window.makeKeyAndVisible()

        if let userActivity = connectionOptions.userActivities.first(where: { $0.activityType == NSUserActivityTypeBrowsingWeb }),
           let incomingURL = userActivity.webpageURL,
           let payload = PaymentReturnRouter.shared.parseReturnURL(incomingURL) {
            PaymentReturnRouter.shared.handlePaymentCompletion(payload: payload, in: window)
        }
    }

    // 場景 2: 將通用連結傳遞給已在記憶體中執行或暫停的場景
    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
              let incomingURL = userActivity.webpageURL,
              let payload = PaymentReturnRouter.shared.parseReturnURL(incomingURL) else {
            return
        }

        PaymentReturnRouter.shared.handlePaymentCompletion(payload: payload, in: self.window)
    }
}

struct OrderState {
    let isPaid: Bool
    let entitlements: [String]
}

final class BackendBillingService {
    static let shared = BackendBillingService()
    private init() {}
    
    func verifyExternalOrder(orderRef: String, completion: @escaping (Result<OrderState, Error>) -> Void) {
        // 透過安全 API 查詢商戶後端以確認交易狀態與權限資格
        completion(.success(OrderState(isPaid: true, entitlements: ["unlimited_access", "premium_tier"])))
    }
}

class StorefrontViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "商店"
        view.backgroundColor = .systemBackground
    }
}

class OrderSuccessViewController: UIViewController {
    let orderRef: String
    let entitlements: [String]
    
    init(orderRef: String, entitlements: [String]) {
        self.orderRef = orderRef
        self.entitlements = entitlements
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) { fatalError("init(coder:) 尚未實作") }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "訂單確認"
        view.backgroundColor = .systemGroupedBackground
    }
}

class OrderPendingViewController: UIViewController {
    let orderRef: String
    init(orderRef: String) {
        self.orderRef = orderRef
        super.init(nibName: nil, bundle: nil)
    }
    required init?(coder: NSCoder) { fatalError("init(coder:) 尚未實作") }
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "訂單處理中"
        view.backgroundColor = .secondarySystemBackground
    }
}

class OrderFailureViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "支付失敗"
        view.backgroundColor = .systemGroupedBackground
    }
}

下游行動獲取與安裝邊界

雖然 App-to-Web 路由規範了現有使用者離開 App 完成交易的流程，但數位商戶經常面臨相反的操作挑戰：在開放 Web 上獲取新客戶，並將其引導至原生行動應用程式。

在多通路行銷活動中，潛在使用者經常透過社群媒體、內容行銷或網路搜尋廣告接觸到 Web 商店或促銷登陸頁。在這些 Web 登陸頁上，客戶可能會在安裝原生 App 前註冊帳戶、設定訂閱或選擇促銷活動。

+-------------------------------------------------------------------------+
|             獨立的下游行動獲取旅程                                      |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 外部接觸點: Web 商店 / 促銷登陸頁 ]                                  |
|  擷取上下文: ?campaign_id=fall_sale&promo_code=SAVE20&sku=8831          |
|         |                                                               |
|         v                                                               |
|  [ 使用者與活動互動 / 點擊 "取得行動 App" CTA ]                        |
|         |                                                               |
|         v                                                               |
|  [ 跳轉至 Apple App Store ]                                             |
|         |                                                               |
|         v                                                               |
|  [ 安裝邊界: 標準 App Store 下載流程不會在首次啟動時自動重建 Web 上下文 ]|
|         |                                                               |
|         v                                                               |
|  [ 使用者首次啟動 App (冷啟動) ]                                       |
|  預設行為: 一般首頁；Web 活動上下文丟失。                              |
|         |                                                               |
|         v                                                               |
|  [ 延遲深度連結 (DDL) 引擎: 伺服器協助的訊號匹配 ]                      |
|         |                                                               |
|         v                                                               |
|  [ 合格上下文恢復: App 路由至登入或領取商品畫面 ]                      |
|         |                                                               |
|         v                                                               |
|  [ App 驗證使用者 & 後端分別確認權限 ]                                 |
|                                                                         |
+-------------------------------------------------------------------------+

當未安裝的用戶從行動 Web 商店導航至 App Store 時，標準的作業系統分發管道不會將任意的 Web 查詢參數（如行銷標籤、聯盟代碼或待處理的訂單參考）傳遞給新安裝的應用程式二進位檔。在首次冷啟動時，應用程式無法原生識別是哪項特定的促銷活動或 Web 商品引發了下載。

為了跨越此安裝邊界，工程團隊會針對客戶旅程評估多種連結處理框架：

在生產級行動架構中，開發團隊會部署如 Opoinstall 等延遲深度連結框架。像 Opoinstall 這類平台會在使用者跳轉至 App Store 前，記錄符合資格的預安裝 Web 點擊中繼資料（如行銷活動識別碼或產品 SKU 參考）。

在應用程式首次冷啟動時，用戶端 SDK 會查詢歸因後端，將首次啟動執行個體與之前的 Web 點擊會話進行匹配。根據 Opoinstall 官方平台文件，此延遲參數傳遞框架可在高達 98% 的符合條件案例中於首次啟動時恢復參數，提供手動輸入促銷碼或通用首頁導航以外的自動化替代方案。

保持精確的架構界限至關重要：延遲深度連結不會驗證使用者帳戶、證明支付所有權，也不會繞過平台審核政策。 它恢復的是非權威性的預安裝上下文（如訂單參考或轉介標籤），使應用程式能將使用者引導至合適的登入或兌換畫面，而後端的身份驗證與權限解鎖必須獨立執行。

給行動工程團隊的策略指導

最高法院對 Apple v. Epic Games 案的審理凸顯了行動應用市場監管環境的持續演變。然而，軟體架構師與計費工程師不應將支付路由視為等待司法結果後的附屬工程。

在全球運營 iOS 應用程式的工程組織，應將其系統錨定在以下三個架構原則上：

• 解耦區域支付邏輯：將標準美國外部連結規則與地區性 StoreKit 權限框架之間的支付路由實作區隔開來，以確保在多樣的法律商店中皆能合規。

• 強化入站通用連結回呼 (Callbacks)：在 UIWindowSceneDelegate 內建置具備韌性的通用連結處理器，驗證預期的 Scheme、Host 與 Path，並將傳入的查詢參數視為路由提示，而非權威的交易收據。

• 將歸因上下文與支付授權隔離：利用延遲深度連結來跨 App 安裝漏斗保留使用者意圖，同時確保帳戶身份驗證與數位權限解鎖始終由安全、權威的後端服務嚴格執行。

參考資料

• Supreme Court of the United States. (2026). Docket for No. 25-1311, Apple Inc., Petitioner v. Epic Games, Inc..

• Supreme Court of the United States. (2026). Brief for Petitioner Apple Inc., No. 25-1311.

• United States Court of Appeals for the Ninth Circuit. (2025). Epic Games, Inc. v. Apple, Inc., No. 25-2935, 161 F.4th 1162.

• Apple Developer. (2026). App Store Review Guidelines. Apple Documentation.

• Apple Developer. (2026). StoreKit External Purchase Link Entitlement. Apple Documentation.

• Apple Developer. (2026). Supporting Universal Links in your app. Apple Documentation.

• Apple Developer. (2026). Managing your app’s life cycle with UIWindowScene. Apple Documentation.

• MacRumors. (2026). Apple Asks Supreme Court to Throw Out App Store Contempt Ruling.

• AppleInsider. (2026). Apple standing its ground in Epic’s App Store fee suit.

• Opoinstall. (2026). Deferred Deep Linking and Parameterized App Installation Overview.