Deep linki bez SDK: Universal Links i App Links

Deep link to URL, który system operacyjny przekazuje aplikacji zamiast przeglądarce. Dotknij go przy zainstalowanej aplikacji, a aplikacja się otworzy. Bez aplikacji ładuje się strona w przeglądarce. W iOS nazywa się to Universal Links, w Androidzie App Links i żadne z nich nie potrzebuje SDK.

Konfiguracja to dwa pliki JSON na domenie, którą kontrolujesz, plus jedno uprawnienie (entitlement) lub filtr intencji w aplikacji. Poniżej: oba pliki, jak pasuje do tego domena krótkich linków, część pomijana przez większość poradników (aplikacja otrzymuje krótki URL, a nie cel przekierowania) i trzy zadania, które SDK nadal wykonuje lepiej.

Ma to dziś większe znaczenie niż kiedyś. Google wyłączył Firebase Dynamic Links 25 sierpnia 2025, a jego FAQ zwraca teraz HTTP 404 dla tych linków (FAQ wsparcia Firebase, dostęp 2026-10-24). To FAQ wymienia dostawcę dla pełnego parytetu funkcji oraz App Links i Universal Links dla aplikacji, które muszą się tylko otwierać, gdy są zainstalowane. W przypadku od druku do instalacji kod QR do pobrania aplikacji umieszcza ten sam routing za kodem do zeskanowania.

W skrócie

• Android App Links (Android 6, API 23 i nowsze) oraz iOS Universal Links obejmują "otwórz w aplikacji, jeśli zainstalowana, w przeciwnym razie strona internetowa" bez zewnętrznego SDK.
• Każde wymaga domeny, którą kontrolujesz, serwowanej przez HTTPS, z plikiem asocjacji w /.well-known/.
• Na domenie krótkich linków aplikacja jest uruchamiana z krótkim URL. Kod Twojej aplikacji musi zamienić go na ekran. Przekierowanie 302 nigdy się nie wykonuje.
• SDK nadal zarabiają na siebie w deferred deep linkingu, atrybucji instalacji i sklejaniu tożsamości. Pomiń je, jeśli tego nie potrzebujesz.

Jak system decyduje o otwarciu Twojej aplikacji

Oba systemy potwierdzają zweryfikowaną relację między domeną a aplikacją. Dokumentacja Androida mówi, że App Links pozwalają zweryfikowanym URL witryn "natychmiast otwierać odpowiednią treść w Twojej aplikacji na Androida, bez konieczności wybierania aplikacji z okna rozstrzygającego", a użytkownicy bez aplikacji "trafiają zamiast tego na Twoją witrynę - bez 404, bez błędów" (developer.android.com/training/app-links/about, dostęp 2026-10-24).

Android weryfikuje podczas instalacji. Gdy filtr intencji ma android:autoVerify="true", urządzenie z Androidem 6 lub nowszym sprawdza zadeklarowane hosty względem https://hostname/.well-known/assetlinks.json w trakcie instalacji aplikacji (developer.android.com/training/app-links/verify-android-applinks, dostęp 2026-10-24). Przed testem poczekaj co najmniej 20 sekund na to sprawdzenie. W Androidzie 15 i nowszych ponowna weryfikacja działa też okresowo, a zmiany pliku mogą się propagować do siedmiu dni. Android 14 i starsze podchwytują zmiany tylko przy instalacji lub aktualizacji.

Strony deweloperskie Apple (developer.apple.com, Supporting associated domains i Supporting universal links) nie wyrenderowały się przy moim pobraniu 2026-10-24, więc nie cytuję zachowania Apple poza tym, co pokazują jego opublikowane przykłady: plik znajduje się w /.well-known/apple-app-site-association, aplikacja deklaruje applinks:your-domain w uprawnieniu Associated Domains, a Universal Link dociera do aplikacji jako aktywność użytkownika typu przeglądanie sieci, niosąca URL. Przed wydaniem sprawdź aktualną stronę Apple, zwłaszcza pod kątem cache'owania i zachowania w trybie deweloperskim.

