QR-code naar App Store én Google Play: automatische redirect per toestel

Eén QR-code, twee app stores: stuur iPhone-gebruikers naar de App Store en Android-gebruikers naar Google Play

Elk bureau dat een app-installatiecampagne draait, loopt tegen hetzelfde kleine, irritante probleem aan. De klant heeft een app in zowel de App Store als Google Play, de oplage is één poster, één flyer, één sticker bij de kassa, en de QR-code daarop kan maar naar één URL verwijzen. De gebruikelijke oplossing is twee codes naast elkaar drukken, ze labelen met "iPhone" en "Android", en hopen dat de klant de juiste kiest. Het werkt, maar het oogt amateuristisch, het verspilt de helft van de drukruimte, en het legt de verantwoordelijkheid voor die keuze bij iemand die gewoon een app wil downloaden.

Eén QR-code kan die routering ook zelf regelen. Dit artikel legt uit hoe device-gebaseerde redirects onder de motorkap werken, waar dat overlapt met Apple's eigen Smart App Banners en Android's App Links (en waar juist niet), waarom een tool die veel bureaus hier jarenlang voor gebruikten in 2025 verdween, en hoe je dit hele proces opzet met een dynamische QR-code zonder zelf een volledige app-linking-stack te bouwen.

Waarom bureaus voor één app toch twee QR-codes afdrukken

De App Store en Google Play zijn losse systemen met losse URL-formaten. Een App Store-vermelding staat op een URL zoals apps.apple.com/us/app/instagram/id389801252; een Google Play-vermelding staat op play.google.com/store/apps/details?id=com.instagram.android. Noch Apple, noch Google publiceert één "slimme" URL die automatisch naar de juiste store doorverwijst, afhankelijk van wie er vraagt. Dat gat is reëel, geen omissie die een van beide bedrijven per ongeluk heeft laten zitten, en het is precies de reden dat er een hele markt van link-redirect-tools bestaat om het te dichten.

Een QR-code zelf heeft daar geen mening over. Hij codeert simpelweg een URL, en een scanner opent die URL. De intelligentie moet ergens anders zitten: bij de URL waar de code naar wijst. Dat is de hele truc, en het loont om daar precies over te zijn, want de term "slimme QR-code" wordt gebruikt alsof de code zelf iets slims doet. Dat is niet zo. De code is statische data. De redirect waar hij naar wijst bepaalt waar de bezoeker terechtkomt, en die beslissing wordt genomen op basis van één enkele HTTP-header.

Hoe device-gebaseerde QR-redirects echt werken

Wanneer een telefoon een webpagina opvraagt, stuurt hij een User-Agent-header mee die de browser en meestal ook het besturingssysteem identificeert. Een redirect-service leest die header serverside, nog voordat er iets wordt weergegeven, en stuurt een 301- of 302-redirect naar de juiste bestemming. iPhones en iPads geven strings door met "iPhone" of "iPad" erin; Android-toestellen geven "Android" door. Een serverside regel zo simpel als "als de UA iPhone of iPad bevat, stuur door naar de App Store-URL; als hij Android bevat, stuur door naar de Play Store-URL; stuur anders door naar een gewone weblandingspagina" is in feite het grootste deel van de implementatie.

Er bestaat geen officiële specificatie van Apple, Google of het W3C die deze substring-patronen vastlegt als een contract waar je voor eeuwig op kunt bouwen. Het is geobserveerde, stabiele, veelgebruikte praktijk, geen API. In de praktijk is het jarenlang betrouwbaar gebleken omdat beide bedrijven er belang bij hebben dat hun eigen browsers herkenbaar blijven (app-compatibiliteit op het hele web hangt ervan af), maar het loont om het fallback-pad netjes te bouwen in plaats van ervan uit te gaan dat detectie altijd perfect zal zijn.

Wat de User-Agent-header de redirect wél en niet vertelt

