Apple оспаривает решение о неуважении к суду в Верховном суде? Навигация по маршрутизации платежей из приложения в веб

Apple оспаривает решение о неуважении к суду по делу Epic в Верховном суде? 14 сентября 2026 года компания Apple подала краткое изложение своих доводов в Верховный суд США по делу Apple Inc. v. Epic Games, Inc. (№ 25-1311), требуя отменить решение о гражданском неуважении к суду, которое было вынесено компании за её правила соблюдения антирулевого (anti-steering) контроля. Вместо пересмотра исходного антимонопольного постановления 2021 года апелляция фокусируется на процедурных пределах судебной власти: в частности, на том, ошибся ли Девятый окружной апелляционный суд, обвинив сторону в неуважении к суду на основании «духа» предписания, а не его буквального текста. Для архитекторов мобильного ПО, инженеров по биллингу и команд по привлечению пользователей юридический спор вокруг маршрутизации платежей «из приложения в веб» имеет огромное архитектурное значение. Поскольку разработчики внедряют внешние платежные потоки для предложения альтернативных способов оплаты вне стандартных покупок в приложении (IAP), инженерные команды должны проектировать устойчивые двусторонние конвейеры маршрутизации — обеспечивая надежную передачу контекста возврата, чтобы нативное приложение могло восстановить авторизованное состояние транзакции из внутренних платежных сервисов через Universal Links.

Апелляция в Верховный суд: власть суда и предписание из 75 слов

Спор, рассматриваемый в Верховном суде, сосредоточен на юридическом стандарте, необходимом для обвинения в гражданском неуважении к суду согласно Федеральным правилам гражданского процесса 65(d) и сложившейся федеральной судебной практике.

В сентябре 2021 года Окружной суд США Северного округа Калифорнии постановил, что Apple не является незаконным монополистом по федеральным антимонопольным законам, но пришел к выводу, что правила для разработчиков, запрещающие «руление» (steering), нарушают Закон Калифорнии о недобросовестной конкуренции (UCL), создавая информационный вред. Чтобы исправить это нарушение, суд выдал постоянный судебный запрет из 75 слов, запрещающий Apple препятствовать разработчикам размещать в приложениях «кнопки, внешние ссылки или другие призывы к действию, направляющие клиентов к механизмам оплаты, в дополнение к встроенным покупкам в приложении».

Краткий обзор

• Подан краткий обзор доводов в Верховный суд: 14 сентября 2026 года Apple подала краткое изложение по ходатайству о выдаче судебного приказа (writ of certiorari) по делу Apple Inc. v. Epic Games, Inc. (№ 25-1311), оспаривая использование Девятым окружным судом «духа» предписания для оправдания гражданского неуважения к суду.
• Основной вопрос: Верховный суд принял дело к рассмотрению исключительно по Вопросу 1: может ли гражданское неуважение к суду основываться на невысказанной цели предписания, когда приказ не содержит указаний относительно спорного поведения, или же неуважение требует четкого уведомления согласно стандарту «отсутствия обоснованных сомнений» (Taggart v. Lorenzen).
• Операционный триггер: Упоминание о неуважении возникло из-за плана соответствия Apple от января 2024 года, который разрешил внешние ссылки на покупку, но ввел комиссию от 12% до 27% на транзакции по ссылкам в течение семи дней, одновременно регулируя визуальное представление кнопок.
• Распоряжение апелляционного суда: Девятый окружной суд подтвердил вывод о неуважении согласно доктрине «духа», но отменил постоянный запрет окружного суда на комиссии по внешним ссылкам, отправив дело на пересмотр сборов. Пока идут процедуры в окружном суде, апелляция Apple направлена на полную отмену решения о неуважении к суду и связанных с ним инструкций.

Согласно материалам, опубликованным MacRumors и AppleInsider, в документе Apple, подготовленном Грегори Г. Гарре из Latham & Watkins, утверждается, что исходный запрет из 75 слов ничего не говорил о комиссиях по внешним ссылкам и конкретных стилях кнопок. Apple устранила категорический запрет на «руление», ввела правила для External Purchase Link и разрешила разработчикам включать внешние ссылки. Когда Epic оспорила комиссию и требования к дизайну, нижестоящие суды сочли Apple виновной в гражданском неуважении, так как она препятствовала более широким конкурентным целям указа.

