Ein QR-Code für App Store und Google Play: automatische Weiterleitung nach Gerät

Ein QR-Code, zwei App Stores: iPhone-Nutzer in den App Store, Android-Nutzer zu Google Play leiten

Jede Agentur, die eine App-Install-Kampagne betreut, stößt früher oder später auf dasselbe kleine, ärgerliche Problem. Der Kunde hat seine App sowohl im App Store als auch bei Google Play, gedruckt wird aber nur ein Poster, ein Flyer, ein Aufkleber an der Kasse, und der QR-Code darauf kann nur auf eine einzige URL zeigen. Die übliche Lösung: zwei Codes nebeneinander drucken, mit "iPhone" und "Android" beschriften und hoffen, dass die Kundschaft den richtigen wählt. Das funktioniert, wirkt aber unprofessionell, verschwendet die Hälfte der Druckfläche und bürdet ausgerechnet den Menschen, die einfach nur eine App herunterladen wollen, die Aufgabe der Selbstauswahl auf.

Ein einziger QR-Code kann diese Weiterleitung stattdessen selbst übernehmen. Dieser Artikel erklärt, wie geräteabhängige Weiterleitung unter der Haube funktioniert, wo sie sich mit Apples eigenen Smart App Banners und den App Links von Android überschneidet (und wo eben gerade nicht), warum ein Tool, das viele Agenturen genau für diesen Zweck genutzt haben, 2025 verschwunden ist, und wie Sie das Ganze mit einem dynamischen QR-Code einrichten, ohne selbst einen kompletten App-Linking-Stack zu programmieren.

Warum Agenturen für eine App am Ende zwei QR-Codes drucken

App Store und Google Play sind getrennte Systeme mit unterschiedlichen URL-Formaten. Ein App-Store-Eintrag liegt unter einer URL wie apps.apple.com/us/app/instagram/id389801252, ein Google-Play-Eintrag unter play.google.com/store/apps/details?id=com.instagram.android. Weder Apple noch Google veröffentlicht eine einzige "smarte" URL, die je nach Anfragendem automatisch zum richtigen Store führt. Diese Lücke ist real, kein Versehen, das einer der beiden Konzerne einfach vergessen hätte zu schließen, und genau deshalb gibt es einen ganzen Markt an Link-Weiterleitungstools, der sie füllt.

Der QR-Code selbst hat dazu keine Meinung. Er kodiert lediglich eine URL, und ein Scanner öffnet diese URL. Die eigentliche Intelligenz muss woanders sitzen: an der URL, auf die der Code zeigt. Das ist der ganze Trick, und es lohnt sich, hier präzise zu sein, denn der Begriff "smarter QR-Code" wird oft so verwendet, als würde der Code selbst etwas Cleveres tun. Das tut er nicht. Der Code ist statische Information. Der Redirect, auf den er zeigt, entscheidet, wo die besuchende Person landet, und diese Entscheidung fällt anhand eines einzigen HTTP-Headers.

So funktioniert geräteabhängige QR-Weiterleitung in der Praxis

Wenn ein Smartphone eine Webseite anfragt, sendet es einen User-Agent-Header, der den Browser und meist auch das Betriebssystem identifiziert. Ein Redirect-Dienst liest diesen Header serverseitig aus, bevor überhaupt etwas gerendert wird, und schickt einen 301- oder 302-Redirect zum richtigen Ziel. iPhones und iPads melden Zeichenketten mit "iPhone" oder "iPad", Android-Geräte melden "Android". Eine serverseitige Regel, so simpel wie "enthält der UA iPhone oder iPad, weiterleiten zur App-Store-URL; enthält er Android, weiterleiten zur Play-Store-URL; sonst weiterleiten auf eine normale Web-Landingpage", macht tatsächlich den Großteil der Implementierung aus.

