iOS Install Referrer: Alternativen ohne Fingerprinting

Auf Android ist die Zuordnung einer Empfehlung nach der Installation gelöst: Du hängst den Code an den Play-Store-Link, und deine App liest ihn beim ersten Start wieder aus. Dann baust du die iOS-Version, suchst dieselbe API – und es gibt keine.

Dieser Artikel zeigt, was Android dir bietet, warum iOS kein Gegenstück hat und welche Möglichkeiten es auf iOS tatsächlich gibt – geprüft an Apples Dokumentation. Am Ende stehen ein deterministisches Design und eine Entscheidungstabelle.

Quellen: Apple-Developer-Dokumentation, App Store Connect Hilfe und Android-Developers-Dokumentation, Stand Oktober 2026. APIs und Richtlinien ändern sich – prüf die verlinkten Seiten, bevor du baust. Zitate stehen im englischen Original.

Die Kurzfassung

Option	Funktioniert, bevor die App installiert ist?	Pro Nutzer?	Deterministisch?
Play Install Referrer (nur Android)	Ja	Ja	Ja
Universal Links	Nein – der Link öffnet deine Website	Ja	Ja
Fingerprinting / Wahrscheinlichkeits-Matching	Manchmal	Geraten	Nein – und Apple erlaubt es nicht
Zwischenablage	Ja, wenn die Zwischenablage überlebt	Ja	Ja, wenn es klappt
App Clip	Ja, wenn der Nutzer zuerst den Clip öffnet	Ja	Ja
AdAttributionKit / SKAdNetwork	Ja, für registrierte Werbenetzwerke	Nein – aggregiert	Nicht für Personen
Apple-Angebotscodes (Custom Codes)	Ja	Pro Angebot, nicht pro Code	Teilweise
Manuelle Code-Eingabe im Onboarding	Ja	Ja	Ja
Zuerst Web-Registrierung, dann App-Login	Ja	Ja	Ja

Keine iOS-API übergibt dir beim ersten Start einen Empfehlungscode. Ein verlässliches Setup kombiniert mehrere deterministische Wege.

Was Android dir gibt: den Play Install Referrer

Mit Googles Play Install Referrer API kann eine App „securely retrieve referral content from Google Play" – also Empfehlungsdaten sicher aus Google Play abrufen. Du hängst einen referrer-Parameter an den Store-Link – Googles Beispiel ist https://play.google.com/store/apps/details?id=com.example.package&referrer=example_referrer_source (hier dokumentiert) –, und nach der Installation liefert die Client-Bibliothek ein ReferrerDetails-Objekt:

• getInstallReferrer() – der Referrer-String aus dem Link
• getReferrerClickTimestampSeconds() – wann der Link geklickt wurde
• getInstallBeginTimestampSeconds() – wann die Installation begann
• getGooglePlayInstantParam() – ob der Nutzer in den letzten 7 Tagen deine Instant-Version genutzt hat

Die Service-Dokumentation nennt zusätzlich serverseitige Zeitstempel und die App-Version bei der Erstinstallation. Laut Google bleiben die Daten 90 Tage verfügbar. Für ein Empfehlungsprogramm ist das alles, was du brauchst: Der Code reist mit der Installation.

Warum iOS kein Gegenstück hat

Der App Store nimmt durchaus Parameter an einem Link an – nur nicht für deine App. App-Store-Kampagnenlinks tragen ein Provider-Token (pt=) und ein Kampagnen-Token (ct=), und die Ergebnisse landen in App Store Connect Analytics: aggregiert, und jede Kennzahl erscheint erst ab einem Schwellenwert von 5 im gewählten Zeitraum. Einen Weg, wie die installierte App den ct-Wert auslesen kann, dokumentiert Apple nicht.

Apples Attributions-Werkzeuge messen Kampagnen, nicht, wer wen eingeladen hat. Der Code muss die App also über einen Weg erreichen, den der Nutzer selbst geht.

Die Optionen im Einzelnen

1. Universal Links – nur wenn die App schon installiert ist

Universal Links sind normale HTTPS-Links, die iOS in deiner App statt im Browser öffnet. Ein Link wie https://example.com/r/ABC123 bringt den Code direkt ins Onboarding.

Der Haken steht in Apples eigener Beschreibung: „If the person hasn't installed your app, the system opens the URL in their default web browser". Ohne App öffnet sich also der Browser – und die Person, die du werben willst, hat die App meist noch nicht. Universal Links helfen nur, wenn sie zuerst installiert und danach auf den Link tippt.

Bevor du dich darauf verlässt:

• Du brauchst das Associated-Domains-Entitlement und eine apple-app-site-association-Datei. Laut Apples Dokumentation zu Associated Domains ruft Apples CDN die Datei innerhalb von 24 Stunden ab, und Geräte prüfen nach der Installation etwa einmal pro Woche auf Updates.
• Surft der Nutzer in Safari auf deiner Website und tippt auf einen Universal Link derselben Domain, bleibt iOS in Safari. Teste Empfehlungslinks aus Nachrichten und anderen Apps, nicht nur von deiner eigenen Seite.

Ein verwandter Helfer ist das Smart App Banner: Mit einem app-argument öffnet es die installierte App mit dieser URL. Laut Apple wird der Button nach einem Download über das Banner zu „Öffnen", wenn der Nutzer auf die Seite zurückkehrt – kommt er zurück, kommt also auch der Code an.

2. Deferred Deep Linking per Fingerprinting – was Apple dazu sagt

Um die Lücke „Link geklickt, App nicht installiert" zu überbrücken, setzen manche Deep-Linking-Lösungen auf Wahrscheinlichkeits-Matching: Beim Klick speichert ein Server Signale wie IP-Adresse, User-Agent, OS-Version und Uhrzeit; beim ersten Start schickt die App dieselben Signale, und der Server rät, welcher Klick zu welcher Installation gehört.

Apple beantwortet das in seinem FAQ zu User Privacy and Data Use. Auf die Frage, ob du Fingerprinting betreiben oder Gerätesignale zur Identifizierung nutzen darfst, lautet die Antwort Nein – „you may not derive data from a device for the purpose of uniquely identifying it" –, und Apps, die das tun oder solche SDKs einbinden, können abgelehnt werden. Die Dokumentation zu Required Reason APIs ergänzt: Fingerprinting ist nicht erlaubt, egal ob der Nutzer Tracking zugestimmt hat. Eine App-Tracking-Transparency-Einwilligung ändert daran nichts.

Für ein Programm, das Geld auszahlt, ist es außerdem ein wackliges Fundament. Treffer sind geraten: Ein Büro oder ein Mobilfunkanbieter kann viele Menschen hinter eine IP-Adresse setzen, und die Provision geht an die falsche Person. Die Signale werden schlechter – mit iCloud Privat-Relay sehen Websites in Safari eine temporäre IP-Adresse (Apple Support). Und „der Match-Score war zu niedrig" ist keine Antwort, die ein Empfehlungsgeber akzeptiert.

3. Die Zwischenablage – und die Einfügen-Abfrage seit iOS 16

Die Landingpage kopiert den Code (oder den ganzen Empfehlungslink), und die App liest ihn beim ersten Start. Entweder liegt der Code in der Zwischenablage oder nicht – deterministisch.

iOS hat das schrittweise verschärft. Seit iOS 14 benachrichtigt das System den Nutzer, wenn eine App ohne erkennbare Absicht Inhalte einer anderen App aus der Zwischenablage liest. Und laut UIPasteControl-Dokumentation gilt: „In iOS 16 and later, programmatic pasting raises a user alert that prompts the user for approval". Eine Berechtigungsabfrage beim ersten Start, bevor der Nutzer weiß, worum es geht, ist ein schlechter Einstieg.

Die Lösung: Lass den Nutzer selbst einfügen.

• UIPasteControl / SwiftUI-PasteButton (ab iOS 16) – ein System-Button, den der Nutzer antippt; laut Apple fügt er „without a user prompt" ein, also ohne Abfrage.
• Mustererkennung – detectPatterns(for:completionHandler:) (ab iOS 14, async-Varianten seit iOS 15) verrät dir, ob die Zwischenablage wahrscheinlich eine Web-URL, eine Zahl oder einen Suchbegriff enthält. Weil der Inhalt dabei nicht offengelegt wird, benachrichtigt das System den Nutzer nicht. Die detectValues-Methoden liefern dagegen Inhalte – und lösen die Benachrichtigung aus.

Also: Kopier den kompletten Empfehlungslink (eine URL), prüf still darauf und zeig erst dann einen Einfügen-Button:

let found = try? await UIPasteboard.general.detectedPatterns(for: [\.probableWebURL])
showPasteInvite = found?.contains(\.probableWebURL) == true
// Im Onboarding: PasteButton(payloadType: String.self) { items in parseCode(items.first) }

Der Nutzer kann vor dem ersten Start etwas anderes kopieren – behandle Einfügen deshalb als Abkürzung neben einem Code-Feld.

4. App Clips – am nächsten an einem Install Referrer

Ein App Clip ist ein kleiner Teil deiner App, der ohne vollständige Installation startet – über einen Link, QR-Code, NFC-Tag oder App Clip Code. Beim Start erhält er seine Aufruf-URL (Responding to invocations), https://example.com/r/ABC123 übergibt dem Clip also den Code.