De header vertelt je betrouwbaar de platformfamilie (iOS-achtig versus Android versus geen van beide). Welke exacte OS-versie het is, vertelt hij tegenwoordig veel minder betrouwbaar. Apple bevriest al sinds Safari 11.1 geleidelijk hoeveel detail de User-Agent-string van Safari prijsgeeft, en heeft die trend met iOS 26 doorgezet door een statische, minder specifieke OS-versiestring te tonen als privacymaatregel. Dat verstoort het onderscheid tussen iPhone en Android dat je redirect nodig heeft niet, want het platformtoken zelf verandert niet, maar het betekent wel dat je niets moet bouwen dat afhankelijk is van precies weten welke iOS-versie iemand draait op basis van alleen die header.

De header kan ook worden vervalst, verwijderd, of aangepast door privacygerichte browsers en browserextensies. Dat is geen reden om het patroon te vermijden (het is standaardpraktijk in de hele link-in-bio- en app-marketingsector), maar wel een reden om de fallback-bestemming écht bruikbaar te houden in plaats van een doodlopend pad, want een klein percentage bezoekers komt daar per ongeluk terecht.

Wat er gebeurt op desktop of bij een onherkend toestel

Dit is het onderdeel dat leverancierspagina's stelselmatig overslaan, en het is precies het onderdeel dat bepaalt of de campagne werkt. Een QR-code op verpakking, een flyer, of een etalage wordt af en toe gescand vanaf een laptopcamera, een iPad in desktopmodus, of een scanner-app die identificerende headers weglaat. Stuur dat verkeer naar een storebadge en het loopt dood: er is geen "App Store" in een desktopbrowser. De fallback moet een gewone webpagina zijn, idealiter de marketingpagina van de app met beide storebadges als gewone links, zodat niemand tegen een muur aanloopt. Het bouwen van die fallbackpagina kost tien minuten en maakt van een edge case een non-issue.

Waarom dit niet hetzelfde is als Apple's Smart App Banner

Apple heeft al een mechanisme om een app te promoten bij Safari-bezoekers: de Smart App Banner, toegevoegd met één enkele meta-tag, <meta name="apple-itunes-app" content="app-id=YOUR_ID, app-argument=YOUR_URL">, geplaatst in de <head> van de pagina. Dat is echt nuttig, en wordt nog steeds volledig ondersteund. Maar het lost een ander probleem op dan waar dit artikel over gaat, en die twee door elkaar halen leidt tot kapotte opzetten.

De Smart App Banner verschijnt alleen wanneer Safari de getagde pagina daadwerkelijk rendert en een bezoeker er even op blijft. Hij verschijnt niet binnen een in-app browser (de webview waarin Instagram, TikTok of Facebook links openen), hij verschijnt niet in een iframe, en cruciaal voor QR-campagnes: hij krijgt nooit de kans om te verschijnen als jouw redirect de bezoeker meteen met een serverside 301 doorstuurt voordat Safari klaar is met laden. Een QR-code die direct naar de App Store doorstuurt, laat Safari de getagde pagina nooit zien, dus is de banner structureel irrelevant voor die flow. De banner is bedoeld voor een andere reis: iemand die rechtstreeks in Safari op je website rondkijkt en ervoor kiest om er even te blijven. Device-gebaseerde QR-redirects zijn bedoeld voor iemand die een code scande met één duidelijke intentie (de app binnenhalen) en meteen daarheen gestuurd moet worden.

Het gat dat Firebase Dynamic Links achterliet, voelen bureaus nog steeds

Als jouw bureau in het afgelopen decennium ooit QR-flows voor app-installaties heeft gebouwd, is de kans groot dat je daarvoor Firebase Dynamic Links gebruikte, precies voor dit soort routering. Google kondigde de uitfasering aan in augustus 2023, maakte de console vanaf 24 mei 2024 read-only, en sloot de dienst op 25 augustus 2025 volledig af: elke page.link en elk custom Dynamic Links-domein geeft nu niets meer terug. Google's officiële argument was dat de native alternatieven (Universal Links, App Links, en nieuwere mechanismen) inmiddels volwassen genoeg waren, waardoor een apart cross-platform smart-link-product niet langer nodig was.