Es gibt keine veröffentlichte Spezifikation von Apple, Google oder dem W3C, die diese Teilstrings als verbindlichen, dauerhaft garantierten Vertrag festschreibt. Es handelt sich um beobachtete, stabile und weit verbreitete Praxis, nicht um eine API. In der Praxis hat sich das über Jahre als zuverlässig erwiesen, weil beide Unternehmen ein starkes Eigeninteresse daran haben, ihre Browser identifizierbar zu halten (die App-Kompatibilität im gesamten Web hängt davon ab). Trotzdem lohnt es sich, den Fallback-Pfad sauber zu bauen, statt davon auszugehen, dass die Erkennung immer perfekt funktioniert.

Was der User-Agent-Header dem Redirect verrät, und was nicht

Der Header verrät zuverlässig die Plattform-Familie (iOS-artig gegenüber Android gegenüber weder noch). Die genaue Betriebssystemversion verrät er heute deutlich unzuverlässiger. Apple friert den Detailgrad des Safari-User-Agent-Strings seit Safari 11.1 zunehmend ein und hat diesen Trend mit iOS 26 fortgesetzt: Aus Datenschutzgründen wird eine statische, weniger spezifische OS-Versionsangabe gemeldet. Das bricht die Unterscheidung zwischen iPhone und Android, die Ihr Redirect braucht, nicht, da sich das Plattform-Token selbst nicht ändert. Es bedeutet aber, dass Sie nichts entwerfen sollten, das darauf angewiesen ist, allein aus dem Header die genaue iOS-Version zu kennen.

Der Header kann außerdem von datenschutzorientierten Browsern und Browser-Erweiterungen gefälscht, entfernt oder verändert werden. Das ist kein Grund, auf dieses Muster zu verzichten (es ist gängige Praxis in der gesamten Link-in-Bio- und App-Marketing-Branche), aber ein guter Grund, das Fallback-Ziel wirklich nützlich zu gestalten statt es zur Sackgasse zu machen, da ein kleiner Prozentsatz der Besucher dort zufällig landet.

Was auf dem Desktop oder bei einem nicht erkannten Gerät passiert

Das ist der Teil, den Anbieterseiten routinemäßig auslassen, und genau der Teil, der letztlich darüber entscheidet, ob die Kampagne funktioniert. Ein QR-Code auf Verpackungen, einem Flyer oder im Schaufenster wird gelegentlich von einer Laptop-Kamera, einem iPad im Desktop-Modus oder einer Scanner-App gescannt, die identifizierende Header entfernt. Leiten Sie diesen Traffic zu einem Store-Badge, landet er in einer Sackgasse: Ein "App Store" existiert in einem Desktop-Browser schlicht nicht. Das Fallback sollte eine normale Webseite sein, idealerweise die Marketingseite der App mit beiden Store-Badges als gewöhnliche Links, damit niemand vor einer Wand steht. Diese Fallback-Seite zu bauen dauert zehn Minuten und macht aus einem Randfall ein Nicht-Problem.

Warum das nicht dasselbe ist wie Apples Smart App Banner

Apple hat bereits einen eigenen Mechanismus, um Safari-Besuchern eine App vorzuschlagen: den Smart App Banner, eingebunden über einen einzigen Meta-Tag, <meta name="apple-itunes-app" content="app-id=YOUR_ID, app-argument=YOUR_URL">, im Head der Seite platziert. Er ist wirklich nützlich und wird nach wie vor vollständig unterstützt. Er löst jedoch ein anderes Problem als das, um das es in diesem Artikel geht, und wer beides vermischt, baut sich fehlerhafte Setups.

