Universal Links, App Links, Deferred Deep Links: повний гайд

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

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Universal Links, App Links, Deferred Deep Links: повний гайд
Середній
від 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

Universal Links, App Links та Deferred Deep Links: повний гайд

Користувач тапає по посиланню, переходить в магазин, встановлює додаток і одразу потрапляє на потрібний екран. Без цього втрачається до 30% трафіку з рекламних кампаній. Погано реалізоване глибоке посилання обходиться бізнесу в мільйони гривень втрачених конверсій щорічно. Наша команда має 10+ років досвіду, понад 50 реалізованих проектів із deep linking та працює на ринку з 2019 року, впроваджуючи рішення під ключ за 2-4 тижні.

Глибоке посилання — це універсальний механізм навігації, що використовує схемну десеріалізацію URI для інтроспекції навігаційного графа. Правильно налаштований deep link підвищує конверсію до 40%, що при середньому чеку 50$ дає додатковий прибуток від 5000$ на місяць.

Три типи глибоких посилань: що обрати?

Тип Приклад Надійність 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. Universal Links забезпечують верифікацію, яка в 3 рази надійніша за Custom URL Scheme.

Deferred Deep Links — посилання зберігає контекст навіть якщо додаток не встановлено. Користувач тапає → App Store → встановлення → відкриття → потрібний екран. Реалізується через Branch.io, Adjust або AppsFlyer (Firebase Dynamic Links більше не підтримується). Deferred Deep Links підвищують конверсію в 1.5 рази порівняно зі звичайними посиланнями.

Чому Universal Links кращі за Custom URL Scheme?

Universal Links мають низку переваг: автоматична верифікація через AASA, безпечне перенаправлення, сумісність з Handoff. Вони вважаються стандартом для сучасних iOS-додатків. На Android аналог — App Links, які також верифікуються через assetlinks.json. Обидва механізми забезпечують плавний перехід між вебом і додатком.

Налаштування 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%. Економія до 300 000 грн на місяць на 10 000 встановленнях. 95% користувачів очікують, що посилання відкриє додаток, а зниження відмов сягає 25%. Для реалізації використовуємо Branch.io або Adjust — вони надають SDK і консоль для відстеження. Branch.io має SDK у 2 рази більший за Adjust, але пропонує простішу інтеграцію.

Етапи реалізації deep linking

  1. Аудит поточної навігації та схеми URL.
  2. Проектування роутера з чергою pending deep links.
  3. Налаштування AASA (iOS) та assetlinks.json (Android).
  4. Інтеграція Universal Links / App Links + обробка в коді.
  5. Підключення Deferred Deep Links через обраний SDK.
  6. Тестування на фізичних пристроях (iOS та Android).
  7. Документація з підтримки та доступів.
  8. Гарантія 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 днів Легка, швидка
Приклад AASA файлу для iOS ```json { "applinks": { "apps": [], "details": [ { "appIDs": ["TEAMID.com.company.app"], "components": [ { "/": "/product/*", "comment": "Сторінки товарів" } ] } ] } } ```

Що входить у роботу

  • Повний аудит поточної реалізації deep link.
  • Робочий роутер з чергою pending deep links (код на iOS та Android).
  • Налаштовані AASA та assetlinks.json на вашому домені.
  • Інтегрований SDK для Deferred Deep Links (Branch/Adjust).
  • Документація з підтримки та доступами.
  • Гарантія 30 днів після здачі.

Строки та вартість

Реалізація Universal Links + App Links + роутер + deferred deep links займає від 2 до 4 тижнів. Вартість стартує від 1500 доларів і розраховується індивідуально після оцінки обсягу робіт. Зв'яжіться з нами — отримайте консультацію та попередню оцінку.

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

Метрики нашої компанії

Показник Значення
Років досвіду 10+
Реалізованих проектів 50+
На ринку з 2019
Середній термін реалізації 2-4 тижні
Гарантія 30 днів

Інтеграція API в мобільний додаток: з чого почати

Запит йде, відповідь не приходить, timeout — 30 секунд. Користувач дивиться на спінер. Мережі немає — мобільна карта в метро. Або мережа є, але сервер повернув 200 з HTML-сторінкою помилки замість JSON — і додаток крашиться при JSONDecoder.decode(). Ми бачимо такі кейси на кожному другому проєкті. Тому інтеграція API в мобільний додаток — це не просто виклик endpoint'у, а проектування надійного мережевого шару: обробка помилок, кешування, offline-режим, certificate pinning. Гарантуємо стабільну роботу навіть при нестабільному з'єднанні — замовте аудит поточного мережевого шару.

Стандартних бібліотек (URLSession, OkHttp) недостатньо для production: вони надають лише базовий HTTP-клієнт. Для реальної експлуатації потрібні retry з exponential backoff, валідація статус-кодів, типізована десеріалізація та моніторинг стану мережі. Без цього додаток втрачає дані та користувачів. Ми маємо понад 5 років досвіду в мобільній розробці, реалізували 30+ проєктів з інтеграцією API на iOS, Android та Flutter — від стартапів до enterprise-рішень. Сертифіковані iOS/Android розробники гарантують якість коду.

Як вибрати протокол для інтеграції 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%. Економія трафіку була значною при 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 відстежують стан мережі та тригерять оновлення. Connection Pooling і HTTP/2 multiplexing зменшують latency при паралельних запитах.

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. Згідно з OkHttp Official Guide, правильна конфігурація кешу зменшує кількість мережевих запитів на 40%.

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 — запити з перетинаючимися даними оновлюють кеш без дублювання.

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 (менше залежностей). TLS 1.3 забезпечує безпеку з'єднання.

Чому важливий certificate pinning?

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

Що входить у роботу

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

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

Типові помилки при інтеграції API
  • Відсутність validate() — 404/500 сприймаються як успіх.
  • Жорсткий timeout без retry — втрата даних при короткочасних збоях.
  • Відсутність offline-кешу — додаток безглуздий без мережі.
  • Ігнорування certificate pinning — вразливість до MITM.
  • Over-fetching через REST — зайвий трафік і час парсингу.

Терміни та вартість

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