Apple утверждает, что разрыв связи между гражданским неуважением и однозначными текстовыми командами нарушает требование о конкретике правила 65(d) и лишает регулируемые стороны справедливого уведомления. Согласно официальному реестру Верховного суда, Epic Games должна подать ответный документ 13 ноября 2026 года, а устные слушания состоятся в сроки, установленные Судом в 2027 году.

Хронология антирулевого судебного разбирательства Epic v. Apple

Проектирование цикла оплаты «из приложения в веб»

Независимо от того, как Верховный суд разрешит процедурные границы гражданского неуважения, практическая реальность для инженерных организаций ясна: разработчики могут внедрять внешние ссылки для направления пользователей к веб-оплате. Однако выполнение этой передачи требует разграничения между специализированными фреймворками витрин и общими требованиями проектирования веб-оплаты для мобильных устройств.

Фреймворки витрин: политика США против региональных External-Purchase фреймворков StoreKit

Распространенное архитектурное заблуждение заключается в том, что все внешние платежные ссылки опираются на идентичные системные API. Разработчики должны разделять свои реализации в зависимости от географии магазина и применимых программ:

• Фреймворк витрины США: После постановления 2021 года, Руководство App Store Review разрешает приложениям в витрине США включать кнопки, внешние ссылки или другие призывы к действию, направляющие пользователей к механизмам оплаты вне IAP, без необходимости специального профиля StoreKit External Purchase Link Entitlement. Коммерческие условия, оценки уровней и механизмы отчетности остаются предметом соответствующих соглашений с разработчиками.
• Региональные фреймворки StoreKit External-Purchase: За пределами США модели реализации варьируются в зависимости от юрисдикции и программы Apple. Некоторые витрины (например, отдельные программы внешних ссылок в Европейской экономической зоне или России) используют специальные права StoreKit, где вызов ExternalPurchaseLink.open() отображает окно продолжения и добавляет сгенерированный Apple токен внешней покупки к URL для аудита. Другие юрисдикции и программы — например, альтернативный биллинг в Южной Корее или меняющиеся бизнес-условия ЕС — используют отдельные API StoreKit, уведомления и конвейеры отчетности. Кроме того, в ЕС Apple объявила о переходе на унифицированные бизнес-условия с 1 октября 2026 года, что означает, что права, API, комиссия и требования к отчетности должны оцениваться при реализации в соответствии с действующей витриной и соглашением разработчика.

Построение двустороннего цикла веб-оплаты

Следующая архитектура иллюстрирует типичный поток внешней ссылки, разработанный продавцом. В витринах, регулируемых специализированными программами платформы, специфические для региона API StoreKit могут заменять или дополнять этап отправки внешних ссылок там, где это требуется.

