Deeplinks unter iOS und Android: ein Praxisleitfaden

Ein Deeplink ist eine URL, die einen bestimmten Bildschirm in einer installierten App öffnet statt einer Webseite. Das ist die ganze Idee, und sie wurde über fünfzehn Jahre hinweg auf drei verschiedene Arten umgesetzt, jede mit eigenen Fehlerbildern. Dass Marketing-Teams dazu immer wieder Bugs melden, liegt daran, dass alle drei nach wie vor nebeneinander existieren und sich dieselbe URL unterschiedlich verhalten kann — je nachdem, ob sie in einer Nachricht, einem Browser, einem E-Mail-Programm oder in einem eingebetteten Webview innerhalb einer Social-App angetippt wurde.

Dieser Leitfaden erklärt die Mechanismen ehrlich, einschließlich dessen, was sie nicht leisten können. Wenn Sie nur eines mitnehmen, dann dies: Einen Klick auf den richtigen App-Bildschirm zu leiten ist gelöste Infrastruktur; einen Nutzer nach der Installation der App auf den richtigen Bildschirm zu leiten ist es nicht — jedenfalls nicht durch die Link-Plattform allein.

Die drei Generationen der App-Verlinkung

Eigene URL-Schemata

Der ursprüngliche Mechanismus. Eine App registriert ein Schema wie myapp, und eine URL der Form myapp://product/42 übergibt die Anfrage an sie. Schemata sind trivial umzusetzen und als internes Routing-Format weiterhin nützlich, sie bringen aber zwei strukturelle Probleme mit.

Es gibt keine Eigentumsprüfung: Jede App kann jedes Schema registrieren, und beanspruchen zwei Apps dasselbe, ist die Auflösung unter iOS undefiniert und unter Android ein Auswahldialog. Und es gibt keine Rückfallebene: Auf einem Gerät ohne installierte App erzeugt eine Schema-URL eine Fehlerseite oder überhaupt nichts, jeder Schema-Link braucht also eine Hülle, die das Scheitern erkennt und den Nutzer irgendwohin schickt, wo es weitergeht. Genau diese Hülle ist das fragile Stück, das kaputtging, als Browser den Umgang mit Navigations-Timern verschärften.

Universal Links unter iOS

Apples Nachfolger arbeitet mit gewöhnlichen HTTPS-URLs. Ihre App deklariert ein Associated-Domains-Entitlement der Form applinks:yourbrand.com, und die Domain veröffentlicht unter /.well-known/apple-app-site-association eine JSON-Datei, die beschreibt, welche Pfade zur App gehören.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

Die Datei muss über HTTPS ohne Weiterleitungen, als JSON und unter genau diesem Pfad ausgeliefert werden. iOS holt sie rund um Installation und Update ab, größtenteils über Apples CDN — Änderungen wirken also nicht sofort. Der Gewinn ist, dass dieselbe URL überall funktioniert: Ist die App installiert und passt der Pfad, öffnet sie sich; sonst lädt Safari die Webseite. Einen Fehlerzustand gibt es nicht.

App Links unter Android

Das Android-Gegenstück nutzt eine Digital-Asset-Links-Datei unter /.well-known/assetlinks.json, die das App-Paket und den SHA-256-Fingerprint des Signaturzertifikats nennt.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

Auf App-Seite wird ein Intent-Filter für die Domain deklariert, mit eingeschalteter automatischer Verifizierung. Gelingt die Verifizierung, öffnet der Link die App ohne Auswahldialog. Scheitert sie, öffnet der Link den Browser — und die mit Abstand häufigste Ursache ist ein nicht passender Fingerprint: Teams veröffentlichen den Fingerprint ihres lokalen Release-Schlüssels, während Play App Signing die App mit einem anderen neu signiert. In die Datei gehört der Fingerprint, den der Store für das ausgelieferte Artefakt anzeigt.

Wie ein Kurzlink sein Ziel wählt

