Deep Linking для iOS и Android: Universal Links, App Links, Deferred

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Deep Linking для iOS и Android: Universal Links, App Links, Deferred
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    562

Пользователь тапает по ссылке, переходит в магазин, устанавливает приложение и сразу попадает на нужный экран. Без этого теряется до 30% трафика из рекламных кампаний. Плохо реализованный deep link обходится бизнесу в миллионы рублей потерянных конверсий ежегодно. Наша команда с 10+ годами опыта в iOS и Android реализует решение под ключ за 2-4 недели.

Три типа deep links: что выбрать?

Тип Пример Надёжность Fallback Когда использовать
Custom URL Scheme myapp://product/123 Низкая (возможны коллизии) Нет Внутренняя кросс-апп коммуникация
Universal Links (iOS) / App Links (Android) https://domain.com/product/123 Высокая (верификация системой) Браузер Production, любые сценарии
Deferred Deep Link Ссылка с параметрами Зависит от SDK Магазин + установка Рекламные кампании, привлечение новых пользователей

Custom URL Scheme — самый простой, но самый ненадёжный. Если приложение не установлено — браузер показывает ошибку. Несколько приложений могут зарегистрировать одну схему — непредсказуемо какое откроется. Подходит только для внутренних сценариев.

Universal Links (iOS) / App Links (Android) — HTTP/HTTPS-ссылки, которые система перехватывает и открывает в приложении вместо браузера. Если приложение не установлено — обычный браузер. Надёжно, верифицированно, правильный fallback. Это стандарт для production.

Deferred Deep Links — ссылка сохраняет контекст даже если приложение не установлено. Пользователь тапает → App Store → установка → открытие → нужный экран. Реализуется через Branch.io, Adjust или AppsFlyer (Firebase Dynamic Links больше не поддерживается).

Как настроить Universal Links на iOS?

Требуется файл apple-app-site-association (AASA) на сервере:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appIDs": ["TEAMID.com.company.app"],
        "components": [
          { "/": "/product/*", "comment": "Страницы товаров" },
          { "/": "/profile/*" },
          { "/": "/order/*" },
          { "/": "/promo/*", "?": { "ref": "?" } }
        ]
      }
    ]
  }
}

AASA должен отдаваться с Content-Type: application/json, без редиректов, код 200. Apple CDN кэширует его до 48 часов. На iOS 16+ доступен режим developer для ускорения обновления в debug. В Info.plist пропишите домены в ключе com.apple.developer.associated-domains, а в SceneDelegate обработайте NSUserActivity. Подробнее в Apple Documentation.

App Links на Android: пошаговая настройка

Файл assetlinks.json на сервере:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.company.app",
    "sha256_cert_fingerprints": ["AA:BB:CC:..."]
  }
}]

SHA256 fingerprint из keystore: keytool -list -v -keystore release.jks. Для debug и release fingerprints разные — оба добавляем в production assetlinks.json или используем разные домены.

В AndroidManifest.xml:

<activity android:name=".MainActivity">
    <intent-filter android:autoVerify="true">
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="https"
            android:host="yourdomain.com"
            android:pathPrefix="/product/" />
    </intent-filter>
</activity>

android:autoVerify="true" запускает верификацию при установке. Проверить: adb shell pm get-app-links com.company.app. Если STATE_APPROVED — всё работает.

Роутер на клиенте: централизованная обработка

Никаких if (url.contains("product")) разбросанных по коду. Единый роутер с очередью pending deep links на случай, если навигация ещё не инициализирована.

// Android
class DeepLinkRouter {
    fun handle(intent: Intent, navController: NavController) {
        val uri = intent.data ?: return
        val path = uri.path ?: return

        val route = when {
            path.matches(Regex("/product/(\\d+)")) -> Route.ProductDetail(uri.lastPathSegment ?: return)
            path.matches(Regex("/order/(\\w+)")) -> Route.OrderDetail(uri.lastPathSegment ?: return)
            path == "/profile" -> Route.Profile
            path.startsWith("/promo/") -> {
                val ref = uri.getQueryParameter("ref")
                Route.Promo(uri.lastPathSegment ?: return, ref)
            }
            else -> { openInBrowser(uri); return }
        }
        navController.navigate(route)
    }
}
// iOS
final class DeepLinkRouter {
    func handle(url: URL) {
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false) else { return }
        let pathComponents = components.path.split(separator: "/").map(String.init)

        switch pathComponents.first {
        case "product" where pathComponents.count == 2:
            navigationManager.push(.productDetail(id: pathComponents[1]))
        case "order" where pathComponents.count == 2:
            navigationManager.push(.orderDetail(id: pathComponents[1]))
        case "profile":
            navigationManager.push(.profile)
        default:
            UIApplication.shared.open(url)
        }
    }
}

