При одинаковой HTTPS-ссылке iOS открывает браузер, а Android — приложение. Как локализовать этап сбоя deep link-маршрутизации?
Сначала нужно разделить проверку на три этапа: распознаёт ли ОС ссылку как ссылку приложения, запускается ли нужное приложение и правильно ли оно обрабатывает переданный адрес. В описанном случае наиболее вероятен сбой привязки домена к приложению на iOS, а не ошибка экранов или сетевого запроса.
Проверку начинают с конфигурации Universal Links на iOS и App Links на Android, затем подтверждают результат на чистой установке и в разных источниках перехода. Если iOS не подтверждает доверенную связь домена с приложением, система обычно оставляет ссылку обычной веб-ссылкой и открывает браузер.
Мобильным приложениям понадобился способ открывать веб-ссылки внутри приложения без отказа от обычного веб-адреса. Ранние пользовательские схемы ссылок позволяли запускать приложение, но могли конфликтовать между приложениями и не обеспечивали надёжного веб-запасного варианта.
Universal Links в iOS и App Links в Android используют HTTPS-домен как видимый адрес и добавляют подтверждение связи между доменом и конкретным приложением. Это решает задачу выбора приложения при переходе по ссылке, сохраняя возможность открыть тот же материал в браузере, если приложение отсутствует или связь не подтверждена.
Одна и та же ссылка проходит несколько независимых стадий. ОС должна распознать подходящий домен, проверить декларацию доверия, выбрать приложение и передать ему URL; уже затем приложение должно разобрать путь, параметры и открыть нужный экран.
Неверный вывод возникает, если считать любой запуск браузера ошибкой маршрутизации внутри приложения. Причина может находиться раньше: в неверном домене, отсутствии декларации, несовпадении идентификатора приложения или подписи, неподдерживаемом пути либо в пользовательском выборе открывать ссылки в браузере.
Последствия особенно заметны в маркетинговых и авторизационных сценариях. Пользователь может попасть на общую веб-страницу, потерять контекст перехода или не завершить вход, хотя сервер и сам экран приложения работают корректно.
Сначала фиксируют точный URL: схему, домен, путь и параметры. Нельзя считать эквивалентными, например, разные поддомены или URL с путём, который не входит в разрешённые правила обработки.
Затем проверяют платформенную привязку. На iOS приложение заявляет поддерживаемый домен через Associated Domains, а домен публикует файл apple-app-site-association с разрешённым идентификатором приложения и путями. На Android приложение описывает подходящие HTTPS-ссылки в правилах намерений, а домен публикует assetlinks.json, где должны совпасть пакет приложения и отпечаток сертификата подписи.
Важно проверять именно ту сборку, которая установлена на устройстве. Для Android особенно частая причина — декларация содержит отпечаток сертификата от одной сборки, а на устройстве установлена сборка с другой подписью, например тестовая вместо релизной. Аналогично проверяют идентификатор приложения iOS и соответствие опубликованной декларации текущему варианту приложения.
После конфигурации проверяют переход из поддерживаемого источника, например из сообщения или письма, на чистой установке. Отдельно проверяют приложение, установленное до изменения конфигурации, повторное открытие ссылки, неизвестный путь и отсутствие приложения. Ввод URL вручную в адресной строке не всегда моделирует обычный пользовательский переход и не должен быть единственным тестом.
Если ОС передала ссылку приложению, проверяют журнал входящего URL и внутренний маршрутизатор: сохраняются ли путь и параметры, не происходит ли перенаправление на главный экран, корректно ли обрабатывается холодный и повторный запуск. Если приложение вообще не получает URL, исследуют платформенную привязку; если получает, но открывает неверный экран, исследуют уже приложение.
Есть важное ограничение: поведение может зависеть от пользовательского выбора, состояния установки и способа открытия ссылки. Поэтому один успешный переход не доказывает совместимость: нужны матрица платформ, версии ОС, вариантов сборки, источников ссылок и состояний приложения.
После выпуска Android-приложение открывало ссылки из рекламной кампании внутри приложения, а iOS-версия всегда показывала веб-страницу. Команда сначала изменила внутренний маршрутизатор, но это не помогло: приложение не получало URL вовсе.
Рассмотрели три варианта. Можно было заменить HTTPS-ссылки на пользовательскую схему, но это ухудшило веб-запасной сценарий и создало риск конфликтов. Можно было временно направлять пользователей на промежуточную страницу, но это добавляло задержку и скрывало исходную причину. Выбранным решением стала проверка доменной ассоциации iOS и соответствия путей рекламных ссылок опубликованным правилам.
Выяснилось, что декларация домена содержала идентификатор другой конфигурации приложения, а путь кампании не входил в разрешённые шаблоны. После исправления и проверки на чистой установке iOS стала передавать ссылку приложению; отдельно сохранили тест неизвестного пути, который должен открываться в браузере.
Почему переход из одного источника открывает приложение, а переход из другого — браузер?
Источник может по-разному формировать или передавать ссылку, а ОС и приложение могут по-разному обрабатывать контекст перехода. Нужно сравнить фактический URL, способ открытия, наличие промежуточных перенаправлений и пользовательские настройки, а не только текст ссылки. Такой дефект нельзя надёжно локализовать по одному скриншоту результата.
Как отличить ошибку доменной ассоциации от ошибки внутреннего маршрутизатора?
Нужно определить, получил ли процесс приложения исходный URL. Если URL не поступил, проверяют домен, декларацию доверия, идентификатор приложения, подпись, пути и состояние установки. Если URL поступил, но показан неверный экран, проблема находится в разборе пути, параметров, авторизации или обработке холодного запуска.
Почему проверка только на эмуляторе или только на одной сборке недостаточна?
Привязка зависит не только от кода маршрутизатора, но и от платформы, версии ОС, домена, типа сборки и сертификата подписи. Эмулятор может не воспроизвести поведение конкретного устройства или пользовательские настройки, а тестовая подпись может отличаться от релизной. Поэтому минимальная проверка должна включать реальные устройства, чистую установку, актуальную релизную конфигурацию и несколько состояний приложения.