Konsekwencja dla krótkich linków wynika wprost. System decyduje na podstawie dotkniętego URL. Dzieje się to przed jakimkolwiek żądaniem do Twojego serwera. Jeśli domena tego URL jest zweryfikowana dla Twojej aplikacji, aplikacja otwiera się z tym URL. Żadne żądanie HTTP do krótkiego linku nie następuje, więc żadne przekierowanie się nie wykonuje.

Dwa pliki

Jeden plik na platformę, każdy pod stałą ścieżką na tej samej domenie.

apple-app-site-association

Plik AASA musi być serwowany pod https://yourdomain.example/.well-known/apple-app-site-association. Serwuj go przez HTTPS z prawidłowym łańcuchem certyfikatów, statusem 200 i Content-Type: application/json, bez przekierowania.

Opis formatu Apple to Supporting associated domains; jego strona nie wyrenderowała się u mnie 2026-10-24, więc potraktuj poniższy przykład jako powszechnie publikowany kształt i sprawdź go względem tej strony.

Minimalny kształt AASA:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.example.acme"],
        "components": [
          {
            "/": "/spring-*",
            "comment": "Match any path starting with /spring-"
          },
          {
            "/": "/campaigns/*"
          }
        ]
      }
    ]
  }
}

appIDs to złączenie Team ID Apple i identyfikatora bundle Twojej aplikacji, oddzielonych kropką. Tablica components kontroluje, które ścieżki uruchamiają routing do aplikacji; wszystko, co nie pasuje do komponentu, trafia do przeglądarki. W tablicy details możesz zarejestrować wiele aplikacji - przydatne, jeśli masz wariant konsumencki i firmowy tego samego produktu na tej samej domenie.

Jeden szczegół wart wyraźnego podania: "/" ze wzorcem wieloznacznym, takim jak /spring-*, to dopasowanie prefiksu ścieżki. Składnia wzorców w tym samym opisie obejmuje * (dowolny podciąg), ? (dowolny pojedynczy znak) i obiekty wykluczeń. Jeśli chcesz dopasować każdą ścieżkę na domenie, użyj "/" : "/*". Jeśli chcesz wykluczyć konkretną ścieżkę z routingu do aplikacji - powiedzmy, że Twoja strona /account/delete ma zawsze otwierać się w przeglądarce - dodaj obiekt wykluczenia przed symbolem wieloznacznym:

{
  "/": "/account/delete",
  "exclude": true
}

Reguły są oceniane od pierwszej do ostatniej, więc wykluczenia umieszczaj przed symbolami wieloznacznymi.

assetlinks.json

Plik Digital Asset Links dla Androida znajduje się pod https://yourdomain.example/.well-known/assetlinks.json. Google dokumentuje format pod adresem developers.google.com/digital-asset-links/v1/getting-started.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.acme",
      "sha256_cert_fingerprints": [
        "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
      ]
    }
  }
]

package_name to identyfikator aplikacji w Sklepie Play. sha256_cert_fingerprints zawiera odciski SHA-256 certyfikatu podpisu Twojej aplikacji (strona Google mówi, że cele aplikacji mobilnych są identyfikowane przez skrót certyfikatu i nazwę pakietu). Pobierz go przez keytool -list -v -keystore your.keystore albo z ustawień podpisywania w Play Console, jeśli podpisuje aplikację Play. Wymień każdy certyfikat, którym instalujesz kompilacje, w tym debug.

W przeciwieństwie do pliku AASA plik Androida nie zawiera reguł ścieżek. Dopasowanie ścieżek dla App Links odbywa się w AndroidManifest.xml przez <intent-filter> z android:pathPrefix, android:pathPattern. Plik assetlinks.json potwierdza własność domeny; manifest deklaruje, które ścieżki obsługuje aplikacja.

Jak pasuje domena krótkich linków