Почему Deferred Deep Links критичны для рекламы?

Обычный Universal Link теряет контекст, если приложение не установлено. Deferred Deep Link запоминает параметры (например, id товара) и передаёт их после установки. Это увеличивает конверсию из рекламы на 20–40%. При средней цене лида 1000 руб правильный deep link экономит до 300 000 руб в месяц на 10 000 установках. Для реализации используем Branch.io или Adjust — они предоставляют SDK и консоль для отслеживания.

Какие этапы включает реализация deep linking?

  • Аудит текущей навигации и схемы URL.
  • Проектирование роутера с очередью pending deep links.
  • Настройка AASA (iOS) и assetlinks.json (Android).
  • Интеграция Universal Links / App Links + обработка в коде.
  • Подключение Deferred Deep Links через выбранный SDK.
  • Тестирование на физических устройствах (iOS и Android).
  • Документация по поддержке и доступам.
  • Гарантия 30 дней после сдачи.

Закажите аудит текущей навигации — оценим сложность реализации за 2 дня.

Какие ошибки при deep linking допускают чаще всего?

  • Redirect на CDN ломает App Links. Если домен редиректит на www, AASA нужен на обоих.
  • Неправильный Content-Type. AASA только application/json.
  • Отсутствие обработки onNewIntent на Android. Deep link при warm start игнорируется.
  • Навигация до готовности NavController. Используем очередь.

Сравнение провайдеров Deferred Deep Links

Провайдер SDK размер Fingerprinting Attribution window Интеграция
Branch.io ~2 MB Да 7 дней Простая, единый SDK
Adjust ~1.5 MB Нет 30 дней Настраиваемая
AppsFlyer ~1.8 MB Да 30 дней Широкая аналитика
Airbridge ~1.2 MB Нет 14 дней Лёгкая, быстрая

Сроки и стоимость

Реализация Universal Links + App Links + роутер + deferred deep links занимает от 2 до 4 недель. Стоимость рассчитывается индивидуально после оценки объёма работ. Свяжитесь с нами — получите консультацию и предварительную оценку.

Deep link — фундаментальная концепция, без которой невозможно представить современные мобильные приложения. Мы поможем внедрить её правильно и без головной боли.

Интеграция API в мобильное приложение: с чего начать

Запрос уходит, ответ не приходит, timeout — 30 секунд. Пользователь смотрит на спиннер. Сети нет — мобильная карта в метро. Или сеть есть, но сервер вернул 200 с HTML-страницей ошибки вместо JSON — и приложение крашит при JSONDecoder.decode(). Мы видим такие кейсы на каждом втором проекте. Поэтому интеграция API в мобильное приложение — это не просто вызов endpoint'а, а проектирование надёжного сетевого слоя: обработка ошибок, кэширование, offline-режим, certificate pinning. Закажите аудит текущего сетевого слоя — оценим проект за 1 день.

Почему стандартные библиотеки недостаточны? URLSession и OkHttp предоставляют базовый HTTP-клиент, но для production нужны retry с exponential backoff, валидация статус-кодов, типизированная десериализация и мониторинг состояния сети. Без этого приложение теряет данные и пользователей. Мы уже 5 лет занимаемся мобильной разработкой и реализовали более 30 проектов с интеграцией API на iOS, Android и Flutter — от стартапов до enterprise-решений.

Как выбрать протокол для интеграции API?

Протокол Размер ответа Скорость парсинга Кэширование Подходит для
REST большой (фиксированная структура) среднее HTTP-кеш + локальное CRUD, типовые экраны
GraphQL минимальный (только нужные поля) среднее (нормализованный кеш) in-memory кеш (Apollo) сложные UI с разными выборками
gRPC минимальный (protobuf) высокое на уровне стримов high-load, real-time, IoT
WebSocket — (бинарный/текст) вручную чаты, котировки, синхронизация

REST остаётся стандартом для большинства проектов. Но когда на экране профиля нужно 5 полей из 40, GraphQL исключает over-fetching и сокращает трафик на 30–60%. gRPC оправдан при тысячах запросов в минуту (trading, IoT) — бинарная сериализация в 3–5 раз быстрее JSON. WebSocket — единственный выбор для real-time без polling (сообщения, уведомления).

Пример из практики: для финтех-приложения мы заменили REST (40 полей) на GraphQL — размер ответа сократился с 12 КБ до 2,5 КБ, время рендера экрана упало на 70%. Экономия трафика составила около 15 000 ₽ в месяц при 100 000 активных пользователей.

Как обеспечить надёжность соединения и offline-first

Пользователи теряют сеть в метро, лифте, тоннеле. Мобильное приложение обязано работать без интернета — хотя бы в read-only режиме. Мы внедряем паттерн offline-first:

  1. При открытии экрана сначала показываем данные из локального кеша (Core Data / Room).
  2. Параллельно выполняем сетевой запрос, обновляем UI после ответа.
  3. Если сеть недоступна — показываем кешированные данные и метку «нет соединения».
  4. При восстановлении сети автоматически синхронизируем изменения.