Der Smart App Banner erscheint nur, wenn Safari die getaggte Seite tatsächlich rendert und ein Besucher dort verweilt. Er erscheint nicht innerhalb eines In-App-Browsers (der Webview, in der Instagram, TikTok oder Facebook Links öffnen), er erscheint nicht in einem iFrame, und entscheidend für QR-Kampagnen: Er bekommt gar keine Chance zu erscheinen, wenn Ihr Redirect die besuchende Person per serverseitigem 301 sofort weiterleitet, bevor Safari die Seite überhaupt fertig geladen hat. Ein QR-Code, der direkt zum App Store weiterleitet, zeigt Safari die getaggte Seite nie an, weshalb der Banner für diesen Ablauf strukturell irrelevant ist. Der Banner ist für eine andere Reise gedacht: jemand, der Ihre Website direkt in Safari besucht und sich entscheidet, kurz dort zu bleiben. Geräteabhängige QR-Weiterleitung ist für jemanden gedacht, der einen Code mit einer einzigen, klaren Absicht gescannt hat (die App herunterladen) und direkt dorthin geschickt werden sollte.

Die Lücke, die Firebase Dynamic Links hinterlassen hat

Wenn Ihre Agentur in den letzten zehn Jahren App-Install-QR-Flows gebaut hat, ist die Wahrscheinlichkeit hoch, dass Sie dafür Firebase Dynamic Links genutzt haben, um genau diese Art von Weiterleitung umzusetzen. Google kündigte die Einstellung im August 2023 an, setzte die Konsole ab dem 24. Mai 2024 auf reinen Lesezugriff und stellte den Dienst am 25. August 2025 vollständig ein: Jede page.link- und jede benutzerdefinierte Dynamic-Links-Domain liefert seither nichts mehr zurück. Als Begründung nannte Google, dass die nativen Alternativen (Universal Links, App Links und neuere Mechanismen) inzwischen ausgereift genug seien, sodass ein eigenständiges, plattformübergreifendes Smart-Link-Produkt nicht mehr nötig sei.

Für Agenturen, die sich darauf verlassen haben, entsteht dadurch eine echte Lücke, und genau das ist ein Grund, das Thema jetzt sauber zu lösen, statt auf irgendein halbfertiges Skript zurückzugreifen, das gerade noch läuft. Ein dynamischer QR-Code, der auf einen Redirect-Endpunkt zeigt, den Sie selbst kontrollieren, umgeht diese Abhängigkeit vollständig: Sie sind nicht darauf angewiesen, dass ein Smart-Link-Produkt eines Drittanbieters weiterexistiert, sondern darauf, dass eine URL, die Ihnen gehört, eine einzige, einfache Aufgabe erfüllt.

Universal Links und App Links: Menschen weiterleiten, die die App schon haben

Alles bisher Genannte dreht sich darum, jemanden ohne die App zum richtigen Store-Eintrag zu bringen. Ein separater, verwandter Mechanismus deckt den Fall ab, dass die App bereits installiert ist: Universal Links unter iOS und App Links unter Android lassen eine URL direkt in der installierten App öffnen statt im Browser und überspringen den Store komplett. Dafür ist eine Verifizierungsdatei nötig (apple-app-site-association unter iOS, eine Digital-Asset-Links-Datei unter Android), die auf Ihrer eigenen Domain liegt. Apples eigene Dokumentation stellt ausdrücklich klar, dass Universal Links für den Verifizierungsschritt nicht über einen serverseitigen Redirect erreichbar sein dürfen. Sie müssen also direkt auf der Domain konfiguriert werden, auf die der QR-Code zeigt, wenn Sie dieses Verhalten für wiederkehrende Nutzer wollen.

Für eine QR-Code-Kampagne ist die praktische Erkenntnis einfacher als die komplette Deep-Linking-Spezifikation: Geht es um neue Installationen, ist geräteabhängige Weiterleitung zum passenden Store-Eintrag das richtige Werkzeug. Kommt ein nennenswerter Anteil der Scans von Menschen, die die App bereits haben (etwa bei einer Neuauflage einer Treuekarte oder einem Flyer für Stammkunden), lohnt es sich, zusätzlich Universal Links oder App Links einzusetzen, damit diese Besucher den Store überspringen und direkt in der App landen, statt zu einem Eintrag geschickt zu werden, den sie längst kennen.