Ein Kurzlink ist ein Entscheidungspunkt und kein fester Zeiger, und genau das macht ihn für App-Kampagnen nützlich: Ein einziger gedruckter Code kann iPhone-Nutzer, Android-Nutzer und Desktop-Besucher unterschiedlich bedienen, und die Entscheidung lässt sich noch ändern, nachdem der Code gedruckt ist.

Die Weiterleitungsmaschine sieht den User Agent der Anfrage, die mitgeschickten Client Hints und aus dem Netzwerk abgeleitete Signale wie das Land. Ein für App-Traffic eingerichteter Link hält typischerweise drei Ziele bereit: eine iOS-URL, eine Android-URL und eine Web-URL für alles Übrige. Darüber gelegt können Targeting-Regeln nach Land, Gerät, Betriebssystem oder Sprache routen — eine Kampagne kann also kanadischen Android-Traffic auf ein Ziel schicken und alle anderen auf ein zweites, ohne getrennte Links anzulegen.

Zwei Umsetzungsdetails lohnt es zu kennen, weil sie den größten Teil des verwirrenden Verhaltens erklären.

Das erste sind Social-Crawler. Fordert ein Bot wie der Abrufdienst von Facebook oder Telegram einen Link an, um eine Vorschaukarte zu bauen, antwortet eine korrekte Weiterleitungsmaschine mit den Vorschau-Metadaten — statt die Anfrage als Klick zu zählen und statt sie zu routen, als käme sie von einem Handy. Wenn Ihre Klickzahlen in dem Moment ausschlagen, in dem ein Link veröffentlicht wird, und bevor ihn irgendjemand angetippt hat, tut die Maschine genau das nicht.

Das zweite ist die Grenze der Domainverknüpfung, und das ist der wichtigste technische Punkt dieses Artikels. Universal Links werden gegen die Domain der URL geprüft, die der Nutzer tatsächlich angetippt hat. Tippt jemand go.yourbrand.com/p/42 an und antwortet diese Domain mit einer Weiterleitung auf yourbrand.com/p/42, behandelt iOS das Weiterleitungsziel nicht als verknüpften Link — die App öffnet sich also nicht. Damit ein Kurzlink die App nativ öffnet, muss die Association-Datei auf der Kurzdomain selbst ausgeliefert werden. Wo das nicht möglich ist, bleibt als praktische Rückfallebene die Übergabe an ein eigenes Schema oder direkt an den Store, und genau das tun die meisten Deeplink-Funktionen von Shortenern tatsächlich. Fragen Sie jeden Anbieter, welchen der beiden Wege er umsetzt, denn die Marketingtexte lesen sich in beiden Fällen gleich.

Die Kette der Rückfallebenen

Ein funktionierender App-Link ist in Wahrheit ein kleiner Entscheidungsbaum, und jeder Zweig braucht eine bewusste Antwort.

| Situation | Was passieren sollte | Häufiger Fehler | | --- | --- | --- | | App installiert, Pfad erkannt | App öffnet sich auf dem Zielbildschirm | Weiterleitungskette zerstört die Verknüpfung | | App installiert, Pfad nicht erkannt | Webseite lädt, App wird vorgeschlagen | Auswahldialog bei jedem Antippen | | App nicht installiert, mobil | Store-Seite der passenden Plattform | Store-Link fest auf eine Plattform verdrahtet | | Desktop | Vollwertiges Web-Äquivalent des Bildschirms | Landung auf einer allgemeinen Startseite | | Social-Crawler | Vorschau-Metadaten, kein gezählter Klick | Vorschau-Abruf bläht die Analytics auf |

Richten Sie den Store-Zweig auf den jeweils plattformrichtigen Eintrag statt auf einen einzigen Link, und halten Sie den Web-Zweig wirklich gleichwertig zum App-Bildschirm. Ein großer Teil des Traffics aus App-Kampagnen landet im Web-Zweig, egal wie gut der Rest konfiguriert ist — ihn als Sackgasse zu behandeln verbrennt den größten Teil des Budgets.