Link taki jak go.acme.example/spring-launch to po prostu URL na domenie. Daj go.acme.example te dwa pliki asocjacji i zadeklaruj ją w aplikacji, a dotknięcie tego linku otwiera aplikację na urządzeniach, na których jest zainstalowana. To jest sztuczka, a zarazem haczyk. Aplikacja otrzymuje https://go.acme.example/spring-launch, a nie stronę, na którą link przekierowuje.

Kod Twojej aplikacji ma wtedy dwie opcje. Pierwsza: samodzielnie dopasować ścieżkę (/spring-launch oznacza ekran wiosenny), co działa, gdy kontrolujesz sluga. Druga: zapytać serwer, na co wskazuje krótki link, i kierować na podstawie odpowiedzi. Elido nie ma udokumentowanego endpointu, dzięki któremu aplikacja rozwiązałaby sluga do celu. Publiczne przekierowanie po prostu odpowiada 302. Dziś niezawodna jest pierwsza opcja, a ta luka jest w naszym backlogu.

Na urządzeniach bez aplikacji albo gdy dotknięcie następuje w miejscu, które nie przekazuje linków systemowi, krótki link zachowuje się jak zawsze. Edge odpowiada przekierowaniem (domyślnie 302; link można ustawić na 301 lub 307), a przeglądarka za nim podąża. Reguły kierowania Elido mogą dopasowywać system operacyjny, więc jeden link może wysłać odwiedzających z iOS na stronę App Store, a z Androida do Google Play, gdy aplikacji nie ma.

Oto co Elido robi, a czego nie robi w tej sprawie dzisiaj, sprawdzone w kodzie:

Elido przechowuje JSON, który tworzysz, i serwuje go bez zmian pod własnymi ścieżkami /.well-known/ domeny. Elido nie generuje za Ciebie Team ID, ID bundle ani odcisku certyfikatu podpisu; pochodzą one z Twojego konta Apple Developer i klucza podpisu. Konfiguracja samej domeny (CNAME i TLS) jest taka sama jak w krótkich linkach z własną domeną, a strona funkcji deep linków pokazuje przepływ w panelu. Dla zespołów produktowych używających krótkich linków we wdrożeniu ten wzorzec obejmuje linki z zaproszeniami i poleceniami bez dodawania SDK do binarki. Połowę problemu, w której nic nie jest jeszcze zainstalowane, adresują na iOS App Clip Codes.

Co SDK nadal robi lepiej

Trzy rzeczy leżą poza tym, co daje system.

Deferred deep linking. Użytkownik dotyka przed instalacją. System nie ma aplikacji, której mógłby przekazać URL, więc dotknięcie trafia do przeglądarki, a intencja jest tracona. Dostawcy odzyskują ją przez probabilistyczne dopasowanie danych żądania lub przekazanie przez schowek. Monit Apple o zgodę na śledzenie czyni przypadki brzegowe brzydkimi. Elido tego dziś nie robi.

Atrybucja instalacji. Bez SDK nadal widzisz instalacje w App Store Connect i Play Console, ale nie powiążesz żadnej z konkretnym dotknięciem linku. Sygnały względne przetrwają: uruchom eksperymenty ze smart linkami i porównuj instalacje na kampanię. Atrybucja per urządzenie wymaga dostawcy.

Sklejanie tożsamości. Połączenie dotknięcia z adresem e-mail lub kontaktem CRM to projekt danych. Dostawcy utrzymują do tego graf urządzeń.

Jeśli żadna z tych trzech rzeczy nie ma znaczenia, prymitywy systemu wystarczą. Jeśli któraś ma, zatrudnij dostawcę tylko do tego zadania.

Książka kucharska konfiguracji

Trzy miejsca do ustawienia: serwer, projekt iOS i manifest Androida.

Wymagania HTTPS i ścieżki