1. Scannen. Die Kamera öffnet die URL des QR-Codes, genau wie beim Antippen eines beliebigen Links.
2. Prüfen. Der Redirect-Endpunkt liest den User-Agent-Header der besuchenden Person aus, bevor überhaupt etwas geladen wird.
3. iPhone oder iPad. Direkte Weiterleitung zum Eintrag im App Store.
4. Android. Direkte Weiterleitung zum Eintrag bei Google Play.
5. Alles andere. Desktop, Tablet oder ein nicht erkanntes Gerät landet auf der Web-Fallback-Seite statt in einer Sackgasse.

So richten Sie das mit einem dynamischen QR-Code ein

Der QR-Code selbst muss nur auf eine Sache zeigen: eine URL, die die Geräteerkennung übernimmt. Sie drucken keinen separaten Code für iOS und Android, und der Code muss auch keine besondere Logik kodieren, denn ein QR-Code kann keinen Code ausführen. Was sich ändert, ist das, was hinter der Ziel-URL liegt.

Zwei praxistaugliche Ansätze:

• Nutzen Sie einen Redirect-Dienst oder eine kleine, selbst kontrollierte Serverless-Funktion, die den eingehenden User-Agent-Header ausliest und per 301 zur passenden Store-URL weiterleitet, mit einer sauberen Web-Fallback-Seite für alles andere. Das ist ein wirklich kleines Stück Code (die gesamte Logik passt in ein Dutzend Zeilen), und weil Sie sie selbst besitzen, sind Sie nicht davon abhängig, dass ein Anbieter den Dienst einstellt, wie es bei Firebase Dynamic Links passiert ist.
• Richten Sie das Ziel des QR-Codes mit einem dynamischen QR-Code auf diesen Endpunkt aus, statt die URL fest in den gedruckten Code einzubacken. Mehr dazu unter dynamische versus statische QR-Codes. Das ist das Detail, auf das es für eine Agentur in der Kundenbetreuung wirklich ankommt: Der gedruckte Code muss sich nie ändern, wohl aber der Endpunkt dahinter. Überarbeitet der Kunde seinen App-Store-Eintrag, wechselt zu einem neuen Redirect-Anbieter, oder verschiebt sich die Kampagne von "App herunterladen" zu "unser neues Feature entdecken", ändern Sie das Ziel, ohne irgendetwas neu drucken zu müssen.

Genau bei diesem zweiten Punkt zahlt sich eine dynamische QR-Plattform bei einer App-Install-Kampagne besonders aus. Druckauflagen für Verpackungen, Kassenaufkleber oder In-Store-Beschilderung sind teuer und lassen sich nur langsam austauschen. Ein Code, der sich in dem Moment umleiten lässt, in dem die Redirect-Logik aktualisiert werden muss, ohne das physische Material anzufassen, macht den Unterschied zwischen einem sechswöchigen Nachdruck-Zyklus und einer Fünf-Minuten-Korrektur.

Es lohnt sich außerdem, die Verteilung zu verfolgen, sobald die Kampagne live ist. Ein Scan verrät zwar nicht, ob daraus eine Installation wurde, aber er zeigt die Geräteverteilung der Scannenden, was für das Reporting an einen Kunden nützlich ist, der wissen will, ob seine iPhone-lastige oder Android-lastige Zielgruppe tatsächlich zu den Targeting-Annahmen der Kampagne passt. Erfasst Ihre QR-Analyse den Gerätetyp pro Scan, liegt diese Verteilung ohne zusätzlichen Aufwand bereits in den Daten vor.

Braucht Geräteerkennung einen Cookie-Banner?

Das Auslesen eines User-Agent-Headers, um zu entscheiden, zu welchem Store weitergeleitet wird, setzt für sich genommen keinen Cookie, speichert nichts auf dem Gerät der besuchenden Person und erfordert keine Einwilligung nach den ePrivacy-Regeln, die Cookies und lokalen Speicher betreffen. Es ist lediglich ein Server, der einen Header ausliest, den der Browser ohnehin bei jeder Anfrage mitschickt, und ihn einmalig nutzt, um ein Redirect-Ziel zu bestimmen.

