Deep Links für mobile Apps ohne SDK

Ein Deep Link ist einfach eine URL, die das Betriebssystem an eine App statt an einen Browser übergibt. Tippen Sie auf den Link auf einem Gerät, auf dem die App installiert ist, öffnet sich die App am richtigen Bildschirm. Tippen Sie auf einem Gerät ohne die App darauf, folgt der Browser dem Redirect zum Web-Fallback. Eine URL, zwei Ergebnisse, kein JavaScript-Shim, kein Drittanbieter-SDK für die meisten Setups erforderlich.

Teams kaufen hier routinemäßig zu viel ein. Branch.io, Adjust, AppsFlyer - ihre Marketingmaterialien werben mit Deferred Deep Linking: Man tippt auf den Link, bevor man die App installiert, installiert sie, und die App öffnet sich genau bei dem Inhalt, auf den man getippt hat. Dieses Feature ist tatsächlich komplex und erfordert einen serverseitigen Fingerprinting- oder Clipboard-Matching-Trick, da das OS-Link-Routing ruht, bis die App installiert ist. Aber Deferred Deep Linking ist nur ein Teil des Problems. Der häufigere Fall, „Link öffnet sich in der bereits installierten App“, wird vollständig durch OS-native Primitiven gelöst, die Apple und Google 2015 bzw. 2015–16 veröffentlichten und die mit nichts weiter als einer Domain, die Sie kontrollieren, und zwei JSON-Dateien funktionieren.

In diesem Beitrag geht es um diese zwei JSON-Dateien.

TL;DR#

• Apple Universal Links (iOS 9+) und Android App Links (Android 6.0+) handhaben den Flow „In App öffnen, wenn installiert, Web-Fallback wenn nicht“ ohne Drittanbieter-SDK.
• Beide erfordern eine Domain, die Sie kontrollieren, über HTTPS bereitgestellt, mit einer validierten Assoziationsdatei unter /.well-known/. Das OS ruft die Datei bei der App-Installation ab und speichert sie zwischen, nicht bei jedem Tippen.
• Ein URL-Shortener mit einer benutzerdefinierten Domain wie go.acme.example stellt beide Dateien bereit und wird zum Link, der das App-Routing auslöst - der Kurzlink ist der Deep Link.
• Was das SDK hinzufügt, was die OS-Primitiven nicht bieten: Deferred Deep Linking, probabilistische Installations-Attribution und plattformübergreifende Identitätszusammenführung. Wenn Sie diese benötigen, rechtfertigt das SDK seine Kosten. Wenn nicht, zahlen Sie für Funktionen, die Sie nicht nutzen.

Die OS-nativen Primitiven#

Apple führte Universal Links in iOS 9 (2015) ein. Android lieferte App Links in Android 6.0 Marshmallow (ebenfalls 2015, für Geräte bis 2016 veröffentlicht) aus. Beide folgen demselben konzeptionellen Modell: Das OS stellt eine verifizierte Beziehung zwischen einer Domain und einer App fest, und wenn eine URL auf dieser Domain angetippt wird, leitet das OS sie an die App statt an den Browser weiter.

Die Verifizierung ist gegenseitig und Offline-First. Bei der App-Installation ruft das OS eine Assoziationsdatei von Ihrer Domain ab und speichert sie zwischen. Apples Fetcher ist unter developer.apple.com/ios/universal-links/ (abgerufen am 12.05.2026) dokumentiert; das Äquivalent von Google findet sich unter developer.android.com/training/app-links (abgerufen am 12.05.2026). Keiner der Abrufe erfolgt zum Zeitpunkt des Tippens auf einem betriebsbereiten Gerät - der Cache bedeutet, dass die Routing-Entscheidung null Netzwerk-Roundtrips kostet.

Der Redirect selbst ist ein Standard-HTTP 302. Das OS fängt ihn ab, bevor der Browser lädt, prüft seinen lokalen Cache und übergibt die URL an die App, falls eine Übereinstimmung gefunden wird. Sobald der Cache gefüllt ist, erfolgt die gesamte Entscheidung lokal. Der Edge, der den Kurzlink bereitstellt, gibt den Redirect aus und das OS übernimmt.

Die zwei Dateien#

apple-app-site-association#

Die AASA-Datei muss unter https://yourdomain.example/.well-known/apple-app-site-association bereitgestellt werden (Apple prüft aus Gründen der Legacy-Kompatibilität auch den Apex-Pfad https://yourdomain.example/apple-app-site-association für ältere Systeme, aber der .well-known-Pfad ist der aktuelle Standard). Sie muss über HTTPS mit einer gültigen Zertifikatskette und mit einem Content-Type: application/json-Header bereitgestellt werden. Apples CDN-Fetcher lehnt Dateien ab, die mit dem falschen Content-Type bereitgestellt werden - dies ist einer der häufigsten Konfigurationsfehler in der Produktion.