Die Installationsgrenze, ehrlich betrachtet

Hier gehen Anbietermarketing und Wirklichkeit auseinander. Nehmen wir an, ein neuer Nutzer tippt einen Link zu einem bestimmten Produkt an, hat die App nicht, landet im Store, installiert sie und öffnet sie. Die App zeigt jetzt ihren Standard-Startbildschirm, weil nichts die Produktkennung über die Installation hinweg getragen hat. Das zum Laufen zu bringen heißt Deferred Deep Linking, und es ist nichts, was eine Link-Plattform allein leisten kann.

Es braucht ein SDK in der App, das beim ersten Start einen Server fragt, was der Nutzer vor der Installation angetippt hat. Der Server muss die beiden Ereignisse einander zuordnen, und die Signale, die für diese Zuordnung zur Verfügung stehen, sind stark schmaler geworden. Geräte-Fingerprinting ist unzuverlässig und wird von den Plattformrichtlinien zunehmend eingeschränkt. Werbekennungen setzen eine Einwilligung voraus, die die meisten Nutzer verweigern. Apples Attributions-Frameworks melden Werbetreibenden eine Zuordnung auf Installationsebene, statt Ihrer App einen Pfad zu übergeben. Die Zwischenablage-Technik, die früher ein Token transportierte, löst heute eine sichtbare Einfüge-Benachrichtigung aus.

Was bleibt, funktioniert — aber es ist ein anderes Produkt mit anderem Integrationsaufwand: ein SDK eines Mobile Measurement Partners, eine Initialisierung in der App und ein Zuordnungsfenster, das probabilistisch statt exakt ist. LinkProfit routet Klicks je Gerät und übergibt an den Store, beansprucht aber kein Routing nach der Installation, denn es sauber zu machen heißt, Code in Ihrer App auszuliefern. Ist verzögertes Routing eine harte Anforderung, planen Sie dieses SDK neben Ihrer Link-Plattform ein und nicht an ihrer Stelle.

Webviews und andere praktische Fallen

In-App-Browser

Die meisten Links, die in Social-Apps angetippt werden, öffnen sich in einem eingebetteten Webview statt im Systembrowser, und Webviews behandeln die App-Verknüpfung uneinheitlich: Manche ignorieren Universal Links, manche blockieren eigene Schemata, und das Verhalten unterscheidet sich zwischen App-Versionen. Das ist der häufigste Grund dafür, dass ein Link, der im Test einwandfrei funktioniert, im Produktivbetrieb die Website öffnet — denn getestet wird meist, indem man einen Link in einer Messenger-App antippt, und die verhält sich korrekt.

Es gibt keine Einstellung, die das global behebt. Was hilft, ist ein gutes Webziel, ein sichtbares Bedienelement „In App öffnen“ darauf und das einzelne Testen jedes Veröffentlichungskanals, statt anzunehmen, dass sie sich gleich verhalten.

Fehler an der Association-Datei

Vier davon wiederholen sich. Die Association-Datei über eine Weiterleitung auszuliefern — auch die automatische Weiterleitung von der Apex-Domain auf www zählt dazu und macht sie ungültig. Sie mit falschem Content-Type oder von einem Pfad auszuliefern, den ein Framework umschreibt. Den falschen Android-Signatur-Fingerprint zu veröffentlichen, wie oben beschrieben. Und zu vergessen, dass iOS die Datei zwischenspeichert — eine Korrektur kann also einen Tag oder länger brauchen, bis sie Geräte erreicht, auf denen die App bereits installiert ist.

Analytics im App-Zweig