Ob der User-Agent-String selbst als personenbezogene Daten im Sinne der DSGVO gilt, ist eine etwas andere Frage, und die ehrliche Antwort lautet: Es kommt auf den Kontext an, statt sich mit einem klaren Ja oder Nein beantworten zu lassen. Aufsichtsbehördliche Leitlinien (etwa die Arbeit der britischen ICO zu Adtech und Real-Time Bidding) behandeln Geräte- und Browser-Kennungen als personenbezogene Daten, wenn sie sich allein oder in Kombination mit anderen Signalen dazu eignen, eine Einzelperson zu identifizieren. Ein einmaliges Auslesen des UA-Strings, das nur dazu dient, zwischen zwei öffentlichen Store-URLs zu wählen, ohne dass irgendetwas gegen eine identifizierbare Person protokolliert wird, liegt am risikoarmen Ende dieses Spektrums. Protokollieren Sie den vollständigen UA-String hingegen zusätzlich zusammen mit IP-Adressen und bauen über die Zeit Profile auf, ist das eine andere, risikoreichere Nutzung, die in Ihrer Datenschutzdokumentation auch so behandelt werden sollte. Für den größeren Überblick darüber, was ein QR-Scan erfasst und was nicht, siehe den Überblick zur DSGVO-Konformität.

Häufig gestellte Fragen

Kann ein QR-Code gleichzeitig zum App Store und zu Google Play führen?

Ja. Der QR-Code selbst zeigt immer auf dieselbe eine URL. Diese URL führt zu einem Redirect-Schritt, der das Gerät der besuchenden Person ausliest und iPhone- und iPad-Nutzer zum App Store, Android-Nutzer zu Google Play und alle anderen auf eine normale Web-Landingpage mit beiden Store-Badges schickt.

Woher weiß ein QR-Code, ob ich ein iPhone oder Android nutze?

Das weiß er nicht, der QR-Code hat keine eigene Logik. Der Redirect-Endpunkt, auf den der Code zeigt, liest den User-Agent-HTTP-Header aus, den Ihr Browser automatisch mitschickt, prüft ihn auf Plattform-Hinweise wie "iPhone", "iPad" oder "Android" und leitet entsprechend weiter. Das geschieht, bevor überhaupt Seiteninhalt geladen wird.

Was passiert, wenn jemand einen App-Store-QR-Code am Desktop-Rechner scannt?

Ist die Redirect-Logik sauber gebaut, landet die Person auf einer normalen Webseite, typischerweise der Marketingseite der App mit beiden Store-Badges als gewöhnliche Links, statt zu einem Store-Eintrag geschickt zu werden, den es für ihr Gerät gar nicht gibt. Ein schlecht gebauter Redirect, der nur iOS und Android abdeckt und kein Fallback hat, führt Desktop- und Tablet-Besucher in eine Sackgasse. Es lohnt sich also, dieses Fallback vor dem Kampagnenstart gezielt zu testen.

Unterscheidet sich ein "smarter" QR-Code von einem normalen dynamischen QR-Code?

Strukturell nicht. Beide sind QR-Codes, die auf eine URL zeigen, die sich nach dem Druck noch ändern lässt. Was einen QR-Code "smart" wirken lässt, ist die Redirect-Logik hinter dieser URL (in diesem Fall die Geräteerkennung), nicht etwas anderes am Code selbst.

Kann ein QR-Code direkt die App öffnen, wenn diese schon installiert ist, statt zum Store zu führen?

Ja, aber das ist ein anderer Mechanismus: Universal Links unter iOS und App Links unter Android, die mithilfe einer Verifizierungsdatei auf der Ziel-Domain direkt in eine installierte App führen. Geräteabhängige Store-Weiterleitung und Universal-/App-Links lösen verwandte, aber getrennte Probleme, und ein ausgereiftes Setup nutzt oft beides: Universal-/App-Links für Menschen, die die App schon haben, Store-Weiterleitung für alle anderen.

