Реализация Custom URL Scheme для мобильного приложения
Deep link не открывается — пользователь видит пустой браузер вместо нужного экрана приложения. Или открывается, но передаёт параметры в кодировке, которую приложение не парсит. Это классика при первой реализации URL scheme.
Два подхода и когда какой выбирать
Custom URL Scheme (myapp://product/123) — простой в реализации, но небезопасный: любое приложение может зарегистрировать тот же scheme и перехватить диплинк. Подходит для внутренней навигации между собственными приложениями или для dev-инструментов.
Universal Links (iOS) / App Links (Android) — работают через HTTPS-домен с верификационным файлом (apple-app-site-association / assetlinks.json). Безопасны, падают на браузер если приложение не установлено. Это правильный путь для продакшена.
На практике реализуем оба: Universal Links как основной механизм, Custom URL Scheme как fallback для случаев, когда верификация домена невозможна.
Детали реализации
iOS (Swift/SwiftUI): регистрируем scheme в Info.plist в CFBundleURLTypes, обрабатываем в application(_:open:options:) для UIKit или через .onOpenURL в SwiftUI. Для Universal Links — application(_:continue:restorationHandler:). Парсинг URL делаем через URLComponents, не через ручной split строки.
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/.
React Native: используем Linking API из react-native core, а для навигации — @react-navigation/native с linking конфигом. Главная ошибка здесь — забыть обработать кейс когда приложение было закрыто (cold start) vs уже запущено (foreground). Это разные события.
Flutter: пакет go_router поддерживает deep links нативно, нужно только настроить routerConfig с GoRouter и добавить конфигурацию в нативные модули через flutter_deeplinking_enabled в Info.plist/manifest.
Типичная ошибка при тестировании
Диплинк тестируют только через Safari/Chrome, но забывают проверить случай «приложение установлено, но закрыто». На iOS с Universal Links бывает задержка верификации AASA-файла при первом запуске — приложение открывается через браузер вместо диплинка, и команда думает что что-то сломано. Это нормальное поведение, кэш обновляется в течение суток.
Срок реализации: 1-3 дня для базового Custom URL Scheme, до 5 дней если нужны Universal Links с настройкой домена и навигацией к конкретным экранам.