Die vollständige Format-Referenz finden Sie unter developer.apple.com/documentation/xcode/supporting-associated-domains.

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-ID Ihrer App, getrennt durch einen Punkt. Das components-Array steuert, welche Pfade das App-Routing auslösen; alles, was nicht mit einer Komponente übereinstimmt, fällt auf den Browser zurück. Sie können mehrere Apps im details-Array registrieren - nützlich, wenn Sie eine Consumer- und eine Enterprise-Variante desselben Produkts auf derselben Domain haben.

Ein Detail, das man deutlich aussprechen sollte: "/" mit einem Wildcard-Muster wie /spring-* ist ein Pfadpräfix-Match. Apples AASA-Parser unterstützt eine Musternsyntax, die in der Xcode-Dokumentation definiert ist, einschließlich * (beliebiger Substring), ? (beliebiges Einzelzeichen) und Ausschluss-Objekten. Wenn Sie jeden Pfad auf der Domain abgleichen möchten, verwenden Sie "/" : "/*". Wenn Sie einen bestimmten Pfad vom App-Routing ausschließen möchten - sagen wir, Ihre /account/delete-Seite soll immer im Browser geöffnet werden - fügen Sie ein Ausschluss-Objekt vor dem Wildcard hinzu:

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

Regeln werden von vorne nach hinten ausgewertet. Platzieren Sie Ausschlüsse vor Wildcards.

assetlinks.json#

Androids Digital Asset Links Datei liegt unter https://yourdomain.example/.well-known/assetlinks.json. Die Spezifikation wird von Google unter developers.google.com/digital-asset-links/v1/getting-started gepflegt.