Wie schnell läuft die Geräteerkennung beim Scannen ab?

Sie läuft als Teil des normalen HTTP-Redirects ab, auf moderner Edge- beziehungsweise Serverless-Infrastruktur typischerweise deutlich unter einer Sekunde, und ist für die scannende Person nicht als eigener Schritt wahrnehmbar.

Erfasst geräteabhängige Weiterleitung personenbezogene Daten oder braucht sie einen DSGVO-Cookie-Banner?

Das Auslesen eines User-Agent-Headers zur Wahl eines Redirect-Ziels setzt selbst keinen Cookie und erfordert keine Einwilligung nach den ePrivacy-Cookie-Regeln. Ob der UA-String als personenbezogene Daten gilt, hängt davon ab, was Sie sonst noch damit tun. Ein einmaliges Auslesen, das nur der Wahl eines Redirect-Ziels dient und über das kein Profil aufgebaut wird, ist risikoarm; das Protokollieren zusammen mit anderen Kennungen zu Tracking-Zwecken ist ein anderer, risikoreicherer Fall.

Gehen native Kamera-Scanner anders mit Redirects um als QR-Scanner-Apps von Drittanbietern?

Für diesen Anwendungsfall nicht nennenswert. Sowohl der native Scanner der iOS-Kamera-App als auch der native Android-Scanner (über Google Lens oder die Kamera-App) öffnen die aufgelöste URL einfach im Standardbrowser und folgen dabei jedem serverseitigen Redirect genauso wie beim Tippen auf einen normalen Link. Ältere oder ungewöhnliche Drittanbieter-Scanner-Apps entfernen oder verändern gelegentlich Header, was ein weiterer Grund ist, die Fallback-Seite wirklich nützlich zu gestalten.

Kann ich sehen, wie viele Scans von iOS statt von Android kamen?

Erfasst die QR-Plattform den Gerätetyp pro Scan (die meisten dynamischen QR-Tools tun das, da sie für ihre eigene Analyse denselben User-Agent-Header auslesen), dann ja: Diese Verteilung steht in den Scan-Daten zur Verfügung, ohne dass auf der Redirect-Seite zusätzliche Konfiguration nötig wäre.

Was hat Firebase Dynamic Links nach der Einstellung ersetzt?

Googles eigene Leitlinien verweisen auf die nativen Plattform-Mechanismen: Universal Links und App Links für Deep Links in installierte Apps, ergänzt um klassische geräteabhängige Redirect-Logik (das Muster, das dieser Artikel beschreibt) für Install-Flows für Neukunden, statt auf ein einzelnes Ersatzprodukt zum direkten Einsetzen.

Die Kurzversion

Ein QR-Code kann nicht von sich aus nach Gerät verzweigen, er zeigt lediglich auf eine URL. Hinter dieser URL sitzt eine kleine Redirect-Logik, die den User-Agent-Header der besuchenden Person ausliest, und schon kann ein einziger gedruckter Code iPhone-Nutzer zum App Store, Android-Nutzer zu Google Play und alle anderen zu einem sauberen Web-Fallback schicken, ganz ohne Sackgassen. Halten Sie diese Redirect-Logik durch einen dynamischen QR-Code getrennt vom gedruckten Code, damit eine Änderung am App-Eintrag, am Redirect-Anbieter oder an der Kampagne selbst nie einen Nachdruck bedeutet. Hat Ihre Agentur dafür vor der Einstellung 2025 Firebase Dynamic Links genutzt, ist dies das dauerhafte Ersatzmuster: den Redirect selbst besitzen, einen dynamischen Code darauf ausrichten und die Geräteverteilung in der Scan-Analyse prüfen, sobald die Kampagne live ist.