苹果就藐视法庭判决上诉最高法院？App-to-Web 支付路由的技术指南

苹果就藐视法庭裁决向最高法院提起上诉了吗？2026 年 9 月 14 日，苹果公司在 Apple Inc. v. Epic Games, Inc. (案号 25-1311) 一案中，向美国最高法院提交了实质性案情陈述摘要，请求最高法院推翻或撤销此前关于其“反引导（anti-steering）”合规框架的民事藐视法庭判决。该上诉并未重启对 2021 年反垄断裁决的审理，而是聚焦于司法藐视权力的程序界限：特别是第九巡回上诉法院是否在仅仅基于禁令的“精神”而非“明确文本”的情况下，将当事人判定为民事藐视。对于移动软件架构师、计费工程师以及用户增长团队而言，这场围绕 App-to-Web 支付路由 的法律纠纷具有显著的工程指导意义。随着开发者部署外部支付流程，以提供标准内购 (IAP) 之外的替代支付机制，工程团队必须设计稳健的双向路由管道——提供可靠的返回上下文处理机制，确保原生 App 能通过 Universal Links 从后端计费服务中同步获取权威的交易状态。

最高法院上诉：藐视法庭的权力边界与 75 字禁令

最高法院审理的核心在于，依据《联邦民事诉讼规则》第 65(d) 条及联邦衡平法判例，判定民事藐视所需的法律标准。

2021 年 9 月，美国加州北区地方法院裁定，苹果并未触犯联邦反垄断法，但其禁止开发者进行支付引导的准则因造成了“信息损害”，违反了加州的《反不正当竞争法》(UCL)。为纠正该违规行为，地方法院发布了一项 75 字的永久禁令，禁止苹果阻止开发者在其 App 中包含“除内购之外，引导用户使用其他购买机制的按钮、外部链接或其他行动号召”。

要点速览

提交最高法院案情陈述：2026 年 9 月 14 日，苹果针对 Apple Inc. v. Epic Games, Inc. (案号 25-1311) 提交了调卷令申请摘要，挑战第九巡回法院以禁令“精神”作为藐视法庭依据的判决。
核心争议点：最高法院仅受理争议问题 1：当禁令文本对涉案行为未明确说明时，法院能否基于禁令的“隐含意图”判定民事藐视，还是必须根据长期适用的“不存在公平合理怀疑”标准（Taggart v. Lorenzen）要求明确告知。
运营触发点：藐视法庭裁定源于苹果 2024 年 1 月的合规计划，该计划允许外部支付链接，但对 7 天内的外部链接交易收取 12% 至 27% 的佣金，并对按钮展示形式进行了规范。
上诉法院处置：第九巡回法院依据其“精神”原则维持了藐视法庭的裁定，但撤销了地方法院对链接外链佣金的永久禁令，并要求重审费用问题。目前地方法院的重审程序仍在进行中，而苹果的上诉旨在完全撤销藐视法庭判决及其相关的重审指示。

据 MacRumors 和 AppleInsider 的报道，由 Latham & Watkins 律所的 Gregory G. Garre 撰写的苹果摘要辩称，最初的 75 字禁令并未提及链接外链佣金及具体的按钮样式。苹果已取消了对支付引导的全面禁止，建立了“外部购买链接”准则，并允许开发者包含外部链接。当 Epic 对佣金和设计要求提出质疑时，地方法院判定苹果构成藐视，理由是苹果阻碍了法令的竞争目标。

苹果主张，将民事藐视与明确的文本命令剥离，违反了第 65(d) 条的特异性要求，并剥夺了受监管方的公平通知权。根据官方的最高法院案卷，Epic Games 计划于 2026 年 11 月 13 日提交回复摘要，口头辩论将于 2027 年由最高法院排期进行。

苹果 Epic 法律回顾与 App-to-Web 支付路由指南

Epic v. Apple 反引导诉讼时间轴