Dat laat een reëel gat achter voor bureaus die erop leunden, en het is een groot deel van de reden waarom het nu de moeite waard is om dit netjes op te lossen in plaats van te grijpen naar welk halfwerkend scriptje dan ook nog draait. Een dynamische QR-code die naar een redirect-endpoint wijst dat je zelf beheert, omzeilt die afhankelijkheid volledig: je leunt niet op het voortbestaan van andermans smart-link-product, je leunt op een URL die je zelf bezit en die één simpele taak uitvoert.

Universal Links en App Links: mensen routeren die de app al hebben

Alles hierboven gaat over iemand die de app nog niet heeft naar de juiste vermelding in de store krijgen. Een apart, verwant mechanisme regelt het geval waarin de app al is geïnstalleerd: Universal Links op iOS en App Links op Android laten een URL rechtstreeks in de geïnstalleerde app openen in plaats van in een browser, en slaan de store dus helemaal over. Deze leunen op een verificatiebestand (apple-app-site-association voor iOS, een Digital Asset Links-bestand voor Android) dat op jouw domein staat, en Apple's eigen documentatie is expliciet dat Universal Links niet ondersteund worden via een serverside redirect voor de verificatiestap, dus die moeten rechtstreeks op het domein staan waar de QR-code naar wijst als je dat gedrag voor terugkerende gebruikers wilt.

Voor een QR-campagne is de praktische conclusie eenvoudiger dan de volledige deep-linking-spec: als het doel nieuwe installaties is, is device-gebaseerde redirect naar de juiste storevermelding het juiste middel. Als een aanzienlijk deel van de scans van mensen komt die de app al hebben (een herdruk van een loyaliteitskaart, een flyer voor terugkerende klanten), loont het om daar Universal Links of App Links bovenop te leggen, zodat die bezoekers de store overslaan en meteen in de app zelf terechtkomen, in plaats van bij een vermelding die ze al hebben.

1. Scannen. De camera opent de URL van de QR-code, net als bij elke andere link.
2. Checken. Het redirect-endpoint leest de User-Agent-header van de bezoeker uit voordat er iets wordt weergegeven.
3. iPhone of iPad. Directe redirect naar de vermelding in de App Store.
4. Android. Directe redirect naar de vermelding in Google Play.
5. Al de rest. Desktop, tablet of een onherkend toestel krijgt de webfallback in plaats van een doodlopende weg.

Dit opzetten met een dynamische QR-code

De QR-code zelf hoeft maar naar één ding te wijzen: een URL die de device-detectie uitvoert. Je drukt geen aparte code voor iOS en Android af, en de code hoeft ook geen speciale logica te bevatten, want een QR-code kan geen code uitvoeren. Wat verandert, is wat er achter die bestemmings-URL zit.

Twee bruikbare aanpakken:

• Gebruik een redirect-service of een kleine serverless functie die je zelf beheert, die de binnenkomende User-Agent-header leest en een 301 stuurt naar de juiste store-URL, met een fatsoenlijke webpagina-fallback voor al het andere. Dit is echt een klein stukje code (de hele logica past in een stuk of tien regels), en het zelf beheren betekent dat je niet afhankelijk bent van een andere leverancier die de dienst stopzet, zoals bij Firebase Dynamic Links gebeurde.
• Laat de bestemming van de QR-code naar dat endpoint wijzen via een dynamische QR-code in plaats van de URL rechtstreeks in de gedrukte code te bakken. Zie dynamische versus statische QR-codes voor het volledige plaatje. Dit is het detail dat er voor een bureau met een klantrelatie écht toe doet: de gedrukte code hoeft nooit te veranderen, maar het endpoint erachter wel. Als de klant de vermelding in de app store herontwerpt, overstapt naar een andere redirect-provider, of de campagne verschuift van "download de app" naar "bekijk onze nieuwe functie", dan wijzig je de bestemming zonder iets opnieuw te hoeven drukken.

