Ein Deep Link ist eine URL, die das Betriebssystem an eine App statt an einen Browser übergibt. Tippen Sie darauf, während die App installiert ist, öffnet sich die App. Ohne die App lädt der Browser die Webseite. Auf iOS heißt das Universal Links, auf Android App Links, und beide brauchen kein SDK.
Der Aufbau besteht aus zwei JSON-Dateien auf einer Domain unter Ihrer Kontrolle sowie einem Entitlement oder Intent-Filter in der App. Unten: beide Dateien, wie eine Short-Link-Domain hineinpasst, der Teil, den die meisten Anleitungen auslassen (die App erhält die Short-URL, nicht das Redirect-Ziel), und die drei Aufgaben, die ein SDK weiterhin besser erledigt.
Das ist wichtiger als früher. Google hat Firebase Dynamic Links am 25. August 2025 abgeschaltet, und die FAQ liefert für diese Links nun HTTP 404 (Firebase-Support-FAQ, abgerufen am 2026-10-24). Diese FAQ nennt einen Anbieter für vollen Funktionsumfang sowie App Links und Universal Links für Apps, die sich nur öffnen müssen, wenn sie installiert sind. Für den Fall vom Druck zur Installation legt ein QR-Code für App-Downloads dasselbe Routing hinter einen scanbaren Code.
Kurzfassung
- Android App Links (ab Android 6, API 23) und iOS Universal Links decken "in der App öffnen, falls installiert, sonst Webseite" ohne SDK eines Drittanbieters ab.
- Jedes braucht eine Domain unter Ihrer Kontrolle, über HTTPS ausgeliefert, mit einer Zuordnungsdatei unter
/.well-known/. - Auf einer Short-Link-Domain wird die App mit der Short-URL gestartet. Ihr App-Code muss sie in einen Screen auflösen. Der 302 läuft nie.
- SDKs rechtfertigen ihre Kosten weiterhin bei Deferred Deep Linking, Install-Attribution und Identitätszusammenführung. Lassen Sie sie weg, wenn Sie das nicht brauchen.
Wie das Betriebssystem entscheidet, Ihre App zu öffnen
Beide Systeme stellen eine verifizierte Beziehung zwischen einer Domain und einer App fest. Die Android-Dokumentation sagt, dass App Links verifizierte Website-URLs "sofort den entsprechenden Inhalt in Ihrer Android-App öffnen lassen, ohne dass der Nutzer Ihre App in einem Auswahldialog wählen muss", und dass Nutzer ohne die App "stattdessen auf Ihre Website gelangen - keine 404, keine Fehler" (developer.android.com/training/app-links/about, abgerufen am 2026-10-24).
Android verifiziert bei der Installation. Trägt ein Intent-Filter android:autoVerify="true", prüft ein Gerät ab Android 6, während die App installiert wird, die deklarierten Hosts gegen https://hostname/.well-known/assetlinks.json (developer.android.com/training/app-links/verify-android-applinks, abgerufen am 2026-10-24). Warten Sie mindestens 20 Sekunden auf diese Prüfung, bevor Sie testen. Ab Android 15 läuft die erneute Verifizierung außerdem periodisch, und Dateiänderungen können bis zu sieben Tage zur Verbreitung brauchen. Android 14 und früher übernehmen Änderungen nur bei Installation oder Update.
Die Entwicklerseiten von Apple (developer.apple.com, Supporting associated domains und Supporting universal links) wurden bei meinem Abruf am 2026-10-24 nicht gerendert, daher zitiere ich Apples Verhalten nicht über das hinaus, was die veröffentlichten Beispiele zeigen: Die Datei liegt unter /.well-known/apple-app-site-association, die App deklariert applinks:your-domain in ihrem Associated-Domains-Entitlement, und ein Universal Link erreicht die App als Web-Browsing-Benutzeraktivität mit der URL. Prüfen Sie vor dem Release die aktuelle Apple-Seite, besonders zu Caching und Verhalten im Entwicklungsmodus.
Die Folge für Short Links ergibt sich direkt. Das Betriebssystem entscheidet anhand der angetippten URL. Das geschieht vor jeder Anfrage an Ihren Server. Ist die Domain dieser URL für Ihre App verifiziert, öffnet sich die App mit dieser URL. Es findet keine HTTP-Anfrage an den Short Link statt, also läuft kein Redirect.
Die zwei Dateien
Eine Datei pro Plattform, jede an einem festen Pfad auf derselben Domain.
apple-app-site-association
Die AASA-Datei muss unter https://yourdomain.example/.well-known/apple-app-site-association ausgeliefert werden. Liefern Sie sie über HTTPS mit gültiger Zertifikatskette, Status 200 und Content-Type: application/json aus, und ohne Redirect.
Apples Formatreferenz ist Supporting associated domains; die Seite wurde bei mir am 2026-10-24 nicht gerendert, behandeln Sie das Beispiel unten also als die üblich veröffentlichte Form und prüfen Sie es gegen diese Seite.
Eine minimale AASA-Form:
{
"applinks": {
"details": [
{
"appIDs": ["ABCDE12345.com.example.acme"],
"components": [
{
"/": "/spring-*",
"comment": "Match any path starting with /spring-"
},
{
"/": "/campaigns/*"
}
]
}
]
}
}
appIDs ist die Verkettung Ihrer Apple Team ID und der Bundle-Kennung Ihrer App, getrennt durch einen Punkt. Das Array components steuert, welche Pfade das App-Routing auslösen; alles, was zu keiner Komponente passt, fällt an den Browser durch. Sie können im Array details mehrere Apps registrieren - nützlich, wenn Sie eine Consumer- und eine Enterprise-Variante desselben Produkts auf derselben Domain haben.
Ein Detail, das ich klar sagen will: "/" mit einem Wildcard-Muster wie /spring-* ist ein Pfad-Präfix-Abgleich. Die Mustersyntax in derselben Referenz umfasst * (beliebiger Teilstring), ? (beliebiges einzelnes Zeichen) und Ausschluss-Objekte. Wollen Sie jeden Pfad der Domain abgleichen, nutzen Sie "/" : "/*". Wollen Sie einen bestimmten Pfad vom App-Routing ausschließen - etwa soll Ihre Seite /account/delete immer im Browser öffnen -, fügen Sie vor der Wildcard ein Ausschluss-Objekt ein:
{
"/": "/account/delete",
"exclude": true
}
Regeln werden von der ersten bis zur letzten ausgewertet, setzen Sie Ausschlüsse also vor Wildcards.
assetlinks.json
Die Digital-Asset-Links-Datei von Android liegt unter https://yourdomain.example/.well-known/assetlinks.json. Google dokumentiert das Format unter 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 ist die Application-ID Ihrer App im Play Store. sha256_cert_fingerprints enthält die SHA-256-Fingerprints des Signaturzertifikats Ihrer App (Googles Seite sagt, Mobile-App-Ziele würden über Zertifikats-Hash und Paketnamen identifiziert). Sie erhalten ihn über keytool -list -v -keystore your.keystore oder aus den Signatureinstellungen Ihrer Play Console, falls Play die App für Sie signiert. Führen Sie jedes Zertifikat auf, mit dem Builds installiert werden, auch Debug.
Anders als die AASA-Datei enthält die Android-Datei keine Pfadregeln. Der Pfadabgleich für App Links erfolgt in der AndroidManifest.xml über <intent-filter> mit android:pathPrefix, android:pathPattern. Die Datei assetlinks.json belegt den Domain-Besitz; das Manifest deklariert, welche Pfade die App bearbeitet.
Wie eine Short-Link-Domain hineinpasst
Ein Link wie go.acme.example/spring-launch ist nur eine URL auf einer Domain. Geben Sie go.acme.example die zwei Zuordnungsdateien und deklarieren Sie sie in der App, dann öffnet ein Tipp auf diesen Link die App auf Geräten, auf denen sie installiert ist. Das ist der Trick, und zugleich der Haken. Die App erhält https://go.acme.example/spring-launch, nicht die Seite, auf die der Link weiterleitet.
Ihr App-Code hat dann zwei Optionen. Erstens: den Pfad selbst abgleichen (/spring-launch bedeutet den Spring-Screen), was funktioniert, wenn Sie die Slugs kontrollieren. Zweitens: einen Server fragen, worauf der Short Link zeigt, und anhand der Antwort routen. Elido hat keinen dokumentierten Endpunkt, mit dem eine App einen Slug zu seinem Ziel auflösen kann. Der öffentliche Redirect antwortet nur mit einem 302. Heute ist die erste Option die verlässliche, und die Lücke steht in unserem Backlog.
Auf Geräten ohne die App, oder wenn der Tipp an einer Stelle geschieht, die Links nicht ans Betriebssystem übergibt, verhält sich der Short Link wie immer. Der Edge antwortet mit dem Redirect (standardmäßig 302; ein Link kann auf 301 oder 307 gesetzt werden), und der Browser folgt ihm. Die Targeting-Regeln von Elido können nach Betriebssystem abgleichen, sodass ein Link iOS-Besucher auf eine App-Store-Seite und Android-Besucher zu Google Play schicken kann, wenn die App nicht da ist.
Was Elido dafür heute kann und nicht kann, am Code geprüft:
| Fähigkeit | Status | Wo |
|---|---|---|
apple-app-site-association für eine eigene Domain ausliefern | Ja | JSON pro Domain im Dashboard einfügen |
assetlinks.json für eine eigene Domain ausliefern | Ja | Dasselbe Panel |
| 404 liefern, wenn für eine Domain keine Datei konfiguriert ist | Ja | Domains ohne App legen nichts offen |
| iOS- und Android-Besucher auf unterschiedliche URLs leiten | Ja | Targeting-Regeln (OS-Abgleich) |
| Deferred Deep Linking nach der Installation | Nein | SDK eines Anbieters nutzen |
| Install-Attribution pro Klick | Nein | Store-Konsolen oder ein Anbieter |
Elido speichert das JSON, das Sie verfassen, und liefert es unverändert unter den eigenen /.well-known/-Pfaden der Domain aus. Elido erzeugt Team ID, Bundle-ID oder Fingerprint des Signaturzertifikats nicht für Sie; diese stammen aus Ihrem Apple-Developer-Konto und Ihrem Signaturschlüssel. Die Einrichtung der Domain selbst (CNAME und TLS) ist dieselbe wie in Short Links mit eigener Domain, und die Deep-Links-Funktionsseite zeigt den Dashboard-Ablauf. Für Produktteams, die Short Links fürs Onboarding nutzen, deckt dieses Muster Einladungs- und Empfehlungslinks ab, ohne ein SDK in die Binärdatei aufzunehmen. Die Hälfte des Problems, bei der noch nichts installiert ist, adressieren auf iOS die App Clip Codes.
Was ein SDK weiterhin besser kann
Drei Dinge liegen außerhalb dessen, was Ihnen das Betriebssystem gibt.
Deferred Deep Linking. Ein Nutzer tippt vor der Installation. Das Betriebssystem hat keine App, der es die URL übergeben könnte, der Tipp geht also an den Browser, und die Absicht geht verloren. Anbieter holen sie mit probabilistischem Abgleich von Anfragedaten oder einer Zwischenablage-Übergabe zurück. Apples Tracking-Einwilligungsabfrage macht die Randfälle hässlich. Elido macht das heute nicht.
Install-Attribution. Ohne SDK sehen Sie Installationen weiterhin in App Store Connect und Play Console, können aber keine einem bestimmten Link-Tipp zuordnen. Relative Signale überleben: Führen Sie Smart-Link-Experimente durch und vergleichen Sie Installationen pro Kampagne. Attribution pro Gerät braucht einen Anbieter.
Identitätszusammenführung. Einen Tipp mit einer E-Mail-Adresse oder einem CRM-Kontakt zu verbinden ist ein Datenprojekt. Anbieter pflegen dafür einen Geräte-Graphen.
Wenn keines dieser drei zählt, genügen die Primitive des Betriebssystems. Zählt eines, beauftragen Sie den Anbieter nur für diese Aufgabe.
Konfigurations-Rezeptbuch
Drei Stellen müssen stimmen: der Server, das iOS-Projekt und das Android-Manifest.
HTTPS- und Pfadanforderungen
Liefern Sie beide Dateien über HTTPS mit einem Zertifikat aus, das zu einer öffentlichen Root-CA führt. Googles Seite zu Digital Asset Links sagt, die Statement-Liste "muss" unter /.well-known/assetlinks.json liegen, und Listen an anderen Orten oder unter anderen Namen seien nicht gültig (developers.google.com/digital-asset-links/v1/getting-started, abgerufen am 2026-10-24). Die Seite sagt nicht, ob Redirects befolgt werden, also liefern Sie die Datei direkt mit 200 aus und riskieren Sie es nicht. Derselbe Rat gilt für die Apple-Datei.
iOS: Associated-Domains-Entitlement
Fügen Sie in Xcode unter Signing & Capabilities die Capability Associated Domains mit dem Wert applinks:go.acme.example hinzu. Apple dokumentiert ein Suffix ?mode=developer für Entwicklungs-Builds, das das Gerät die Datei von Ihrem Server holen lässt, statt über Apples Cache zu gehen; ich konnte diese Seite am 2026-10-24 nicht erneut prüfen, bestätigen Sie es also in Apples Dokumentation. Verarbeiten Sie den eingehenden Link als Web-Browsing-Benutzeraktivität (SwiftUI onContinueUserActivity(NSUserActivityTypeBrowsingWeb) oder der UIKit-Delegate continue userActivity) und lesen Sie webpageURL.
Android: App Links im Manifest
Innerhalb der Activity, die Links bearbeiten soll:
<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 zieht für die automatische Verifizierung Filter mit der Aktion VIEW, beiden obigen Kategorien und einem Schema http oder https in Betracht. Auf Android 11 und früher macht das System Ihre App nur dann zum Standard-Handler, wenn es für jeden Host im Manifest eine Digital-Asset-Links-Datei findet, ein fehlerhafter Host bricht also alle. Auf einem Gerät kann zu einem Zeitpunkt nur eine App einer Domain zugeordnet sein.
Prüfen, ob es funktioniert
Geben Sie auf Android der Verifizierung nach der Installation mindestens 20 Sekunden, führen Sie dann adb shell pm get-app-links com.example.acme aus (Android 12 und später) und suchen Sie nach verified. Sie können einen neuen Lauf mit adb shell pm verify-app-links --re-verify com.example.acme erzwingen. Ergebnisse wie none, denied oder legacy_failure bedeuten, dass die Datei oder der Fingerprint falsch ist.
Für die Datei selbst listet Googles Digital Asset Links API die Statements auf, die sie für eine Site lesen kann: https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://go.acme.example&relation=delegate_permission/common.handle_all_urls. Eine leere Antwort bedeutet, dass Android die App nicht verifiziert.
Rufen Sie für beide Plattformen die Datei so ab, wie es ein Crawler täte:
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
Sie wollen ein 200 und einen JSON-Body. Elido sendet bei beiden Dateien application/json. Die üblichen Fehler sind ein Tippfehler in Team ID oder Bundle-ID, ein Release-Build, dessen Signaturzertifikat nicht in der Fingerprint-Liste steht, und eine Datei, die nur auf der Apex-Domain existiert, während die Links eine Subdomain nutzen.
Der Zielkonflikt, offen benannt
Das Weglassen des Deep-Link-SDK entfernt eine Abhängigkeit aus der App-Binärdatei und eine Datenweitergabe-Beziehung aus Ihrer Datenschutzerklärung. Eine Größenangabe nenne ich nicht; sie variiert je Anbieter, und ich habe keine gemessen. Der Preis: Ein Tipp vor der Installation lässt sich nicht der Installation zuordnen.
Beginnen Sie bei Teams in der Frühphase, bei denen die Kosten pro Installation je Kanal das Budget noch nicht steuern, mit den Primitiven des Betriebssystems und ergänzen Sie einen Attributions-Anbieter, wenn die Daten handlungsrelevant werden.
Weitere Beiträge im Blog
Häufig gestellte Fragen
Kann ich Deep Linking ohne Firebase oder ein SDK eines Drittanbieters umsetzen?
Ja, für den Fall, dass die App bereits installiert ist. iOS Universal Links und Android App Links brauchen eine Domain unter Ihrer Kontrolle, eine JSON-Zuordnungsdatei auf dieser Domain und ein paar Zeilen in der App. Die FAQ zu Firebase Dynamic Links von Google selbst verweist auf diese beiden Mechanismen als Option für Deep Linking in installierte Apps. Was Sie aufgeben, ist Deferred Deep Linking, also das Öffnen des richtigen Screens nach einer Neuinstallation.
Funktionieren Universal Links und App Links mit einer Short-Link-Domain?
Ja, wenn die Short-Link-Domain die Zuordnungsdateien ausliefert und die App diese Domain deklariert. Der Haken: Das Betriebssystem öffnet die App mit der angetippten Short-URL selbst, die App muss diese URL also in einen Screen umsetzen. Sie kann sich nicht darauf verlassen, dass der Redirect gelaufen ist. Ist die App nicht installiert, lädt derselbe Tipp im Browser, und der normale Redirect greift.
Wohin gehören die Zuordnungsdateien?
Android liest https://your-domain/.well-known/assetlinks.json, und die Dokumentation zu Digital Asset Links von Google sagt, dies sei der einzige gültige Ort. Apples Datei liegt unter https://your-domain/.well-known/apple-app-site-association ohne Dateiendung. Liefern Sie beide über HTTPS mit einem Zertifikat aus, das zu einer öffentlichen CA führt.
Warum zeigt meine Android-App eine Auswahl, statt direkt zu öffnen?
Direktes Öffnen braucht einen verifizierten App Link. Android prüft die Domain bei der Installation der App gegen assetlinks.json, und nur wenn ein Intent-Filter android:autoVerify="true" trägt. Fehlt die Datei, ist sie falsch oder führt ein anderes Signaturzertifikat als der installierte Build, verhält sich der Link wie ein normaler Deep Link.
Was ist Deferred Deep Linking, und kann ich darauf verzichten?
Deferred Deep Linking trägt das Ziel eines Links durch eine App-Installation, sodass ein Nutzer, der vor der Installation tippt, beim ersten Start trotzdem auf dem richtigen Screen landet. Universal Links und App Links bewirken in diesem Fall nichts, weil die App nicht da ist, um den Tipp zu empfangen. Sie können darauf bei Onboarding-Abläufen verzichten, in denen die Landung auf dem Startbildschirm genügt, und nur dann einen Anbieter dafür ergänzen, wenn das Routing beim ersten Start Ihre Zahlen bewegt.
Welche Teile davon übernimmt Elido?
Elido liefert die Dateien apple-app-site-association und assetlinks.json für eigene Domains aus, anhand von JSON, das Sie in den Domain-Einstellungen im Dashboard einfügen. Außerdem leitet es iOS- und Android-Besucher mit Targeting-Regeln an unterschiedliche Ziele. Deferred Deep Linking oder Install-Attribution bietet es nicht, nutzen Sie also ein SDK eines Anbieters, wenn Sie das brauchen.
Elido testen
URL einfügen, kurzer Link in Sekunden
Kein Konto nötig. Link bleibt 30 Tage aktiv. Konto erstellen, um ihn dauerhaft zu behalten.
Keine Anmeldung nötig. Kostenlos registrieren für 50 Links im Monat.