URL Scheme: что это, как работает и используется в разработке

Что такое URL Scheme?

URL Scheme — это уникальный идентификатор протокола, который приложение регистрирует в операционной системе для получения вызовов по кастомным ссылкам. Когда пользователь переходит по ссылке вида myapp://profile/123, система определяет приложение, зарегистрировавшее схему myapp, и передаёт ему управление с полным URI. Такой механизм позволяет приложениям обмениваться данными и открывать друг друга без участия серверной инфраструктуры.

Концепция URL Scheme напрямую заимствована из веб-стандартов RFC 3986, где URI-схема является первым компонентом любого универсального идентификатора ресурса. В мобильной разработке эта идея адаптирована для межприкладной коммуникации, где вместо HTTP-сервера выступает само приложение-обработчик ссылки.

Примеры известных URL Scheme

Многие популярные приложения регистрируют собственные URL Scheme для интеграции со сторонними сервисами. Например, Spotify использует схему spotify://, Telegram — tg://, а Instagram — instagram://. Разработчики также часто создают схему вида appname:// для внутренней навигации и сквозного тестирования экранов.

URL Scheme по-прежнему широко применяются в push-уведомлениях, email-рассылках и QR-кодах, где требуется мгновенный переход в конкретный раздел приложения. Однако начиная с iOS 9 и Android 6 появились альтернативные механизмы, которые постепенно дополняют и заменяют голые схемы.

Синтаксис URL Scheme: схема, хост и путь

Структура кастомного URI подчиняется общей спецификации RFC 3986 и состоит из нескольких компонентов. Схема указывается первой и отделяется двоеточием от остальной части адреса. После схемы могут следовать хост, порт, путь, query-параметры и фрагмент, каждый из которых опционален.

Полный синтаксис выглядит как scheme://host/path?key=value#fragment. Схема является единственным обязательным элементом, остальные определяются потребностями конкретной реализации. Двойной слеш после схемы исторически заимствован из HTTP и не является строго обязательным по спецификации, но повсеместно используется как соглашение.

Компоненты URI

Для наглядного представления структуры URI используется таблица компонентов. Каждый элемент имеет своё назначение и уровень обязательности.

Разработчики могут произвольно выбирать структуру URI, что создаёт гибкость, но порождает проблемы совместимости между разными версиями приложения. Рекомендуется документировать формат URL Scheme как часть публичного API приложения и версионировать его при изменении.

Как работает URL Scheme в iOS

iOS требует явной регистрации каждой URL Scheme в файле Info.plist проекта. Разработчик добавляет массив CFBundleURLTypes, каждый элемент которого содержит идентификатор (CFBundleURLName) и список поддерживаемых схем (CFBundleURLSchemes). После регистрации система автоматически направляет все входящие вызовы по зарегистрированным схемам в приложение.

Обработка входящего URL Scheme происходит в делегате приложения через метод application(_:open:options:). Этот метод получает объект URL, из которого извлекается путь и query-параметры для принятия решения о навигации. Обработка должна возвращать Bool-значение, указывающее на успешность операции.

Обработка в AppDelegate

Ниже приведён пример реализации обработчика URL Scheme на языке Swift. Код демонстрирует извлечение хоста и query-параметров из входящего URI с помощью URLComponents.

func application(
    _ app: UIApplication,
    open url: URL,
    options: [UIApplication.OpenURLOptionsKey: Any]
) -> Bool {
    let host = url.host
    let params = URLComponents(
        url: url,
        resolvingAgainstBaseURL: false
    )?.queryItems
    if host == "profile" {
        navigateToProfile(params)
    }
    return true
}

Метод использует URLComponents для безопасного парсинга query-параметров. Этот подход предпочтительнее ручного разбора строки, так как автоматически обрабатывает процентное кодирование и декодирование специальных символов в значениях параметров.

Как работает URL Scheme в Android

Android использует систему Intent Filter для маршрутизации deep link на основе URL Scheme. Разработчик объявляет фильтр в AndroidManifest.xml внутри тега Activity, которая должна обрабатывать ссылку. Фильтр содержит action VIEW, категории BROWSABLE и DEFAULT, а также тег data с указанием схемы, хоста и pathPrefix.

Когда пользователь переходит по ссылке с кастомной схемой, система проверяет Intent Filter всех установленных приложений. Если найдено несколько подходящих приложений, пользователю предлагается диалог выбора. Категория BROWSABLE разрешает обработку ссылки из браузера.

Настройка Intent Filter

Пример объявления Intent Filter в AndroidManifest.xml для обработки схемы myapp на Activity. Комбинация action и category обязательна для корректной маршрутизации deep link.

<activity android:name=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile"
            android:pathPrefix="/user" />
    </intent-filter>
</activity>

После настройки фильтра в Activity необходимо вызвать intent.getData() для получения URI. Важно проверять intent и данные на null, так как Activity может быть запущена без входящего deep link, например при стандартном запуске из лаунчера.

Передача параметров через URL Scheme

Query-параметры в URL Scheme передаются после знака вопроса в формате ключ=значение, разделённые амперсандом. Этот формат идентичен HTTP-запросам и легко обрабатывается стандартными средствами платформы. Параметры должны быть закодированы с помощью процентного кодирования для всех символов, не входящих в допустимый набор URI.

Пример полной ссылки с параметрами: myapp://profile?userId=42&source=email&ref=abc123. После извлечения URL приложение последовательно парсит все query-items и на основе их значений принимает решение о навигации на целевой экран.

Ограничение длины URI

При передаче составных данных важно учитывать ограничение на длину URI. В iOS максимальная длина URL Scheme ограничена 2 КБ, после чего система обрезает ссылку. В Android лимит составляет около 8 КБ, но точное значение зависит от версии ОС и производителя устройства. Для больших объёмов данных рекомендуется передавать только идентификатор сессии через URL Scheme, а остальные данные загружать с сервера.

Ограничения и альтернативы URL Scheme

Основной недостаток URL Scheme — невозможность обработать ссылку, если приложение не установлено на устройстве. Браузер отображает ошибку, и пользователь теряет контекст перехода. Для решения этой проблемы Apple внедрила Universal Links в iOS 9, а Google — App Links в Android 6. Оба механизма регистрируются через веб-домен, привязанный к приложению.

Universal Links и App Links работают как обычные HTTPS-ссылки, но при наличии приложения открывают его без диалога выбора. Если приложение не установлено, ссылка открывает веб-страницу на том же домене, сохраняя пользовательский опыт. Это делает их предпочтительной альтернативой для production-среды.

Механизмы fallback

Для URL Scheme на iOS и Android нет встроенного механизма fallback. Разработчики используют промежуточные серверные решения: ссылка ведёт на веб-страницу, которая проверяет установку приложения через JavaScript и перенаправляет либо на схему, либо в магазин приложений. Firebase Dynamic Links и Branch.io предлагают готовые решения этой проблемы с поддержкой deferred deep link, которые автоматически определяют статус установки и маршрутизируют пользователя без необходимости разрабатывать собственный серверный пайплайн.

Дополнительная сложность возникает при использовании URL Scheme в iOS 15+ и Android 12+, где ужесточены правила конфиденциальности. Safari блокирует попытки открыть незарегистрированную схему без предварительного подтверждения, а Android 12 ограничивает видимость установленных приложений через PackageManager. Эти изменения делают использование URL Scheme для межприкладного взаимодействия менее надёжным, чем в ранних версиях платформ.