日期/时期	程序事件	运营背景
2021 年 9 月 10 日	地方法院裁决	UCL 禁令禁止苹果阻止外链引导
2024 年 1 月 16 日	合规计划发布	苹果引入外部购买链接规则
2025 年 4 月 30 日	民事藐视令	地方法院判定苹果藐视；禁止收取佣金
2025 年 12 月 11 日	第九巡回法院裁决	基于“精神”维持藐视定性；撤销 0% 费率规则
2026 年 6 月 30 日	最高法院受理	调卷令仅限于民事藐视问题 (问题 1)
2026 年 9 月 14 日	提交实质案情摘要	苹果向最高法院提交案情摘要 (案号 25-1311)
2026 年 11 月 13 日	计划提交回复摘要	Epic Games 将提交回复摘要

构建 App-to-Web 支付闭环

无论最高法院如何界定民事藐视的程序边界，工程团队面临的现实已明确：开发者可以实现外部购买链接，引导用户通过网页完成支付。然而，执行此切换需要区分具体的商店框架与移动网页支付工程的通用需求。

商店框架：美国政策与区域性 StoreKit 外部购买框架

一种常见的架构误区是认为所有外部支付链接都依赖相同的系统 API。开发者必须根据商店的地理位置及适用的项目来解耦其实现方案：

美国商店框架：继 2021 年禁令后，Apple App Store 审核准则允许美国商店的应用包含引导用户至 IAP 之外购买机制的按钮、外部链接或其他行动号召，无需获取专门的“StoreKit 外部购买链接权限 (Entitlement)”。商业条款、分级评估和上报机制仍受适用的开发者协议管辖。
区域性 StoreKit 外部购买框架：在美国以外，实现模型因司法管辖区和苹果项目而异。某些商店（如特定的欧洲经济区或俄罗斯外链项目）使用特定的 StoreKit 权限，调用 ExternalPurchaseLink.open() 时会弹出持续页，并在 URL 中追加苹果生成的外部购买 Token 以供审计。其他地区和项目（如韩国的替代支付或不断演变的欧盟商业条款）则使用不同的 StoreKit API、通知页和上报管道。此外，欧盟已宣布自 2026 年 10 月 1 日起过渡到统一商业条款，这意味着权限、API、佣金和上报要求必须在实施时根据开发者所适用的商店和协议进行评估。

美国与区域性 iOS 外部购买路由使用不同的框架

构建双向网页支付闭环

以下架构演示了一个通用的、由商户设计的外部链接流程。在受专业平台项目管辖的商店中，区域性 StoreKit API 可能在必要时替代或封装出站调度步骤。

出站浏览器调度：App 展示符合要求的行动号召或链接按钮。用户互动后，App 使用标准系统处理程序调度外部 URL（或在区域性权限 API 强制要求时使用 StoreKit 页）。App 会追加一个不透明的、短期有效的结账会话引用（例如 https://checkout.example.com/pay?session_ref=chk_99182）以关联用户意图。敏感的个人数据或原始账户凭证绝不应通过 URL 查询字符串明文传输。
网页端交易处理：网页支付网关接收会话引用，处理客户身份验证，并通过外部支付服务提供商（如 Stripe 或 Adyen）执行支付处理。
商户后端确认：一旦外部处理器确认支付，商户后端将在其权威数据库中标记订单为已完成，并记录完成凭证。
入站返回导航 (Universal Links)：支付完成后，网页完成页会提供或发起返回原生 App 的流程，使用经过验证的 Apple Universal Links（例如 https://checkout.example.com/payment-complete?order_ref=ord_8812）。
设备端场景处理与权益刷新：操作系统拦截 HTTPS Universal Link，并通过 scene(_:continue:) 或 scene(_:willConnectTo:options:) 将有效载荷分发给 UIWindowSceneDelegate。原生 App 解析不透明的订单引用，通过授权的 API 查询后端以验证交易归属，并据此更新用户权益。

iOS 外部支付流程通过 Universal Links 返回以进行后端校验

