Deep link не відкривається — користувач бачить порожній браузер замість потрібного екрана додатку. Або відкривається, але передає параметри в кодуванні, яке додаток не парсить. Це класика при першій реалізації URL scheme. В одному з проєктів з аудиторією 500k+ користувачів ми виявили, що 20% диплінків втрачалися через неправильну обробку параметрів у URL — це коштувало бізнесу 15% конверсії. За 7 років досвіду ми напрацювали методи, які гарантують коректну роботу диплінків у 99% випадків. Сертифіковані інженери (iOS, Android, Flutter) налаштовують схеми за 3 дні. Зв'яжіться з нами для консультації по вашому проєкту — ми допоможемо розібратися з глибокими посиланнями. Згідно з Apple Developer Documentation, Universal Links обов'язково вимагають коректного AASA-файлу. Впровадження Universal Links у проєкті з бюджетом $50,000 скоротило втрати конверсії на 20%.
Чому Universal Links безпечніші за Custom URL Scheme?
Custom URL Scheme (myapp://product/123) — простий у реалізації, але небезпечний: будь-який додаток може зареєструвати ту ж схему і перехопити диплінк. Підходить для внутрішньої навігації між власними додатками або для dev-інструментів. Universal Links (iOS) та App Links (Android) працюють через HTTPS-домен з верифікаційними файлами (apple-app-site-association / assetlinks.json). Безпечні, падають на браузер якщо додаток не встановлено. Це правильний шлях для продакшену. На практиці ми реалізуємо обидва: Universal Links як основний механізм, Custom URL Scheme як fallback для випадків, коли верифікація домену неможлива. Згідно з тестами, Universal Links у 3 рази рідше викликають помилки при холодному старті порівняно з Custom URL Scheme.
| Характеристика | Custom URL Scheme | Universal Links / App Links |
|---|---|---|
| Безпека | Низька (перехоплення) | Висока (верифікація) |
| Fallback | Не відкривається | Відкривається в браузері |
| Складність | Проста | Середня (потрібен домен) |
| Надійність | ~85% успішних відкриттів | >98% успішних відкриттів (з коректним налаштуванням) |
Як налаштувати deep link на iOS та Android?
iOS (Swift/SwiftUI): реєструємо схему в Info.plist в CFBundleURLTypes, обробляємо в application(_:open:options:) для UIKit або через .onOpenURL в SwiftUI. Для Universal Links — application(_:continue:restorationHandler:). Парсинг URL робимо через URLComponents, не через ручний split рядка. У конфігурації важливо вказати домени в Associated Domains Xcode.
Android (Kotlin): в AndroidManifest.xml додаємо <intent-filter> з <data android:scheme="myapp"/>, обробляємо intent.data в Activity. Для App Links додаємо android:autoVerify="true" і завантажуємо assetlinks.json на https://domain.com/.well-known/. Переконайтеся, що сервер повертає 200 та правильний Content-Type.
| Компонент | iOS | Android |
|---|---|---|
| Верифікація | AASA-файл через HTTPS | assetlinks.json через HTTPS |
| Обробка | application(_:continue:) | Intent.data з autoVerify |
| Fallback | Перехід на сайт | Відкриття в браузері |
| Типова помилка | Затримка кешу до 24 годин | Неправильний підпис додатку |
Крос-платформенні фреймворки
React Native: використовуємо Linking API з react-native core, а для навігації — @react-navigation/native з linking конфігом. Головна помилка тут — забути обробити кейс коли додаток був закритий (cold start) vs вже запущений (foreground). Це різні події. Додатково перевірте налаштування схем в Info.plist та AndroidManifest.
Flutter: пакет go_router підтримує deep links нативно, потрібно лише налаштувати routerConfig з GoRouter та додати конфігурацію в нативні модулі через flutter_deeplinking_enabled в Info.plist/manifest. Альтернативно можна використовувати app_links package.
Типові помилки при тестуванні
Диплінк тестують лише через Safari/Chrome, але забувають перевірити випадок «додаток встановлено, але закрито». На iOS з Universal Links буває затримка верифікації AASA-файлу при першому запуску — додаток відкривається через браузер замість диплінка, і команда думає що щось зламано. Це нормальна поведінка, кеш оновлюється протягом доби. На Android переконайтеся, що assetlinks.json повертає 200 та JSON валідний. Ще одна поширена проблема — використання HTTP замість HTTPS: за вимогами App Store Review Guidelines, всі диплінки повинні бути HTTPS. У підсумку близько 10% всіх збоїв пов'язані саме з HTTP-редиректами.
| Проблема | Причина | Рішення |
|---|---|---|
| Диплінк не відкривається на холодний старт | Обробка тільки foreground | Реалізувати обробку в AppDelegate/Application для cold start |
| Параметри передаються з помилками | Використання ручного split | Використовувати URLComponents/URI для парсингу |
| Universal Link не спрацьовує в iOS | Затримка верифікації AASA | Зачекати до 24 годин, перевірити SSL сертифікат |
Що входить в нашу роботу
- Аудит поточної схеми диплінкінгу
- Проектування цільової архітектури (URL scheme, Universal/App Links)
- Реалізація на обраному стеку (iOS/Android/Flutter/React Native)
- Налаштування верифікаційних файлів на сервері
- Тестування сценаріїв «холодний старт/foreground/background»
- Інтеграція з аналітикою (Firebase, AppsFlyer)
- Документація та навчання розробників
Кейс з практики: 30% помилок відловлюються на етапі тестування
Один із проєктів — додаток для інтернет-магазину з аудиторією 2M+ користувачів. Після впровадження Universal Links ми виявили 30% збоїв при холодному старті через неправильну обробку параметрів в AppDelegate. Після правки конверсія в перехід на цільовий екран зросла на 15%. Гарантуємо, що подібні проблеми будуть виключені на етапі аудиту.Замовте аудит диплінкінгу — отримайте готову конфігурацію за 3 дні. Отримайте консультацію — ми покажемо приклади реалізації для вашого стеку. Залиште заявку зараз.