1. Исходящая отправка в браузер: Приложение представляет допустимый призыв к действию или кнопку ссылки. При взаимодействии пользователя приложение отправляет внешний URL, используя стандартные системные обработчики (или окна StoreKit, где это требуется региональными API прав доступа). Приложение добавляет непрозрачный краткосрочный идентификатор сессии оплаты (например, https://checkout.example.com/pay?session_ref=chk_99182) для соотнесения намерений пользователя. Конфиденциальные персональные данные или исходные учетные данные аккаунта никогда не должны передаваться в открытом виде в строке запроса URL.
2. Обработка транзакций на веб-стороне: Веб-платежный шлюз получает идентификатор сессии, обрабатывает аутентификацию клиента и выполняет обработку платежа через стороннего провайдера платежных услуг (например, Stripe или Adyen).
3. Подтверждение на бэкенде продавца: После того как внешний процессор подтверждает оплату, бэкенд продавца отмечает заказ как исполненный в своей базе данных и записывает квитанцию.
4. Входящая навигация возврата (Universal Links): После завершения оплаты веб-страница предлагает или инициирует возврат в нативное приложение с использованием подтвержденных Apple Universal Links (например, https://checkout.example.com/payment-complete?order_ref=ord_8812).
5. Обработка на устройстве и обновление прав: Операционная система перехватывает HTTPS Universal Link и доставляет данные в UIWindowSceneDelegate через scene(_:continue:) или scene(_:willConnectTo:options:). Нативное приложение парсит непрозрачный идентификатор заказа, делает запрос к своему бэкенду по аутентифицированному API для проверки владения транзакцией и обновляет права пользователя.

+-------------------------------------------------------------------------+
|                  ДВУСТОРОННИЙ КОНВЕЙЕР ОПЛАТЫ ИЗ ПРИЛОЖЕНИЯ В ВЕБ             |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ Нативное iOS-приложение: Пользователь выбирает внешний вариант оплаты ]              |
|         |                                                               |
|         |-- (Отправка ссылки через UIApplication.shared.open)    |
|         v                                                               |
|  [ Safari / Веб-браузер: Открывает портал оплаты ]                |
|  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 проверен) ]           |
|         |                                                               |
|         +---------------------------------------+                       |
|         | (Приложение в памяти)               | (Холодный запуск)     |
|         v                                       v                       |
|  [ scene(_:continue:) ]                 [ scene(_:willConnectTo:) ]     |
|         |                                       |                       |
|         +-------------------+-------------------+                       |
|                             |                                           |
|                             v                                           |
|  [ Приложение запрашивает бэкенд для обновления прав доступа ]|
|                             |                                           |
|                             v                                           |
|  [ Иерархия сцен отображает экран подтверждения & открывает контент ]|
|                                                                         |
+-------------------------------------------------------------------------+

Эта архитектура усиливает важный рубеж безопасности: параметры запроса URL никогда не должны служить авторизованным доказательством покупки. Входящая Universal Link предоставляет контекст для возврата; авторизованное исполнение цифровых заказов всегда должно происходить напрямую через бэкенд-сервисы биллинга продавца.

// Пример Swift-реализации, демонстрирующий безопасную маршрутизацию возврата после внешнего веб-чекаута.
// Проверяет входящие Universal Links внутри 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() {}

    /// Парсит и проверяет входящую 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 не являются доказательством покупки.
        // Нативное приложение делает запрос к бэкенду по защищенному каналу независимо от параметров запроса.
        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]
}

// Заглушки для отображения иерархии контроллеров и сервисов биллинга
final class BackendBillingService {
    static let shared = BackendBillingService()
    private init() {}
    
    func verifyExternalOrder(orderRef: String, completion: @escaping (Result<OrderState, Error>) -> Void) {
        // Запрос к бэкенду для проверки состояния заказа и доступа к правам
        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
    }
}

Привлечение пользователей и граница установки

В то время как маршрутизация «из приложения в веб» управляет существующими пользователями, выходящими из установленного приложения, цифровые продавцы часто сталкиваются с обратной задачей: привлечение новых клиентов на открытом веб-пространстве и перевод их в нативное мобильное приложение.

В многоканальных маркетинговых кампаниях пользователи часто попадают на веб-витрины или лендинги через социальные сети, контент-маркетинг или рекламу в поиске. На этих страницах клиент может зарегистрировать аккаунт, настроить подписку или выбрать акцию до установки нативного приложения.

+-------------------------------------------------------------------------+
|             ОТДЕЛЬНОЕ ПУТЕШЕСТВИЕ ПО ПРИВЛЕЧЕНИЮ МОБИЛЬНЫХ ПОЛЬЗОВАТЕЛЕЙ             |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ Внешняя точка касания: Веб-витрина / Лендинг ]     |
|  Захваченный контекст: ?campaign_id=fall_sale&promo_code=SAVE20&sku=8831     |
|         |                                                               |
|         v                                                               |
|  [ Пользователь нажимает на «Получить приложение» CTA ]         |
|         |                                                               |
|         v                                                               |
|  [ Перенаправление в Apple App Store ]                                        |
|         |                                                               |
|         v                                                               |
|  [ ГРАНИЦА УСТАНОВКИ: Стандартный процесс App Store не переносит      |
|    произвольный веб-контекст при первом запуске ]    |
|         |                                                               |
|         v                                                               |
|  [ Пользователь впервые запускает приложение (холодный старт) ]                       |
|  Поведение: Стандартный экран; контекст веб-кампании утерян.   |
|         |                                                               |
|         v                                                               |
|  [ Движок отложенных диплинков (DDL): Сопоставление сигналов на сервере ]      |
|         |                                                               |
|         v                                                               |
|  [ Восстановление контекста: Приложение направляет к логину или акции ]    |
|         |                                                               |
|         v                                                               |
|  [ Приложение аутентифицирует пользователя & бэкенд подтверждает права ]   |
|                                                                         |
+-------------------------------------------------------------------------+

