Deep linking w iOS i Androidzie: reguły dozwolonych i ignorowanych linków

Deep linking, czyli kierowanie użytkownika z linku bezpośrednio do odpowiedniego ekranu aplikacji, działa w iOS w ramach Universal Links, a w Androidzie w ramach App Links. Są to funkcje systemowe, dzięki którym aplikacja może otwierać się ze zwykłych adresów HTTPS. Po prawidłowej konfiguracji kliknięcie linku takiego jak https://visuality.pl/dashboard/15 nie otwiera najpierw przeglądarki, lecz uruchamia aplikację od razu na właściwym ekranie. Jeśli aplikacja nie jest zainstalowana, ten sam link zachowuje się jak każdy inny adres URL i otwiera się w przeglądarce. Dzięki temu obsługa deep linków jest przewidywalna i bezpieczna, bez własnych schematów URL ani komunikatów proszących użytkownika o zgodę.

iOS

Aby obsługiwać Universal Links, domena internetowa i aplikacja muszą wzajemnie potwierdzić swoje zaufanie. Aplikacja iOS deklaruje domenę w swoich uprawnieniach, czyli entitlements. Domena potwierdza tę relację, udostępniając plik apple-app-site-association, określany także skrótem AASA. Plik należy umieścić w katalogu .well-known i serwować przez HTTPS, bez przekierowań oraz, co ważne, bez rozszerzenia .json. Dla domeny visuality.pl prawidłowa lokalizacja to:

https://visuality.pl/.well-known/apple-app-site-association

Plik określa, która aplikacja ma uprawnienie do otwierania domeny i które ścieżki powinny ją uruchamiać. Minimalny przykład wygląda następująco:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "YOUR_TEAM_ID.pl.visuality.app",
        "paths": ["*"]
      }
    ]
  }
}

Niektóre aplikacje wymagają bardziej szczegółowej kontroli. Często ogranicza się deep linking wyłącznie do stron, które mają sens w natywnym interfejsie, a pozostałe ścieżki jawnie się pomija. iOS umożliwia to przez połączenie konkretnych prefiksów i wykluczeń:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "YOUR_TEAM_ID.pl.visuality.app",
        "paths": [
          "/dashboard/*",
          "/tasks/*",
          "/profile/*",
          "/calendar/*",
          "NOT /admin/*",
          "NOT /api/*"
        ]
      }
    ]
  }
}

Ta konfiguracja pozwala otwierać w aplikacji najważniejsze obszary produktu wymagające uwierzytelnienia, natomiast ścieżki administracyjne i API nadal otwierają się w przeglądarce. Ponieważ reguły znajdują się na serwerze, zachowanie linków można zmienić bez publikowania nowej wersji w App Store.

Android

Android udostępnia podobny mechanizm o nazwie App Links. Zasada jest taka sama: kliknięcie linku HTTPS otwiera aplikację, jeśli jest ona zainstalowana. Weryfikacją również zarządza domena, ale Android oczekuje innego pliku. Zamiast apple-app-site-association używa pliku assetlinks.json, umieszczonego w tym samym katalogu .well-known:

https://visuality.pl/.well-known/assetlinks.json

Plik musi zawierać nazwę pakietu aplikacji na Androida oraz odcisk SHA-256 certyfikatu podpisującego. Typowa konfiguracja wygląda tak:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "pl.visuality.app",
      "sha256_cert_fingerprints": ["ANDROID_RELEASE_CERTIFICATE_SHA256_FINGERPRINT_HERE"]
    }
  }
]

W przeciwieństwie do iOS plik weryfikacyjny Androida nie definiuje filtrowania ścieżek. Android sprawdza jedynie, czy aplikacja jest powiązana z domeną. Decyzja o tym, które adresy URL powinny otwierać aplikację, zapada w kodzie projektu mobilnego, a dokładniej w manifeście aplikacji. Kontrolę na poziomie ścieżek realizują intent filters, czyli filtry intencji. Fragment konfiguracji może wyglądać następująco:

<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="visuality.pl"
    android:pathPrefix="/dashboard" />
    <data
    android:scheme="https"
    android:host="visuality.pl"
    android:pathPrefix="/tasks" />
    <data
    android:scheme="https"
    android:host="visuality.pl"
    android:pathPrefix="/profile" />
</intent-filter>

Każdy element <data> wskazuje jeden dozwolony obszar serwisu. Linki spoza tych ścieżek nadal będą otwierać się w przeglądarce. Ponieważ logika znajduje się w manifeście, każda zmiana zachowania linków wymaga aktualizacji aplikacji na Androida i dystrybucji nowej kompilacji. Z tego powodu podejścia iOS i Androida wzajemnie się uzupełniają: w iOS to serwer jest źródłem reguł dotyczących ścieżek, natomiast w Androidzie definiuje je aplikacja.

Podsumowanie

Choć szczegóły implementacji różnią się nieco między iOS a Androidem, obie platformy zapewniają bezpieczny i przewidywalny sposób obsługi deep linków. Domena internetowa potwierdza powiązanie za pomocą publicznego pliku przechowywanego w katalogu .well-known, a aplikacja deklaruje, które linki potrafi obsłużyć. Zapewnia to spójne doświadczenie: jeden link HTTPS działa w wiadomości e-mail, przeglądarce, powiadomieniu push i innej aplikacji. Jeśli aplikacja jest zainstalowana, nawigacja jest kontynuowana w natywnym interfejsie. Jeśli jej nie ma, użytkownik trafia do przeglądarki bez dodatkowych przeszkód.

Universal Links i App Links rozwiązują praktyczny problem współczesnych produktów mobilnych: użytkownicy powinni trafiać bezpośrednio do odpowiednich ekranów bez ręcznego szukania ich w interfejsie. Kontrolowany deep linking, oparty na jasnych regułach dla dozwolonych i ignorowanych adresów URL, pozwala osiągnąć ten cel w sposób łatwy w utrzymaniu.