Der Clip kann in einen gemeinsamen App-Group-Container oder geteilte UserDefaults schreiben. Installiert der Nutzer die vollständige App, ersetzt sie den Clip und kann diese Daten lesen (Daten zwischen App Clip und App teilen). Speicher den Code dort, und die App findet ihn beim ersten Start.

Nachteile: Das ist echte native Arbeit (ein zusätzliches Xcode-Target, App-Clip-Experiences in App Store Connect, Apples Größenlimits), und es erfasst nur Nutzer, die den Clip vor der Installation öffnen. Clips können außerdem keine Tracking-Erlaubnis anfragen – hier egal, denn der Nutzer bringt den Code selbst mit.

5. AdAttributionKit und SKAdNetwork – aggregiert, nicht pro Nutzer

Apples Installations-Attribution heißt AdAttributionKit (ab iOS 17.4) und davor SKAdNetwork, dessen Seite für App-Store-Werbekampagnen inzwischen auf AdAttributionKit verweist. Beide sind für Werbenetzwerke gedacht, die sich bei Apple registrieren und ihre Anzeigen signieren. Postbacks kommen laut Dokumentation frühestens nach 24 bis 48 Stunden, ihr Detailgrad hängt von Crowd-Anonymity-Stufen ab, und das signierte Postback „doesn't include user- or device-specific data" – enthält also keine nutzer- oder gerätebezogenen Daten.

Das richtige Werkzeug für Werbekampagnen, das falsche für Empfehlungen: Deine Empfehlungsgeber sind keine Werbenetzwerke.

6. Apple-Angebotscodes mit Custom Codes

Angebotscodes für Abos geben einen vergünstigten oder kostenlosen Zeitraum. Custom Codes sind benannte Codes wie SPRINGPROMO, bis zu 64 Zeichen, einlösbar über eine Einlöse-URL oder in deiner App (ab iOS 14). Stand Oktober 2026 nennt die App Store Connect Hilfe bis zu 1 Million Einlösungen pro App und Quartal und bis zu 10 aktive Angebote pro Abo-SKU.

Gut, um die eingeladene Person zu belohnen, begrenzt für die Zuordnung:

• In StoreKit enthält die Angebots-ID der Transaktion den Referenznamen des Angebots; ein Feld für den einzelnen Custom Code beschreibt die Dokumentation nicht. Um Empfehlungsgeber zu unterscheiden, bräuchte jeder ein eigenes Angebot – und 10 pro SKU reichen nicht weit.
• In der App wird über Apples System-Sheet eingelöst, und Apple sagt, du sollst keine eigene Oberfläche verwenden – deine App sieht also nicht, was eingetippt wurde.

Nutz sie für wenige große Partner oder als Rabatt zusätzlich zu deinem eigenen Code – nicht als den Code selbst.

7. Manuelle Code-Eingabe im Onboarding

Die unspektakulärste Option ist die verlässlichste: ein Feld „Einladungscode?" im Onboarding oder auf der Paywall. Es funktioniert für jeden Weg – App-Store-Suche, ein laut genannter Code, ein Screenshot. Halte die Hürde niedrig: kurze Codes ohne verwechselbare Zeichen (0/O, 1/I), Groß-/Kleinschreibung egal, sofortige Prüfung – und füll das Feld vor, sobald ein Code auf anderem Weg ankommt.

8. Zuerst Web-Registrierung, dann Konto-Verknüpfung

Hat dein Produkt Konten, umgehst du das Installationsproblem ganz: Der Nutzer registriert sich auf deiner Website, der Code wird mit dem Konto gespeichert, und wenn er sich in der App anmeldet, weiß dein Backend schon, wer ihn eingeladen hat.

Für In-App-Käufe verknüpfst du die Transaktion mit diesem Konto: StoreKits appAccountToken (ab iOS 15) nimmt eine UUID für deinen Nutzer, und der App Store gibt sie in der resultierenden Transaktion zurück.

Ein deterministisches Design, das funktioniert

Jeder Weg endet am selben Punkt – ein Code, der an einem Nutzer hängt:

1. Jeder Empfehlungsgeber bekommt Code und Link auf einer Domain, die deine App verarbeitet, z. B. https://example.com/r/ABC123.
2. App installiert: Der Universal Link öffnet die App, das Onboarding zeigt den Code vorausgefüllt, der Nutzer bestätigt.
3. App nicht installiert: Der Link öffnet eine Landingpage mit dem Code in großer Schrift, einem „Code kopieren"-Button (kopier den ganzen Link, damit die Mustererkennung ihn findet), einem App-Store-Button und – falls du Konten hast – „Im Web registrieren".
4. Erster Start: Das Onboarding zeigt das Code-Feld, dazu einen Einfügen-Button, wenn wahrscheinlich eine URL in der Zwischenablage liegt. Lies die Zwischenablage nie still aus.
5. Web-Registrierung: Der Code hängt schon am Konto; der App-Login verknüpft ihn, und appAccountToken bindet den Kauf daran.
6. Serverseitig: Code prüfen, Selbstempfehlungen blockieren, Code an das Abo hängen.