Когда неавторизованный пользователь переходит с мобильной веб-витрины в App Store, стандартные каналы ОС не передают произвольные параметры запроса (такие как теги кампании, партнерские токены или ссылки на заказы) в устанавливаемый бинарный файл. При первом холодном запуске приложение не может нативно определить, какая именно промо-кампания или товар побудили пользователя к установке.

Чтобы преодолеть эту границу, инженерные команды оценивают несколько фреймворков обработки ссылок на пути клиента:

В мобильной разработке команды внедряют фреймворки отложенных диплинков, такие как Branch, AppsFlyer, Adjust или Opoinstall. Платформа, подобная Opoinstall, записывает метаданные клика до установки — например, идентификаторы маркетинговой кампании или SKU товара — прежде чем пользователь перейдет в App Store.

При первом холодном запуске приложения клиентский SDK запрашивает бэкенд атрибуции, чтобы сопоставить экземпляр первого запуска с предыдущим сеансом клика. Согласно официальной документации на главной странице Opoinstall, этот фреймворк сквозной передачи отложенных параметров может восстанавливать данные при первом запуске в 98% случаев, предоставляя автоматизированную альтернативу ручному вводу промокодов или навигации при первом запуске.

Поддержание точных архитектурных границ жизненно важно: отложенные диплинки не аутентифицируют аккаунты, не доказывают право собственности на платежи и не обходят политики проверки платформы. Они восстанавливают неавторизованный контекст до установки (такой как номер заказа или тег реферала), позволяя приложению направить пользователя на соответствующий экран логина или получения, где проверка личности и выдача прав доступа должны выполняться независимо.

Стратегическое руководство для инженерных мобильных команд

Рассмотрение Верховным судом дела Apple v. Epic Games подчеркивает продолжающуюся юридическую и регуляторную эволюцию мобильных маркетплейсов. Однако программные архитекторы и инженеры по биллингу не могут позволить себе относиться к маршрутизации платежей как к вопросу второго плана, ожидая судебных решений.

Инженерные организации, управляющие глобальными iOS-приложениями, должны опираться на три архитектурных принципа:

• Разделение региональной логики оплаты: Разделите реализацию маршрутизации платежей между стандартными правилами внешних ссылок США и региональными фреймворками StoreKit для обеспечения соответствия всем требованиям.

• Усиление обратных вызовов Universal Link: Создавайте устойчивые обработчики Universal Link в UIWindowSceneDelegate, которые проверяют ожидаемые схемы, хосты и пути, рассматривая входящие параметры запроса как подсказки для маршрутизации, а не как подтверждение транзакции.

• Изоляция контекста атрибуции от полномочий оплаты: Используйте отложенные диплинки (Deferred Deep Linking) для сохранения намерений пользователя через установку приложения, обеспечивая при этом, чтобы аутентификация аккаунта и выдача прав доступа строго контролировались защищенными бэкенд-сервисами.

Ссылки

• Верховный суд США. (2026). Реестр по делу № 25-1311, Apple Inc., Petitioner v. Epic Games, Inc..

• Верховный суд США. (2026). Brief for Petitioner Apple Inc., No. 25-1311.

• Апелляционный суд США по Девятому округу. (2025). Epic Games, Inc. v. Apple, Inc., No. 25-2935, 161 F.4th 1162.

• Apple Developer. (2026). App Store Review Guidelines. Документация Apple.

• Apple Developer. (2026). StoreKit External Purchase Link Entitlement. Документация Apple.

• Apple Developer. (2026). Supporting Universal Links in your app. Документация Apple.

• Apple Developer. (2026). Managing your app’s life cycle with UIWindowScene. Документация Apple.

• 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.