[
  {
    "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 ist der SHA-256-Fingerabdruck des Zertifikats, mit dem das APK signiert wurde - nicht der SHA-1, nicht der MD5. Sie finden den Fingerabdruck in der Play Console unter App Integrity oder indem Sie keytool -list -v -keystore your.keystore ausführen. Wenn Sie sowohl einen Debug- als auch einen Production-Build veröffentlichen, geben Sie beide Fingerabdrücke im Array an.

Im Gegensatz zur AASA-Datei unterstützt die Assoziationsdatei von Android keine Pfadfilterung auf Dateiebene. Der Pfad-Abgleich für App Links erfolgt in der AndroidManifest.xml über <intent-filter> mit android:pathPrefix, android:pathPattern oder dem neueren android:pathAdvancedPattern (verfügbar ab Android 12). Die assetlinks.json-Datei bestätigt den Domainbesitz; das Manifest deklariert, welche Pfade die App verarbeitet.

Wie ein URL-Shortener ins Bild passt#

Ein Kurzlink wie go.acme.example/spring-launch ist einfach eine URL auf einer Domain. Aus der Sicht des Betriebssystems ist jeder Tap auf einen Link unter dieser Domain für das App-Routing berechtigt, wenn go.acme.example eine gültige AASA- oder assetlinks.json-Datei hat.

Dies ist die Konfiguration, die wir direkt auf benutzerdefinierten Domains mit Elido unterstützen. Wenn Sie go.acme.example als benutzerdefinierte Domain in Ihrem Workspace registrieren, stellt Elido den HTTPS-Redirect für jeden Slug unter dieser Domain bereit. Sie stellen die zwei Assoziationsdateien von derselben Domain bereit - entweder auf Ihrem eigenen Origin hinter einem Pfad-Proxy oder über den HTTPS-Server der Domain selbst. Der Edge-Redirect wird ausgelöst; das OS fängt ihn ab, bevor der Browser lädt, konsultiert seinen AASA/App Links-Cache und öffnet die App, falls eine Übereinstimmung gefunden wird.

Die Architektur wird ausführlicher im Beitrag über benutzerdefinierte Domains für Kurzlinks beschrieben - das TLS-Ausstellen und das CNAME-Setup gelten hier genau wie dort beschrieben. Der Deep-Link-Layer ist additiv: gleiche Domain, gleicher Redirect, zwei JSON-Dateien obendrauf.

Für Produkt-Teams, die Kurzlinks für das mobile Onboarding nutzen - Empfehlungscodes, Einladungslinks, „Rezept teilen“-Flows - deckt dieses Muster fast alles ab, ohne SDK-Abhängigkeiten zum App-Binary hinzuzufügen.

Was das SDK hinzufügt#

Drei Fähigkeiten, die OS-native Primitiven nicht bieten:

Deferred Deep Linking. Ein Benutzer tippt auf Ihren Link, bevor er die App installiert. Beim ersten Start nach der Installation öffnet sich die App genau bei dem Inhalt, auf den er getippt hat. iOS Universal Links und Android App Links bleiben stumm, wenn die App nicht installiert ist - die URL geht zum Browser, die Absicht geht verloren. Die Wiederherstellung erfordert einen serverseitigen Fingerprint-Match (IP + User-Agent + Zeitstempel, probabilistisch) oder den iOS-Clipboard-Trick. Branch, Adjust und AppsFlyer implementieren diese; die Edge-Cases rund um App-Tracking-Transparency-Prompts und Safari-Verhalten machen es nicht trivial, dies selbst zu tun.

Installations-Attribution in großem Maßstab. Die OS-native Route gibt Ihnen den App-Start mit dem URL-Pfad, aber wenn die App beim ersten Tippen nicht installiert war, ist die Attributionskette unterbrochen. Der Abgleich von Klicks gegen Installationen über SKAN auf iOS und Play Install Referrer auf Android ist ohne kostenpflichtiges SDK machbar, erfordert aber Integrationsarbeit, die die Attributionsanbieter bereits erledigt haben.

Plattformübergreifende Identitätszusammenführung. Verknüpfung eines Taps mit einer E-Mail-Adresse, einem CRM-Kontakt oder einer Web-Sitzung. Der OS-native Pfad ist aus Sicht des Link-Dienstes anonym. SDK-Anbieter pflegen einen dauerhaften Geräte-Graphen. Das selbst zu bauen, ist ein umfangreiches Dateninfrastrukturprojekt.

Wenn keine dieser drei Punkte zutrifft, decken die OS-Primitiven Ihre Anforderungen ab. Wenn einer wichtig ist, grenzen Sie ihn genau ab - vielleicht benötigen Sie nur Deferred Deep Links, eine API-Oberfläche, nicht das volle SDK.

Konfigurations-Kochbuch#

DNS- und HTTPS-Anforderungen#

Beide Dateien müssen über HTTPS von der Domain bereitgestellt werden, deren Links Sie per Deep Link verknüpfen möchten. Das Zertifikat muss zu einer öffentlichen Root-CA führen; selbstsignierte Zertifikate führen dazu, dass sowohl Apples als auch Googles Validierungs-Fetcher lautlos fehlschlagen. Let's Encrypt-Zertifikate funktionieren einwandfrei.

Das TLS der Domain darf den /.well-known/-Pfad auch nicht umleiten, bevor die Datei bereitgestellt wird. Wenn Ihr Server einen www.-Redirect ausgibt, bevor der Apple-Fetcher https://yourdomain.example/.well-known/apple-app-site-association erreichen kann, schlägt der Abruf fehl. Apples Fetcher folgt bis zu einem Redirect, aber Googles assetlinks-Fetcher folgt überhaupt keinen Redirects - die Datei muss genau an diesem Pfad liegen, kein Redirect.

iOS: Associated Domains Entitlement#

In Xcode fügen Sie unter den „Signing & Capabilities“ Ihres Targets das „Associated Domains“ Entitlement mit dem Wert applinks:go.acme.example hinzu. Wenn Sie mit einem Development-Build testen (nicht über TestFlight oder den App Store verteilt), fügen Sie ?mode=developer zum Entitlement-Wert hinzu: applinks:go.acme.example?mode=developer. Dies weist das OS an, die AASA bei jedem Start neu abzurufen, anstatt den Installationszeit-Cache zu verwenden - nützlich, um an Ihren Pfadmustern zu iterieren, ohne jedes Mal neu aus dem Store zu installieren.

Das Apple CDN, das Ihre AASA-Datei abruft, ist Apples eigene Infrastruktur, nicht das Gerät selbst. Apple ruft AASA-Dateien von Ihrer Domain im Voraus ab, speichert sie zwischen und stellt sie Geräten während der App-Installation bereit. Das bedeutet, dass die Datei für Apples Crawler erreichbar sein muss, nicht nur für das Gerät des Endbenutzers. Dies bedeutet auch, dass es eine Verzögerung bei der Ausbreitung gibt - Änderungen an Ihrer AASA-Datei können Stunden dauern, bis sie alle Geräte über Apples Cache erreichen. Für Entwickler, die eine schnelle Iteration bei Pfadmustern benötigen, umgeht das ?mode=developer Entitlement das Apple CDN und ruft direkt von Ihrem Server ab.

Android: App Links im Manifest#

In der AndroidManifest.xml, innerhalb der Activity, die Deep Links verarbeiten 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:autoVerify="true" weist Android an, die Verifizierung der Domain gegen assetlinks.json zu versuchen. Ohne dies sieht der Benutzer bei jedem Tippen ein Auswahlmenü (Disambiguation Sheet), anstatt dass sich die App direkt öffnet. Die Verifizierung erfolgt bei der Installation; das Gerät kontaktiert https://go.acme.example/.well-known/assetlinks.json und prüft, ob der Zertifikatsfingerabdruck der installierten App aufgeführt ist.

Validatoren und häufige Fehler#

Apple stellt einen Validator unter search.developer.apple.com/appsearch-validation-tool/ zur Verfügung, der prüft, ob Apples CDN Ihre AASA-Datei abrufen und parsen kann. Geben Sie Ihre Domain ein und er liefert entweder ein gültiges Parse-Ergebnis oder einen spezifischen Fehler. Häufige Fehler:

• Falscher Content-Type. Wenn Ihr Server text/plain oder application/octet-stream zurückgibt, meldet der Validator die Datei als unlesbar, selbst wenn das JSON gültig ist. Setzen Sie Content-Type: application/json explizit.
• Fehlende oder nicht übereinstimmende appIDs. Das Team-ID-Präfix in appIDs muss exakt mit der Team-ID in Ihrem Apple Developer Account übereinstimmen, einschließlich Groß-/Kleinschreibung. Ein einziges falsches Zeichen führt beim Tippen lautlos zum Fehlschlag.
• Problem mit der Zertifikatskette. Wenn Ihre Domain ein Zertifikat bereitstellt, das nicht zu einem öffentlichen Root führt (häufig in Staging-Umgebungen mit lokalen CA-Roots), lehnt Apples Fetcher die Datei ab.

Googles Validator ist die Digital Asset Links API: https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://go.acme.example&relation=delegate_permission/common.handle_all_urls. Die JSON-Antwort listet alle Statements auf, die Google für Ihre Domain verifiziert hat. Wenn die Antwort leer ist oder Ihr Paketname fehlt, wird Android die App bei der Installation nicht automatisch verifizieren. Häufige Fehler:

• Redirect auf dem assetlinks-Pfad. Wie erwähnt: Googles Fetcher folgt keinen Redirects.
• Falscher Zertifikatsfingerabdruck. Das Debug-APK und das Release-APK sind mit unterschiedlichen Schlüsseln signiert. Wenn Sie nur den Release-Fingerabdruck aufgeführt haben, werden Debug-Builds nicht verifiziert. Listen Sie beide auf.
• Datei mit CORS bereitgestellt, aber falscher Header für die Verifizierungsanfrage. Den Fetcher kümmert CORS nicht, aber einige CDN-Konfigurationen geben 403 bei einem GET aus einem Google-IP-Bereich zurück, wenn der Pfad nicht in der Cache-Allowlist steht. Überprüfen Sie, ob /.well-known/assetlinks.json von einem externen HTTP-Client den Status 200 zurückgibt, nicht nur von Ihrem Browser.

Die Abwägung auf den Punkt gebracht#

Das Entfernen des Deep-Link-SDKs spart etwa 150–250 KB komprimierte Binärgröße ein und eliminiert einen API-Aufruf pro Installation an die Server des Attributionsanbieters. Das entfernt eine Datenaustauschbeziehung aus Ihrer Datenschutzrichtlinie und kann die DSGVO-Datenverarbeitungsverzeichnisse vereinfachen. Echte Gewinne, wenn auch bescheiden.

Die Kosten bestehen darin, dass die Attributionsdaten zum Installationszeitpunkt ungenau werden oder fehlen. Wenn ein Benutzer auf Ihren Link tippt, bevor er die App installiert, sehen Sie die Installation in App Store Connect oder in der Play Console, können sie aber nicht dem spezifischen Link-Tap zuordnen. Sie können immer noch Smart Link-Experimente durchführen, um zu vergleichen, welche Kampagnen mehr Installationen generieren - relative Signale bleiben erhalten -, aber die Attributionsdaten pro Gerät und pro Klick erfordern den SDK-Fingerprinting-Layer.

Für Teams in einer frühen Phase, in der der CPI pro Kanal noch keine Budgetentscheidungen steuert, ist der Start mit OS-Primitiven der vernünftige Weg. Fügen Sie später ein Attributions-SDK hinzu, wenn die Daten tatsächlich handlungsrelevant sind.

Der Leitfaden für Entwickler zur Deep-Link-Konfiguration von Elido, das vollständige Schema für den Domain-Verifizierungsflow, die AASA-Proxy-Konfiguration und die Bereitstellungsoptionen für assetlinks.json sind dort dokumentiert. Die Lösungsseite für Produkt-Teams deckt die breiteren Anwendungsfälle für Smart Links und mobiles Verlinken ab.

Marius Voß ist DevRel + Edge-Infra bei Elido. Er ist verantwortlich für die Dienste edge-redirect und domain-manager.