Wer all das überspringt, wird nicht zugeordnet. Das ist der ehrliche Preis dafür, nicht zu raten.

Entscheidungstabelle

Deine Situation	Nutze
Abo-App, Installationen kommen aus dem App Store	Code-Eingabe + Vorausfüllen per Universal Link + Einfügen-Button
Nutzer registrieren sich meist zuerst im Web	Verknüpfung über die Web-Registrierung + appAccountToken; Code-Eingabe als Fallback
QR-Codes, Plakate, Events	App Clip, der den Code über eine App Group weitergibt – wenn du native Arbeit investieren kannst
Die eingeladene Person soll einen Rabatt bekommen	Apple-Angebotscode für den Rabatt, eigener Code für die Zuordnung
Du misst bezahlte Werbekampagnen	AdAttributionKit / SKAdNetwork über dein Werbenetzwerk
Dich reizt „magisches" Install-Matching	Lass es – Apple erlaubt Fingerprinting nicht, mit oder ohne Einwilligung

Checkliste vor dem Release

• Code-Feld im Onboarding und auf der Paywall, sofort geprüft
• Universal Links eingerichtet und aus Nachrichten getestet, nicht nur von deiner eigenen Seite
• Zwischenablage nur über PasteButton/UIPasteControl; stille Prüfungen nur per Mustererkennung
• Web-Registrierungen speichern den Code serverseitig; In-App-Käufe tragen appAccountToken
• Kein SDK in der App, das Fingerprinting oder Wahrscheinlichkeits-Matching betreibt
• Programmbedingungen in der App sichtbar (siehe die App-Store-Regeln für Empfehlungsprogramme)

Wo AppThunder hilft

AppThunder Referrals baut genau auf diesem deterministischen Modell auf: Eine Empfehlung zählt nur, wenn wirklich ein Code ankommt – ohne Geräte-Fingerprinting, ohne Wahrscheinlichkeits-Matching. Codes kommen auf drei Wegen an: über den Abo-Webhook (deine App speichert den Code als Subscriber-Attribut at_ref, und In-App-Abo-Events tragen ihn mit), über den Stripe-Webhook für Web-Checkouts und über eine REST-API für dein Backend (POST /codes, /referrals, /events mit dem Secret Key; GET /codes/:code mit dem Public Key, um einen ins Onboarding-Feld getippten Code zu prüfen). Es gibt Copy-Paste-Vorlagen für Swift, Kotlin, React Native, Flutter und Web; das Web-Snippet hält einen Code nach dem First-Touch-Prinzip 90 Tage lang auf demselben Gerät fest – das deckt „jetzt besuchen, später im Web registrieren" ab.

Provisionen bleiben standardmäßig 30 Tage in der Haltefrist, Erstattungen stornieren sie, Selbstempfehlungen sind blockiert, und du zahlst selbst aus Exporten aus (PayPal Mass Pay, Wise-Sammelüberweisung, CSV) – AppThunder hält oder bewegt nie Geld. Stand Oktober 2026 kostet es pauschal 19 € pro Monat netto, ohne Umsatzbeteiligung.

Was es nicht kann: einen Nutzer zuordnen, der nie einen Code eingibt, einfügt oder mitbringt – das ist der Preis dafür, nicht zu raten. Es richtet weder deine Universal Links noch Smart App Banner oder App Clip ein, und es kann dir auf iOS keinen Install Referrer geben, weil es keinen gibt.

FAQ

Gibt es auf iOS ein Gegenstück zum Play Install Referrer? Nein. Apples Installations-Attribution (AdAttributionKit, SKAdNetwork, Kampagnenlinks) ist aggregiert. Ein Code pro Nutzer muss über einen Weg ankommen, den der Nutzer geht – Link, Einfügen, App Clip, Eingabe oder Konto.

Darf ich Fingerprinting nutzen, wenn der Nutzer Tracking erlaubt? Nein. Laut Apples Dokumentation ist Fingerprinting unabhängig von der Tracking-Erlaubnis nicht erlaubt.

Darf ich beim ersten Start die Zwischenablage lesen? Seit iOS 16 löst ein programmatisches Lesen eine Berechtigungsabfrage aus. Nutz PasteButton oder UIPasteControl, damit der Nutzer bewusst einfügt – ohne Abfrage.

Können Apple-Angebotscodes meine Empfehlungscodes ersetzen? Nicht ganz. StoreKit identifiziert das Angebot über seinen Referenznamen, nicht über den einzelnen Custom Code, und es gibt höchstens 10 aktive Angebote pro Abo-SKU.