+-------------------------------------------------------------------------+
|                  双向 App-to-Web 支付管道流水线                         |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 原生 iOS App: 用户选择外部购买选项 ]                                 |
|         |                                                               |
|         |-- (通过 UIApplication.shared.open 调度外部链接)             |
|         v                                                               |
|  [ Safari / 默认 Web 浏览器: 打开支付门户 ]                             |
|  URL: https://checkout.example.com/pay?session_ref=CHK_99182            |
|         |                                                               |
|         v                                                               |
|  [ 网页支付网关: 处理外部交易 ]                                         |
|         |                                                               |
|         |-- (商户后端确认支付并记录凭证)                                |
|         v                                                               |
|  [ 网页完成页: 发起已验证的 Universal Link 返回流程 ]                    |
|  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 查询参数绝不能作为购买的权威证明。 入站的 Universal Link 仅提供返回路由的上下文；权威的数字交付必须始终直接从商户的后端计费服务中同步获取。

// Swift 实现示例：展示从外部网页结账返回的安全路由逻辑。
// 在 UIWindowSceneDelegate 内验证入站 Universal Links，解析不透明订单引用，
// 并查询权威后端计费服务以更新权益，而不依赖浏览器 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() {}

    /// 解析并验证入站 Universal Link，以提取非权威的支付完成提示
    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)
                }
            }
        }
    }
}

// UIWindowSceneDelegate 捕获冷启动及活跃会话生命周期中的 Universal Link 交付
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: 将 Universal Link 传递给已运行或挂起的现有场景
    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]
}

// 代表 App 视图控制器层级和计费服务的存根
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 完成交易的过程，但数字商户经常面临相反的运营挑战：如何在公开网络上获取新客户并将其转化为原生移动端用户。

在多渠道营销活动中，潜在用户经常通过社交媒体、内容营销或搜索引擎广告访问网页商店或营销落地页。在这些页面上，客户可能会在安装原生 App 之前注册账户、配置订阅或选择促销优惠。

在后台授权前，延迟上下文跨越了安装边界

+-------------------------------------------------------------------------+
|             独立的下游移动端获客旅程                                      |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ 外部接触点: 网页商店 / 促销落地页 ]                                  |
|  已捕获上下文: ?campaign_id=fall_sale&promo_code=SAVE20&sku=8831      |
|         |                                                               |
|         v                                                               |
|  [ 用户与活动交互 / 点击 "获取 App" 按钮 ]                             |
|         |                                                               |
|         v                                                               |
|  [ 跳转至 Apple App Store ]                                             |
|         |                                                               |
|         v                                                               |
|  [ 安装边界: 标准应用商店下载流程在首次启动时                            |
|    无法自动还原任意 Web 上下文 ]                                         |
|         |                                                               |
|         v                                                               |
|  [ 用户首次启动 App (冷启动) ]                                          |
|  默认行为: 通用首页；丢失网页活动上下文。                               |
|         |                                                               |
|         v                                                               |
|  [ 延迟深度链接引擎: 服务器辅助信号匹配 ]                               |
|         |                                                               |
|         v                                                               |
|  [ 合格上下文还原: App 跳转至登录或权益领取页 ]                         |
|         |                                                               |
|         v                                                               |
|  [ App 验证用户身份 & 后端单独确认权益 ]                                |
|                                                                         |
+-------------------------------------------------------------------------+

当未安装 App 的用户从移动端网页商店跳转到 App Store 时，标准的操作系统分发通道不会将任意网页查询参数（如活动标签、联属网络营销 Token 或待处理订单引用）传递给新安装的应用二进制文件。在首次冷启动时，应用无法原生识别是哪个特定的促销活动或网页商品触发了下载。

为了跨越这一安装边界，工程团队在客户旅程中评估了多种链接处理框架：