Dat tweede punt is waar een dynamisch QR-platform zich specifiek terugverdient bij een app-installatiecampagne. Oplages voor verpakking, kassastickers, of in-store signing zijn duur en traag om te vervangen. Een code die je kunt omleggen zodra de redirect-logica moet worden bijgewerkt, zonder het fysieke materiaal aan te raken, is het verschil tussen een herdrukcyclus van zes weken en een fix van vijf minuten.

Het loont ook om de verdeling bij te houden zodra de campagne live staat. Een scan vertelt je niet of hij tot een installatie leidde, maar wel de device-verdeling van wie er scande, wat waardevol is bij het rapporteren aan een klant die wil weten of zijn iPhone-zware of Android-zware doelgroep daadwerkelijk overeenkomt met de targeting-aannames van de campagne. Als jouw QR-analytics het devicetype per scan vastlegt, staat die verdeling al in de data, zonder extra configuratie.

Heeft device-detectie een cookiebanner nodig?

Het lezen van een User-Agent-header om te bepalen naar welke store wordt doorverwezen, zet op zichzelf geen cookie, slaat niets op het toestel van de bezoeker op, en vereist geen toestemming onder de ePrivacy-regels die cookies en lokale opslag regelen. Het is een server die een header leest die de browser toch al bij elk verzoek meestuurt, en die eenmalig gebruikt om een redirect-doel te kiezen.

Of de User-Agent-string zelf onder de AVG geldt als persoonsgegeven, is een net iets andere vraag, en het eerlijke antwoord is dat het van de context afhangt in plaats van een simpel ja of nee. Toezichthouders (het werk van de Britse ICO rond adtech en real-time bidding bijvoorbeeld) behandelen device- en browserherkenningspunten als persoonsgegevens wanneer ze, alleen of gecombineerd met andere signalen, gebruikt kunnen worden om een individu te identificeren. Een eenmalige UA-lezing die puur wordt gebruikt om tussen twee publieke store-URL's te kiezen, zonder dat er iets wordt gelogd tegen een identificeerbare persoon, zit aan de lage-risico-kant van dat spectrum, maar als je ook de volledige UA-string samen met IP-adressen logt en er over tijd profielen mee opbouwt, is dat een ander, risicovoller gebruik, en moet je dat ook zo behandelen in je privacydocumentatie. Voor het bredere plaatje van wat een QR-scan wel en niet verzamelt, zie het AVG-nalevingsoverzicht.

Veelgestelde vragen

Kan één QR-code naar zowel de App Store als Google Play verwijzen?

Ja. De QR-code zelf wijst altijd naar dezelfde ene URL. Die URL leidt naar een redirect-stap die het toestel van de bezoeker herkent en iPhone- en iPad-bezoekers naar de App Store stuurt, Android-bezoekers naar Google Play, en iedereen daarbuiten naar een gewone weblandingspagina met beide storebadges.

Hoe weet een QR-code of ik een iPhone of Android heb?

Dat weet hij niet, de QR-code heeft zelf geen logica. Het redirect-endpoint waar de code naar wijst, leest de User-Agent HTTP-header die je browser automatisch meestuurt, controleert die op platformindicatoren zoals "iPhone", "iPad" of "Android", en stuurt op basis daarvan door. Dit gebeurt voordat er ook maar iets van de pagina-inhoud laadt.

Wat gebeurt er als iemand een app store-QR-code scant op een desktop?

Als de redirect-logica goed gebouwd is, komt diegene op een gewone webpagina terecht, meestal de marketingpagina van de app met beide storebadges als gewone links, in plaats van dat hij naar een storevermelding wordt gestuurd die voor zijn toestel niet bestaat. Een slecht gebouwde redirect die alleen iOS en Android afhandelt en geen fallback heeft, loopt voor desktop- en tabletbezoekers dood, dus het loont om deze fallback expliciet te testen voordat een campagne live gaat.

Is een "slimme" QR-code anders dan een gewone dynamische QR-code?