Для кэширования HTTP-ответов используем URLCache (iOS) и OkHttp Cache (Android) с поддержкой Cache-Control. Для структурированных данных — SwiftData / Room. NWPathMonitor / ConnectivityManager.NetworkCallback отслеживают состояние сети и триггерят обновление.

REST и выбор клиентской библиотеки

Alamofire (iOS) — де-факто стандарт для Swift-проектов. Поверх URLSession добавляет request chaining, response validation, automatic retry, certificate pinning через ServerTrustManager. AF.request() с .validate() возвращает ошибку для любого статус-кода вне 200–299. Без .validate() Alamofire считает 404 и 500 успешными ответами. С Swift Concurrency — async-версия через serializingDecodable.

Retrofit (Android) — аннотационный HTTP-клиент поверх OkHttp. Интерфейс с аннотациями компилируется в реализацию. @GET, @POST, @Path, @Query, @Body — декларативное описание API. OkHttp под капотом: connection pooling, transparent gzip, HTTP/2 multiplex. HttpLoggingInterceptor — логирование в debug-сборке. Authenticator — автоматический refresh токена при 401.

Ktor (KMM/Flutter) — мультиплатформенный HTTP-клиент. На iOS работает через Darwin engine (URLSession), на Android — через OkHttp. Единый код для обеих платформ при KMM-архитектуре.

GraphQL: когда REST не справляется

REST возвращает фиксированную структуру. Экран профиля требует name, avatar, email — сервер отдаёт 40 полей. Over-fetching. GraphQL решает это: клиент запрашивает ровно нужные поля. Это критично для мобайла, где трафик и время парсинга — реальные ограничения. Apollo iOS и Apollo Kotlin генерируют типизированные классы по схеме: schema.graphql + query-файлы → строгие типы на этапе компиляции. Subscriptions через WebSocket — real-time без polling. Ограничение: GraphQL сложнее кешировать на уровне HTTP. Apollo использует нормализованный in-memory кеш InMemoryNormalizedCache — запросы с пересекающимися данными обновляют кеш без дублирования. Apollo GraphQL Documentation

WebSocket: real-time без лишнего трафика

Polling (setInterval каждые 5 секунд) — трата батареи и трафика. WebSocket — постоянное двунаправленное соединение. iOS: URLSessionWebSocketTask (нативный, iOS 13+). Android: OkHttp WebSocket. Обязательная обработка reconnect: при onFailure — экспоненциальный backoff (1с → 2с → 4с → 8с → максимум 60с). Socket.IO — надстройка с автоматическим reconnect, но для новых проектов предпочтительнее нативный WebSocket (меньше зависимостей).

gRPC: для высоконагруженных сервисов

gRPC с protobuf — бинарная сериализация: меньше размер, быстрее парсинг. grpc-swift для iOS, grpc-kotlin для Android. Protobuf-схема компилируется в типизированные классы. Streaming (server-side, client-side, bidirectional) — нативная возможность. Порог применения: высокая частота запросов (trading, IoT) или критичная latency. Для обычного CRUD REST проще в дебаге и мониторинге.

Certificate Pinning и безопасность

Корпоративный proxy может перехватить HTTPS через подмену сертификата. Certificate pinning предотвращает это: приложение принимает только конкретный сертификат или публичный ключ. Alamofire: ServerTrustManager с PinnedCertificatesTrustEvaluator. OkHttp: CertificatePinner с SHA-256 хешем. Операционная сложность: при ротации сертификата старые версии приложения перестают работать. Решение — pinning на публичный ключ CA или поддержка нескольких пинов с grace period. Подробнее о certificate pinning на Wikipedia

Что входит в работу

Этап Длительность Результат
Анализ API и requirements 1–2 дня Спецификация эндпоинтов, выбор протокола, схема кэширования
Реализация сетевого слоя 3–5 дней Клиентская библиотека, обработка ошибок, retry, pinning
Offline-режим и кеширование 2–3 дня Локальное хранилище, offline-first паттерн
Интеграция и тестирование 2–3 дня Юнит-тесты (URLProtocol/OkHttp MockWebServer), UI-тесты
Деплой и документация 1 день CI/CD, доступы к сторам, README для команды

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

Сроки и стоимость

Реализация сетевого слоя с REST, retry, кэшированием и offline-режимом — 1–2 недели. Добавление GraphQL или WebSocket — ещё 1–2 недели. gRPC — 2–3 недели, включая кодогенерацию. Стоимость рассчитывается индивидуально после анализа API и требований к offline-поведению. Оценим проект за 1 день — свяжитесь для консультации.