路由架构	目标 App 状态	跨安装参数保留	运营所有权模型
自定义 URI Scheme	目标 App 已安装	App 缺失时无原生目标；需要明确的兜底处理	应用方所有（维护成本高）
已验证 Universal Links	目标 App 已安装	解析至兜底网页；商店下载后无法原生还原任意 Web 上下文	域名 + 应用方所有（需 AASA 托管）
区域性 StoreKit 外部购买 API	目标 App 已安装	取决于商店和项目；部分流程需要苹果权限、系统披露、Token 及/或上报	平台管理（受区域项目规则约束）
延迟深度链接 (DDL)	目标 App 未安装	在首次冷启动时还原符合条件的预安装参数	SDK 辅助（托管归因和路由引擎）

在移动端生产架构中，开发团队会部署延迟深度链接框架，如 Openinstall。像 Openinstall 这样的平台会在用户跳转至 App Store 之前，记录符合条件的预安装网页点击元数据（如营销活动标识符或商品 SKU 引用）。

在应用首次冷启动时，客户端 SDK 会查询归因后端，将首次启动实例与之前的网页点击会话进行匹配。根据 Openinstall 官网的官方文档，这种延迟参数传递框架可在高达 98% 的符合实例中实现首次启动时的参数还原，为手动输入促销码或跳转至通用首页提供了自动化替代方案。

保持精确的架构边界至关重要：延迟深度链接不认证用户账户，不证明支付所有权，也不绕过平台审核政策。 它仅用于还原非权威的预安装上下文（如订单引用或邀请标签），使 App 能引导用户至合适的登录或领取页，在此处进行独立的后端身份验证与权益解锁。

常见问题 (FAQ)

最高法院在 Apple v. Epic Games 案中同意裁决的核心问题是什么？

最高法院严格针对争议问题 1 批准了调卷令，即评估在禁令文本未明确禁止相关行为时，联邦法院是否可以基于禁令的“精神”将当事人判定为民事藐视。苹果辩称，根据最高法院先例（Taggart v. Lorenzen），民事藐视需要明确的通知，并且只有在禁令文本对所禁止的行为不存在公平合理怀疑时，才能被判定。

iOS 上的每一个外部购买链接是否都需要 StoreKit 外部购买链接权限？

不一定，具体要求因商店而异。在美国商店，继 2021 年反引导禁令后，苹果更新了《App Store 审核准则》，允许开发者包含引导用户至替代购买机制的按钮、外部链接或其他行动号召，而无需获取专门的 `com.apple.developer.storekit.external-purchase-link` 权限。在其他司法管辖区，苹果强制执行因地区和项目而异的 StoreKit 框架、通知流程及上报要求，具体取决于当地监管和平台协议——欧盟条款正在根据苹果 2026 年 10 月 1 日实施的统一商业框架进行积极过渡。

移动 App 从外部网页结账返回时如何保持状态？

为了保持状态，开发者需实现 Apple Universal Links。网页结账完成后，网页服务器使用关联的 HTTPS 域名发起返回重定向。iOS 拦截 URL 并将有效载荷通过 `scene(_:continue:)` 或 `scene(_:willConnectTo:options:)` 分发给 `UIWindowSceneDelegate`。App 会解析返回的会话或订单引用，查询后端计费服务以验证交易状态，并更新用户权益，而不依赖于脆弱的浏览器 Cookie。

移动开发团队的战略指南

最高法院对 Apple v. Epic Games 的审理凸显了监管移动应用市场的法律和法规仍在持续演变。然而，软件架构师和计费工程师不能将支付路由视为司法结果出来后再考虑的次要任务。

运营全球 iOS 应用的工程组织应围绕以下三个架构原则来锚定系统：

解耦区域支付逻辑：将标准美国外部链接规则与区域性 StoreKit 权限框架之间的支付路由实现分离开来，以确保在多样化的法律商店中合规。
加强入站 Universal Link 回调：在 UIWindowSceneDelegate 中构建稳健的 Universal Link 处理程序，验证预期的 Scheme、主机和路径，将入站查询参数视为路由提示而非权威的交易收据。
将归因上下文与支付授权隔离：利用延迟深度链接（Deferred Deep Linking）在应用安装漏斗中保留用户意图，同时确保账户认证和数字权益解锁严格由安全的权威后端服务强制执行。