Sobald ein Klick in eine App übergeht, sehen ihn Ihre Web-Analytics nicht mehr, und genau hier zerfällt das Reporting still und leise. Belassen Sie die Kampagnenparameter am Link, damit die Weiterleitungsmaschine sie mitschreibt, und reichen Sie eine Kennung an das App-Ziel durch, damit sich die Session in der App mit dem Klick verbinden lässt. Unser Leitfaden zum Messen von Klicks auf Links behandelt, was ein Klick-Event preisgeben kann und was nicht, und dieselben Vorbehalte zu Bots und eindeutigen Besuchern gelten auch hier.

Testen vor der Veröffentlichung

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

Die ersten beiden Befehle sollten 200 ohne Weiterleitung zurückgeben. Beachten Sie, dass ein Universal Link, den man in Safaris Adresszeile eintippt, die App bewusst nicht öffnet — testen Sie also aus einer Notiz, einer Nachricht oder mit dem Simulator-Befehl heraus, sonst jagen Sie einen Fehler, den es gar nicht gibt.

Was Link-Plattformen tatsächlich enthalten

Die Unterstützung für Deeplinks ist in dieser Kategorie sehr unterschiedlich verpackt, und die Unterschiede betreffen den Tarif, den Sie kaufen müssen, und nicht den Funktionsumfang.

| Anbieter | Verfügbarkeit von Deeplinks, Stand August 2026 | | --- | --- | | BL.INK | Alle Tarife, Einstiegstarif 48 Dollar im Monat für einen Nutzer und eine Domain | | Short.io | Ab dem Team-Tarif für 48 Dollar im Monat | | Rebrandly | Ab dem Growth-Tarif für 99 bis 119 Dollar im Monat | | Switchy | Beworbene Unterstützung für mehr als 130 Apps | | LinkProfit | Geräteabhängige Ziele in allen Tarifen |

BL.INK ist hier der ehrliche Maßstab: Deeplinks in jeder Stufe zu enthalten ist ungewöhnlich, auch wenn der Einstiegspreis für eine einzelne Domain hoch ist. Rebrandlys Einordnung auf Growth ist das Muster, auf das man allgemein achten sollte, denn die Stufe, die Sie für eine einzige Funktion brauchen, bestimmt am Ende meist die ganze Rechnung.

Eine Einführungsreihenfolge, die funktioniert

1. Legen Sie für jeden App-Bildschirm, auf den Sie verlinken wollen, die kanonische Web-URL fest; die Webseite ist die Rückfallebene und die maßgebliche Quelle.
2. Veröffentlichen Sie beide Association-Dateien auf der Domain, die in den Links auftauchen wird, und prüfen Sie sie über HTTPS ohne Weiterleitungen.
3. Ergänzen Sie unter iOS das Associated-Domains-Entitlement und unter Android den verifizierten Intent-Filter, mit dem Fingerprint des ausgelieferten Builds.
4. Klären Sie, auf welcher Domain Ihre Kurzlinks angetippt werden und ob die Verknüpfung dort liegt oder die Plattform an ein Schema oder den Store übergibt.
5. Konfigurieren Sie an jedem Link geräteabhängige Ziele plus eine Web-Rückfallebene, mit dem richtigen Store-Eintrag je Plattform.
6. Testen Sie auf beiden Plattformen aus einer Messenger-App, aus dem Systembrowser und aus jeder Social-App heraus, in der Sie veröffentlichen.
7. Prüfen Sie, dass Kampagnenparameter die Weiterleitung überstehen und in der Analytics erfasst werden.
8. Automatisieren Sie das Anlegen über die API, wenn Links je Kampagne, je Empfänger oder je Produkt erzeugt werden.

Nichts davon ist für sich genommen schwierig. Die Schwierigkeit ist, dass die Teile an drei Orten liegen — im App-Projekt, in der DNS-Zone und in der Link-Plattform — und meist drei verschiedenen Personen gehören. Aufzuschreiben, wer von ihnen die Association-Datei verantwortet, ist mehr wert als jeder einzelne Konfigurationstipp in diesem Artikel.