Structureel niet. Beide zijn QR-codes die naar een URL wijzen die je na het drukken nog kunt aanpassen. Wat een QR-code "slim" laat aanvoelen, is de redirect-logica die achter die URL zit (in dit geval device-detectie), niet iets anders aan de code zelf.

Kan een QR-code direct de app openen als die al geïnstalleerd is, in plaats van naar de store te gaan?

Ja, maar dat is een ander mechanisme: Universal Links op iOS en App Links op Android, die rechtstreeks naar een geïnstalleerde app routeren via een verificatiebestand op het bestemmingsdomein. Device-gebaseerde storeredirects en Universal/App Links lossen verwante maar aparte problemen op, en een volwassen opzet gebruikt vaak allebei: Universal/App Links voor mensen die de app al hebben, storeredirects voor mensen die hem nog niet hebben.

Hoe snel gaat device-detectie als iemand de code scant?

Dat gebeurt als onderdeel van de normale HTTP-redirect, meestal ruim onder een seconde op moderne edge/serverless-infrastructuur, en is voor de scannende persoon niet waarneembaar als aparte stap.

Verzamelt device-gebaseerde redirect persoonsgegevens of is een AVG-cookiebanner nodig?

Het lezen van een User-Agent-header om een redirect-doel te kiezen, zet op zichzelf geen cookie en vereist geen toestemming onder de ePrivacy-cookieregels. Of de UA-string als persoonsgegeven geldt, hangt af van wat je er verder mee doet. Een eenmalige lezing die alleen wordt gebruikt om een redirect-doel te kiezen, zonder dat er over tijd een profiel wordt opgebouwd, is laag risico; het loggen ervan samen met andere identificatoren voor tracking is een ander, risicovoller geval.

Verwerken de ingebouwde camera-apps redirects anders dan losse scanner-apps?

Niet noemenswaardig voor dit gebruiksdoel. Zowel de scanner in iOS' native Camera-app als Android's native scanner (via Google Lens of de camera-app) opent gewoon de opgeloste URL in de standaardbrowser, en volgt daarbij elke serverside redirect precies zoals een normale klik op een link dat zou doen. Oudere of ongebruikelijke scanner-apps van derden verwijderen of wijzigen soms headers, wat nog een reden is om de fallbackpagina écht bruikbaar te houden.

Kan ik zien hoeveel scans van iOS versus Android kwamen?

Als het QR-platform het devicetype per scan vastlegt (de meeste dynamische QR-tools doen dat, omdat ze dezelfde User-Agent-header ook voor hun eigen analytics lezen), dan ja: die verdeling staat gewoon in de scan-data, zonder extra configuratie aan de redirect-kant.

Wat is het alternatief voor Firebase Dynamic Links nu die dienst is gestopt?

Google's eigen richtlijnen wijzen naar de native platformmechanismen: Universal Links en App Links voor deep linking naar geïnstalleerde apps, plus standaard device-gebaseerde redirect-logica (het patroon dat dit artikel beschrijft) voor flows gericht op nieuwe installaties, in plaats van één kant-en-klaar vervangend product.

De korte versie

Een QR-code kan niet zelf per toestel vertakken, hij wijst alleen naar een URL. Zet een klein stukje redirect-logica achter die URL dat de User-Agent-header van de bezoeker leest, en één gedrukte code kan iPhone-gebruikers naar de App Store sturen, Android-gebruikers naar Google Play, en iedereen daarbuiten naar een fatsoenlijke webfallback, zonder doodlopende paden. Houd die redirect-logica los van de gedrukte code door een dynamische QR-code te gebruiken, zodat een wijziging in de app-vermelding, de redirect-provider, of de campagne zelf nooit betekent dat je iets opnieuw moet drukken. Gebruikte jouw bureau hiervoor Firebase Dynamic Links vóór de stopzetting in 2025? Dan is dit het duurzame vervangende patroon: beheer de redirect zelf, laat een dynamische code ernaar wijzen, en check de device-verdeling in je scan-analytics zodra alles live staat.