{"id":12134,"date":"2026-10-21T08:00:00","date_gmt":"2026-10-21T08:00:00","guid":{"rendered":"https:\/\/wuzzon.com\/?p=12134"},"modified":"2026-07-23T06:59:41","modified_gmt":"2026-07-23T06:59:41","slug":"waarom-werkt-mijn-app-link-wel-op-android-maar-niet-op-ios","status":"publish","type":"post","link":"https:\/\/wuzzon.com\/nl\/blog\/why-does-my-app-link-work-on-android-but-not-ios\/","title":{"rendered":"Waarom werkt mijn app-link wel op Android, maar niet op iOS?"},"content":{"rendered":"<p>Je app-link werkt op Android, maar niet op iOS, omdat de twee platforms compleet verschillende systemen gebruiken voor het verwerken van deep links. iOS hanteert bovendien een strenger verificatieproces dat Android niet op dezelfde manier toepast. Op Android worden app-links geverifieerd via een <code>assetlinks.json<\/code> bestand, terwijl iOS afhankelijk is van een bestand genaamd de <code>apple-app-site-association<\/code> (AASA), dat Apple actief ophaalt en valideert voordat universele links werken. Als dat bestand ontbreekt, verkeerd geconfigureerd is of onjuist wordt aangeboden, opent iOS in plaats van uw app een browser. De onderstaande paragrafen beschrijven de meest voorkomende oorzaken, hoe de verificatie van Apple werkt en wat u kunt doen om het probleem op te lossen.<\/p>\n<h2>Wat is het verschil tussen Android-applinks en universele iOS-links?<\/h2>\n<p>Zowel Android-applinks als universele iOS-links maken het mogelijk om een URL direct in je app te openen in plaats van in een browser, maar ze gebruiken verschillende verificatiemechanismen en gedragen zich anders als er iets misgaat. Android-applinks worden geverifieerd via een <code>assetlinks.json<\/code> een bestand dat op uw domein wordt gehost, terwijl universele iOS-links afhankelijk zijn van een <code>apple-app-site-association<\/code> Een bestand dat Apple op systeemniveau ophaalt en in de cache opslaat tijdens de installatie van een app.<\/p>\n<p>Het praktische verschil is van groot belang bij het debuggen. Op Android toont het systeem bij een mislukte verificatie meestal een dialoogvenster waarin de gebruiker wordt gevraagd in welke app de link moet worden geopend. Op iOS schakelt een mislukte universele link stilletjes terug naar Safari, zonder waarschuwing voor de gebruiker en zonder duidelijke foutmelding die u kunt opsporen. Dit is de reden waarom een Android-ervaring prima kan werken, terwijl iOS-gebruikers stilletjes op een webpagina terechtkomen in plaats van in uw app. Dit leidt tot het verlies van gebruikers na installatie en app-onboarding, wat de prestaties van uw campagne negatief be\u00efnvloedt.<\/p>\n<p>Een ander belangrijk verschil is dat universele links in iOS alleen worden geactiveerd wanneer een gebruiker op een link tikt van buiten de app, bijvoorbeeld vanuit een e-mail, een browser of een berichtenapp. Ze worden niet geactiveerd wanneer een gebruiker de URL rechtstreeks in Safari typt of wanneer de link vanuit dezelfde app wordt geopend. Links in Android-apps gedragen zich vergelijkbaar, maar de uitzonderingen verschillen voldoende om geen gelijke werking tussen de twee platforms te kunnen aannemen.<\/p>\n<h2>Waarom werken universele iOS-links niet, terwijl Android-applinks wel werken?<\/h2>\n<p>Universele iOS-links werken niet, terwijl Android-applinks wel werken, omdat het verificatiesysteem van Apple strenger is en op een specifiek moment plaatsvindt: tijdens de app-installatie. Als uw AASA-bestand op dat moment niet correct toegankelijk is, zal iOS de link tussen uw domein en uw app niet tot stand brengen en zullen universele links niet werken, ongeacht hoe goed uw Android-configuratie is ingesteld.<\/p>\n<p>De oorzaken vallen doorgaans in een paar categorie\u00ebn. Uw AASA-bestand wordt mogelijk niet via HTTPS aangeboden, retourneert mogelijk het verkeerde contenttype, bevindt zich mogelijk achter een redirect of bevat simpelweg een typefout in de app-ID of padconfiguratie. Apple&#039;s CDN haalt het AASA-bestand op via eigen servers, niet vanaf het apparaat van de gebruiker. Dit betekent dat uw bestand publiekelijk toegankelijk moet zijn zonder authenticatie of geografische blokkering.<\/p>\n<p>Het is ook belangrijk om te weten dat Apple het AASA-bestand zeer zorgvuldig cachet. Als u het bestand bijwerkt nadat een gebruiker uw app al heeft ge\u00efnstalleerd, krijgt die gebruiker de bijgewerkte versie pas automatisch na een herinstallatie. Dit betekent dat een verkeerde configuratie die tijdens de installatie bestond, problemen kan blijven veroorzaken, zelfs nadat u het bestand op uw server hebt gecorrigeerd.<\/p>\n<h2>Hoe controleert Apple het apple-app-site-association-bestand?<\/h2>\n<p>Apple controleert het AASA-bestand door het via Apple&#039;s eigen CDN-infrastructuur van uw domein op te halen wanneer een gebruiker uw app installeert, niet wanneer ze op een link klikken. Apple vraagt het bestand op via uw domein. <code>https:\/\/yourdomain.com\/.well-known\/apple-app-site-association<\/code> en valideert dat het correct is opgemaakt, via HTTPS wordt aangeboden zonder omleidingen, en een overeenkomende app-ID bevat voor de ge\u00efnstalleerde app.<\/p>\n<p>De app-ID in uw AASA-bestand moet overeenkomen met het formaat. <code>TEAMID.BUNDLEID<\/code> Precies. Apple vergelijkt dit met de machtigingen in het binaire bestand van je app. Als de team-ID of bundel-ID niet overeenkomt met wat is geregistreerd in App Store Connect, mislukt de verificatie zonder dat er een foutmelding verschijnt en werken universele links niet.<\/p>\n<p>Apple vereist ook dat het bestand wordt aangeboden met een contenttype van <code>applicatie\/json<\/code>. Sommige servers serveren standaard bestanden zonder extensie met een generiek inhoudstype, waardoor de verificatie mislukt. Bovendien kan het CDN van Apple een bijgewerkt AASA-bestand niet direct opnieuw ophalen, waardoor het even kan duren voordat wijzigingen zijn doorgevoerd, zelfs nadat u de configuratie aan uw kant hebt gecorrigeerd.<\/p>\n<h2>Wat zijn de meest voorkomende configuratiefouten bij het gebruik van Universal Link in iOS?<\/h2>\n<p>De meest voorkomende configuratiefouten bij het instellen van een universele link voor iOS zijn een onjuist app-ID-formaat in het AASA-bestand, het aanbieden van het bestand via HTTP in plaats van HTTPS, het gebruik van een redirect in de URL van het AASA-bestand en het niet toevoegen van de bijbehorende domeinrechten aan je Xcode-project. Elk van deze fouten zal er stilletjes voor zorgen dat universele links voor alle gebruikers niet meer werken.<\/p>\n<p>Dit zijn de meest voorkomende fouten die we tegenkomen bij het controleren van defecte deep link-configuraties:<\/p>\n<ul>\n <li><strong>Onjuist app-ID-formaat:<\/strong> Het AASA-bestand moet gebruikmaken van <code>TEAMID.BUNDLEID<\/code>, Niet alleen de bundel-ID. Het ontbreken of verwisselen van de team-ID is een veelvoorkomende fout.<\/li>\n <li><strong>Doorverwijzing op de AASA-URL:<\/strong> Apple volgt geen redirects bij het ophalen van bestanden. Als uw domein HTTP naar HTTPS doorverwijst, of www naar non-www, kan het ophalen mislukken, afhankelijk van welke variant Apple opvraagt.<\/li>\n <li><strong>Ontbrekende rechten voor gekoppelde domeinen:<\/strong> Je Xcode-project moet het volgende bevatten: <code>applinks:yourdomain.com<\/code> toegang. Zonder die toegang zal iOS niet eens proberen links van dat domein aan je app te koppelen.<\/li>\n <li><strong>Onjuiste padpatronen:<\/strong> De paden in uw AASA-bestand bepalen welke URL&#039;s de universele link activeren. Een verkeerd geconfigureerde wildcard of een ontbrekende padvermelding betekent dat slechts sommige links de app openen, terwijl andere terugvallen op Safari.<\/li>\n <li><strong>Het AASA-bestand bevindt zich niet op de juiste locatie:<\/strong> Het bestand moet toegankelijk zijn via <code>\/.bekende\/apple-app-site-associatie<\/code> of rechtstreeks bij <code>\/apple-app-site-association<\/code>. Beide locaties worden gecontroleerd, maar het bestand moet zonder authenticatie bereikbaar zijn.<\/li>\n<\/ul>\n<p>Deze problemen dragen er direct toe bij dat gebruikers na de installatie verdwijnen en na een advertentieklik op een verkeerd scherm terechtkomen, omdat de link de app helemaal niet opent of deze opent zonder de juiste context door te geven aan de juiste bestemming binnen de app.<\/p>\n<h2>Hoe kun je een defecte universele iOS-link testen en debuggen?<\/h2>\n<p>Je kunt een defecte universele iOS-link testen en debuggen met behulp van Apple&#039;s AASA-validatietool, door het bestand rechtstreeks in een browser te controleren, de bijbehorende domeinrechten in Xcode te bekijken en het linkgedrag op een fysiek apparaat te testen. De iOS-simulator reproduceert het gedrag van universele links niet betrouwbaar, dus test altijd op echte hardware.<\/p>\n<p>Begin met de validatietool van Apple zelf op <code>developer.apple.com\/news\/universal-links<\/code>, die uw AASA-bestand ophaalt op dezelfde manier als Apple&#039;s CDN en eventuele fouten rapporteert. Controleer vervolgens de volgende stappen in de aangegeven volgorde:<\/p>\n<ol>\n <li>Open <code>https:\/\/yourdomain.com\/.well-known\/apple-app-site-association<\/code> Voer de code direct in een browser in en controleer of deze geldige JSON met het juiste contenttype retourneert.<\/li>\n <li>Controleer in Xcode of de mogelijkheid voor gekoppelde domeinen is ingeschakeld en of uw domein wordt vermeld bij de <code>applinks:<\/code> voorvoegsel.<\/li>\n <li>Installeer op een fysiek testapparaat een nieuwe versie van uw app en tik vervolgens op een link in Notities of Berichten (niet in Safari) om de universele linkhandler te activeren.<\/li>\n <li>Controleer de apparaatconsole in Xcode op logberichten met betrekking tot swcd of AASA. Deze berichten geven aan of het bestand succesvol is opgehaald en of de app-ID overeenkomt.<\/li>\n<\/ol>\n<p>Als uw link Safari opent in plaats van de app, is de meest waarschijnlijke oorzaak een verificatiefout tijdens de installatie. Installeer de app opnieuw nadat u uw AASA-bestand hebt gecorrigeerd om een nieuwe verificatie af te dwingen. Als de app wel opent, maar op het verkeerde scherm terechtkomt, ligt het probleem in de routinglogica van de deeplinks in uw app en niet in de AASA-configuratie zelf. Dit is de oorzaak van de problemen met retargeting-advertenties die op de verkeerde pagina openen en winkelwagens die verloren gaan na het opnieuw openen van de app, problemen die van invloed zijn op re-engagementcampagnes.<\/p>\n<h2>Zou u in plaats daarvan een deep linking-oplossing van een derde partij moeten gebruiken?<\/h2>\n<p>Het gebruik van een externe oplossing voor deep linking is het overwegen waard als u behoefte heeft aan uitgestelde deep linking, platformonafhankelijke consistentie of betrouwbare bronvermelding naast uw deep links. Tools zoals Branch regelen de AASA- en assetlinks-configuratie voor u, bieden een fallback-logica wanneer native universele links niet werken en geven de linkcontext door tijdens het installatieproces, zodat nieuwe gebruikers op het juiste scherm terechtkomen na de eerste download van uw app.<\/p>\n<p>Native universele links kunnen geen gegevens doorgeven na een nieuwe installatie. Als een gebruiker op een link tikt voordat de app is ge\u00efnstalleerd, stuurt iOS hem of haar naar de App Store. Zodra de gebruiker de app installeert en opent, gaat de oorspronkelijke linkcontext verloren. Dit is een directe oorzaak van gebruikersverlies na installatie en een afname van het aantal gebruikers tijdens de onboarding in performancecampagnes. Je verwacht namelijk dat gebruikers op een specifieke aanbieding of onboardingflow terechtkomen, maar ze belanden in plaats daarvan op een generiek startscherm.<\/p>\n<p>Branch deep linking lost dit op met een techniek genaamd deferred deep linking. Hierbij wordt de beoogde bestemming opgeslagen en aan de app doorgegeven bij de eerste keer openen na installatie. Dit betekent dat een gebruiker die op een retargeting-advertentie klikt, de app installeert en deze voor het eerst opent, nog steeds op de juiste productpagina of campagnepagina terechtkomt in plaats van helemaal opnieuw te moeten beginnen.<\/p>\n<p>Desondanks brengen oplossingen van derden extra complexiteit en kosten met zich mee. Als uw gebruiksscenario eenvoudig is en u geen attributie of uitgestelde koppeling nodig hebt, is het aanpassen van uw eigen AASA-configuratie de juiste eerste stap. Maar voor elke app die betaalde acquisitiecampagnes, re-engagement retargeting of gepersonaliseerde onboarding-flows uitvoert, is een oplossing zoals Branch echt nuttig om de kloof tussen advertentieklik en in-app-ervaring te overbruggen.<\/p>\n<p>Als gebruikers de app na installatie niet meer openen, of als de gebruikerservaring na een klik niet goed is en dit je campagneresultaten negatief be\u00efnvloedt, is het optimaliseren van de deep linking-laag een van de meest effectieve oplossingen die je kunt bedenken. <a href=\"https:\/\/wuzzon.com\/nl\/diensten\/app-groeistapel\/\"><strong><u>app-groeistackservices<\/u><\/strong><\/a> Bij Wuzzon behandelen we precies dit soort technische configuraties, in combinatie met uw bredere acquisitie- en retentiestrategie. Als u uw specifieke configuratie wilt bespreken met iemand die deze problemen al bij veel verschillende apps en platforms heeft gezien, bent u van harte welkom. <a href=\"https:\/\/wuzzon.com\/nl\/vraag-een-consult-aan\/\"><strong><u>Vraag een gratis consult aan<\/u><\/strong><\/a> En dan bekijken we het samen.<\/p>\n<div class=\"wp-block-seoaic-faq-block\">\n    <h2 class=\"seoaic-faq-section-title\">Veelgestelde vragen<\/h2>\n            <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Hoe lang duurt het voordat Apple mijn AASA-bestand opnieuw ophaalt nadat ik het heb hersteld?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Het CDN van Apple kan enkele uren tot meerdere dagen nodig hebben om een bijgewerkt AASA-bestand op te halen, en er is geen manier om handmatig een vernieuwing te starten. Voor testdoeleinden is de meest betrouwbare methode om de app opnieuw te installeren op een fysiek apparaat nadat u wijzigingen in uw AASA-bestand hebt aangebracht. Dit dwingt een nieuwe verificatie af tijdens de installatie. Voor bestaande gebruikers wordt de bijgewerkte configuratie pas van kracht nadat ze de app opnieuw hebben ge\u00efnstalleerd. Kritieke bugfixes vereisen daarom mogelijk een pushmelding of een prompt in de app om gebruikers aan te moedigen de app opnieuw te installeren.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Kunnen universele links na een iOS-update niet meer werken?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Ja, iOS-updates kunnen soms de koppelingen tussen universele links resetten of ongeldig maken, waardoor gebruikers de app opnieuw moeten installeren om de AASA-verificatie opnieuw te activeren. Apple heeft ook het AASA-bestandsformaat tussen iOS-versies gewijzigd, met name met de introductie van het bijgewerkte formaat in iOS 13 en later, dat de &#039;applinks&#039;-sleutelstructuur toevoegde. Als u na een belangrijke iOS-update een plotselinge afname in de prestaties van universele links opmerkt, raadpleeg dan de ontwikkelaarsdocumentatie van Apple om te controleren of uw AASA-bestand nog steeds overeenkomt met het huidige verwachte formaat.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Wat gebeurt er met universele links wanneer een gebruiker de link opent in een app van een derde partij, zoals Instagram of LinkedIn?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Veel apps van derden, waaronder Instagram, Facebook, LinkedIn en TikTok, gebruiken ingebouwde browsers (ook wel WebViews genoemd) die helemaal geen universele links ondersteunen. Wanneer een gebruiker op een link in een van deze apps tikt, opent iOS deze in de ingebouwde browser van de app in plaats van deze door te sturen naar het systeem. Dit betekent dat uw handler voor universele links nooit wordt geactiveerd. Dit is een bekende beperking van native universele links en een van de sterkste argumenten voor het gebruik van een deep linking-oplossing van derden, zoals Branch. Branch bevat namelijk een fallback-logica die specifiek is ontworpen om scenario&#039;s met ingebouwde browsers af te handelen en gebruikers toch naar de juiste bestemming binnen de app te leiden.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Werken universele links anders voor betaald advertentieverkeer afkomstig van Apple Search Ads of Meta?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Universele links gedragen zich hetzelfde, ongeacht de verkeersbron, maar de omgeving waarin de link wordt aangeklikt, maakt een significant verschil. Meta-advertenties openen bijvoorbeeld in een in-app-browser die universele links niet standaard ondersteunt. Dit betekent dat uw app niet direct vanuit een aangeklikte advertentie wordt geopend, zelfs niet als uw AASA-configuratie perfect is. Apple Search Ads werken binnen de App Store-omgeving, waardoor de dynamiek weer anders is. Voor betaalde acquisitiecampagnes is uitgestelde deep linking via een oplossing zoals Branch doorgaans noodzakelijk om de campagne-context betrouwbaar door te geven aan de eerste app die wordt geopend, ongeacht de verkeersbron.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Wat is de eenvoudigste manier om te controleren of mijn AASA-bestandsapp-ID correct is voordat ik de applicatie implementeer?            <\/h3>\n            <p class=\"seoaic-answer\">\n                De eenvoudigste manier is om drie dingen tegelijk te controleren: je Team ID in de Apple Developer-portal (te vinden onder Lidmaatschapsgegevens), je Bundle ID in App Store Connect en de app-ID-string in je AASA-bestand, die exact de indeling TEAMID.BUNDLEID moet hebben, zonder spaties of extra tekens. Je kunt ook de AASA-validatietool van Apple gebruiken op developer.apple.com\/news\/universal-links om opmaakfouten op te sporen voordat ze echte gebruikers treffen. Door deze controle elke keer uit te voeren wanneer je het bestand bijwerkt of een nieuwe app-variant maakt, zoals een staging- of white-label-build, voorkom je de meest voorkomende stille fout.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Kan ik universele links tegelijkertijd gebruiken voor zowel mijn productie- als stagingomgeving?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Ja, maar elk domein vereist een eigen AASA-bestand en een eigen bijbehorende domeinrechtenvermelding in Xcode. Je productiebuild moet `applinks:yourdomain.com` bevatten en je stagingbuild `applinks:staging.yourdomain.com`, die beide verwijzen naar het corresponderende AASA-bestand op dat subdomein of domein. Het door elkaar halen van deze bestanden, bijvoorbeeld door een stagingbuild te laten verwijzen naar je productie-AASA-bestand, is een veelvoorkomende bron van verwarring tijdens de kwaliteitscontrole en kan echte configuratieproblemen maskeren voordat ze de productieomgeving bereiken.            <\/p>\n        <\/div>\n                <div class=\"seoaic-faq-item\">\n            <h3 class=\"seoaic-question\">\n                Als mijn universele links werken, maar gebruikers op de verkeerde pagina terechtkomen, waar moet ik dan beginnen met debuggen?            <\/h3>\n            <p class=\"seoaic-answer\">\n                Als de app wel opent, maar naar het verkeerde scherm wordt doorgestuurd, werkt de AASA-configuratie zelf correct en ligt het probleem in de deeplink-routeringslogica van uw app, niet in de bestandshosting of de toegangsrechten. Begin met het loggen van de binnenkomende URL in de `openURL` of `continue` userActivity-handler van uw app om precies te bevestigen welk pad en welke parameters worden ontvangen. Traceer vervolgens hoe uw router die URL parseert en naar een specifiek scherm koppelt, en controleer op problemen met hoofdlettergevoeligheid, ontbrekende routehandlers of weggelaten parameters. Tools zoals Branch bieden een linkdata-inspector die precies laat zien welke parameters zijn doorgegeven, wat dit soort debuggen aanzienlijk kan versnellen.            <\/p>\n        <\/div>\n        <\/div>","protected":false},"excerpt":{"rendered":"<p>iOS universal links fail silently while Android works \u2014 here&#8217;s exactly why and how to fix it.<\/p>","protected":false},"author":16,"featured_media":12320,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[56],"tags":[],"class_list":["post-12134","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12134","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/comments?post=12134"}],"version-history":[{"count":1,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12134\/revisions"}],"predecessor-version":[{"id":12264,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/posts\/12134\/revisions\/12264"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/media\/12320"}],"wp:attachment":[{"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/media?parent=12134"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/categories?post=12134"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wuzzon.com\/nl\/wp-json\/wp\/v2\/tags?post=12134"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}