Serwuj oba pliki przez HTTPS z certyfikatem łączącym się z publicznym głównym CA. Strona Digital Asset Links od Google mówi, że lista oświadczeń "musi" znajdować się w /.well-known/assetlinks.json, a listy gdzie indziej lub pod innymi nazwami nie są ważne (developers.google.com/digital-asset-links/v1/getting-started, dostęp 2026-10-24). Ta strona nie mówi, czy przekierowania są śledzone, więc serwuj plik bezpośrednio ze statusem 200 i nie hazarduj. To samo dotyczy pliku Apple.

iOS: uprawnienie Associated Domains

W Xcode, w Signing & Capabilities, dodaj możliwość Associated Domains z wartością applinks:go.acme.example. Apple dokumentuje sufiks ?mode=developer dla kompilacji deweloperskich, który sprawia, że urządzenie pobiera plik z Twojego serwera zamiast korzystać z cache Apple; nie mogłem ponownie sprawdzić tej strony 2026-10-24, więc potwierdź to w dokumentacji Apple. Obsłuż przychodzący link jako aktywność użytkownika typu przeglądanie sieci (SwiftUI onContinueUserActivity(NSUserActivityTypeBrowsingWeb) albo delegat UIKit continue userActivity) i odczytaj webpageURL.

Android: App Links w manifeście

Wewnątrz aktywności, która ma obsługiwać linki:

<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="go.acme.example"
    android:pathPrefix="/campaigns/" />
</intent-filter>

Android bierze pod uwagę do automatycznej weryfikacji filtry z akcją VIEW, obiema powyższymi kategoriami i schematem http lub https. W Androidzie 11 i niższych system czyni Twoją aplikację domyślnym obsługującym tylko wtedy, gdy znajdzie plik Digital Asset Links dla każdego hosta w manifeście, więc jeden zły host psuje wszystkie. Na danym urządzeniu z domeną może być jednocześnie powiązana tylko jedna aplikacja.

Sprawdzanie, czy działa

Na Androidzie daj weryfikacji co najmniej 20 sekund po instalacji, potem uruchom adb shell pm get-app-links com.example.acme (Android 12 i nowsze) i szukaj verified. Ponowne uruchomienie możesz wymusić przez adb shell pm verify-app-links --re-verify com.example.acme. Wyniki takie jak none, denied czy legacy_failure oznaczają, że plik lub odcisk jest błędny.

Sam plik sprawdza API Digital Asset Links od Google, które wymienia oświadczenia możliwe do odczytania dla witryny: https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://go.acme.example&relation=delegate_permission/common.handle_all_urls. Pusta odpowiedź oznacza, że Android nie zweryfikuje aplikacji.

Na obu platformach pobierz plik tak, jak zrobiłby to robot:

curl -si https://go.acme.example/.well-known/assetlinks.json | head -20
curl -si https://go.acme.example/.well-known/apple-app-site-association | head -20

Chcesz zobaczyć 200 i treść JSON. Elido wysyła application/json dla obu plików. Zwykłe pomyłki to literówka w Team ID lub ID bundle, kompilacja wydania, której certyfikat podpisu nie figuruje na liście odcisków, oraz plik istniejący tylko na apeksie, podczas gdy linki używają subdomeny.

Kompromis, powiedziany wprost

Rezygnacja z SDK do deep linków usuwa zależność z binarki aplikacji i relację udostępniania danych z Twojej informacji o prywatności. Nie podam liczby rozmiaru; różni się u dostawców i żadnej nie mierzyłem. Koszt: dotknięcia przed instalacją nie da się powiązać z instalacją.

W zespołach na wczesnym etapie, gdzie koszt instalacji na kanał jeszcze nie steruje budżetem, zacznij od prymitywów systemu i dodaj dostawcę atrybucji, gdy dane staną się użyteczne.

Powiązane na blogu

• Krótkie linki z własną domeną: DNS, TLS i edge
• App Clip Codes wyjaśnione: skanuj, otwieraj, bez instalacji
• Smart linki wyjaśnione: routing na brzegu bez dodatkowej usługi
• Kod QR do pobrania aplikacji: jeden kod, oba sklepy