Deep link. Open the app. Fall back gracefully.
Manifest Universal Links e App Links serviti dal tuo dominio personalizzato. iOS apre la tua app al tocco; Android fa lo stesso. Fallback del browser su desktop.
- Universal Links (iOS) and App Links (Android) served from your domain
- Deferred deep links — context survives app install
- Smart platform detection with graceful fallbacks
- No SDK required — works with standard OS mechanisms
Universal Links & App Links
Manifest files, auto-served from your domain
iOS Universal Links require an apple-app-site-association file. Android App Links require assetlinks.json. Elido generates and serves both from your custom domain automatically — no separate hosting, no manual file management.
- iOS Universal LinksBundle ID + Team ID → AASA served at /.well-known/ automatically
- Android App LinksPackage name + SHA-256 fingerprint → assetlinks.json, HTTPS enforced
- Smart-link fallbackApp not installed → App Store / Play Store via rule-based routing
- UTM passthroughUTM parameters preserved to store URL — attribution doesn't break
- No SDK in your appOS-level interception only; intent-filter and continueUserActivity
{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yours.app", "paths": [ "/product/*", "/referral/*", "/invite/*" ] } ] } }
[{ "relation": [ "delegate_permission/ common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "com.yourcompany.app", "sha256_cert_fingerprints": [ "AB:12:CD:34:EF:56:..." ] } }]
Served from your custom domain automatically. Configure bundle ID + Team ID (iOS) or package name + SHA-256 fingerprint (Android) in domain settings — Elido generates and hosts both files.
Deferred deep links
Context that survives the install
When the app isn’t installed, the user goes to the store, installs, and opens the app. Deferred deep-linking passes the original deep-link context through that journey so the app can land the user on exactly the right screen after first launch.
- 01
Clicks link
User taps an Elido short link — from email, social, QR.
go.yourcompany.com/p/12345 - 02
No app → Store
App not installed. OS detects from AASA / assetlinks check. Falls back to App Store or Play Store.
iOS → App Store · Android → Play Store - 03
Installs app
User installs from the store. The install referrer carries the click context as a query parameter.
click_id + UTM preserved in referrer URL - 04
Opens app
App opens for the first time. MMP reads install referrer; maps click_id to the install event.
Appsflyer / Adjust / Branch picks it up - 05
Lands on exact page
App routes to the originally linked screen — product/12345 — as if the user had the app already.
product/12345 — context preserved through install
The click_id and UTM parameters from the original short link are passed as query parameters to the store URL. Mobile Measurement Platforms (MMPs) that capture the install referrer — Appsflyer, Adjust, Branch — can match the install to the originating click. Full deferred deep-linking (passing in-app context through install) requires the MMP SDK in your app; Elido covers the link layer.
Smart platform detection
One link. Three redirect paths.
The edge reads User-Agent and platform signals at the redirect layer — before any JS runs. iPhone gets Universal Links, Android gets App Links, desktop gets your web fallback. No JavaScript redirect delay; no client-side platform detection.
- UA parsing at the edge, sub-millisecond
- iOS → Universal Link interception by the OS
- Android → App Link interception via intent-filter
- Desktop → web URL, no store detour
- In-app browsers detected and redirected to system browser
- Composes with smart-link rules — geo + device + deep-link
What you can do
- Apple App Site Association
- Android Asset Links
- Regole Smart-link per fallback dello store
- Testato con adb e xcrun
Come funzionano realmente i deep link — e dove si rompono
Universal Links e App Links sono meccanismi a livello di sistema operativo. La configurazione è semplice; i casi limite no. Questa sezione copre il quadro completo.
apple-app-site-association servito automaticamente dal tuo dominio personalizzato
I Universal Links richiedono un file apple-app-site-association (AASA) in /.well-known/apple-app-site-association sul tuo dominio personalizzato. iOS scarica questo file quando la tua app viene installata; mappa il tuo dominio al bundle ID e al team ID della tua app. Se la mappatura è corretta, toccando un link HTTPS sul tuo dominio in qualsiasi app iOS (Safari, Mail, Twitter, Instagram) si aprirà direttamente la tua app invece di andare su un browser. Elido genera e serve il file AASA dal percorso well-known del tuo dominio personalizzato automaticamente, in base al bundle ID e al team ID configurati nelle impostazioni del dominio. Non è necessario ospitare il file separatamente. iOS mette in cache il file AASA e lo riscarica periodicamente; se modifichi la configurazione del bundle ID nelle impostazioni del dominio di Elido, il nuovo AASA è attivo in pochi secondi, ma i dispositivi iOS lo rileveranno al prossimo aggiornamento della cache (solitamente 24-48 ore, o alla reinstallazione dell'app). Testato con il validatore Apple AASA ad ogni rilascio di Elido.
assetlinks.json servito automaticamente — impronta SHA-256 dalla tua chiave di firma
Android App Links richiedono un file Digital Asset Links in /.well-known/assetlinks.json sul tuo dominio. Il file mappa il tuo dominio al package name della tua app e all'impronta SHA-256 del tuo certificato di firma. Android verifica questo file durante l'installazione dell'app e periodicamente. Elido lo serve automaticamente dal tuo dominio personalizzato, in base al package name e all'impronta SHA-256 configurati. La verifica di Android richiede HTTPS (imposto dal TLS di Elido sul dominio personalizzato) e il file deve rispondere entro pochi secondi (anche questo gestito). Una modalità di errore comune: diverse chiavi di firma per le build di debug e release hanno impronte SHA-256 diverse. Configura entrambe le impronte nelle impostazioni del dominio di Elido se stai testando con una build di debug; le build di produzione necessitano solo dell'impronta di release. Testato con adb shell pm get-app-links ad ogni rilascio.
App installata → deep link. App non installata → store. Desktop → web. UTM preservati ovunque.
La catena di fallback è impostata per link o per dominio nelle impostazioni di Elido. Per uno short link con configurazione deep-link: se il sistema operativo intercetta il tocco (app installata, dominio verificato), l'app si apre. In caso contrario (app non installata), il link si apre nel browser; la destinazione del browser dovrebbe essere il link all'App Store / Play Store o un fallback web. Le regole degli smart-link gestiscono questo in modo pulito: configura una regola per iOS → URL App Store, una regola per Android → URL Play Store e il fallback alla destinazione web. I parametri UTM dello short link originale vengono preservati negli URL di fallback in modo che l'attribuzione non si interrompa quando l'utente arriva allo store. Il deep-linking differito (passare un percorso deep-link specifico attraverso un'installazione, in modo che l'app si apra sulla schermata corretta dopo l'installazione) richiede un SDK nell'app — Elido non lo fornisce. Per il deep-linking differito, sono ancora necessari Appsflyer, Adjust o Firebase App Distribution.
Retargeting post-installazione: click ID passato alla destinazione per l'attribuzione
Su un reindirizzamento deep-link, Elido passa il click_id come parametro di query all'URL di fallback. Se l'utente atterra nell'App Store e installa l'app, il click_id è nell'URL di riferimento ma non viene propagato automaticamente nell'app dopo l'installazione — ciò richiede SKAdNetwork su iOS o un SDK per deep-link differito su Android. Cosa fa Elido: passa il click_id e i parametri UTM all'URL dello store in modo che una piattaforma di attribuzione mobile (MMP) che sta acquisendo il referrer dell'installazione possa rilevarli. Questo funziona con Appsflyer e Adjust se passi il click_id nel parametro campaign dell'URL dello store. Se non stai usando una MMP, il click_id nell'URL dello store viene effettivamente perso dopo l'installazione.
Migrazione da Firebase Dynamic Links (sunset 2025)
Firebase Dynamic Links è stato dismesso da Google nel 2025. Elido può gestire il pattern principale: un unico short link HTTPS che apre la schermata corretta in un'app installata, torna allo store in caso contrario e al web su desktop. Configura AASA e assetlinks.json nelle impostazioni del dominio di Elido (sostituisce l'hosting Firebase di questi file), aggiorna i tuoi link di condivisione per puntare agli short link di Elido invece degli URL page.link e configura la catena di fallback tramite le regole smart-link. Cosa non replica Elido: il deep-linking differito di Firebase (contesto deep link post-installazione tramite l'SDK Firebase) e i deep link di Firebase App Distribution. Se la tua app si affida pesantemente al deep-linking differito, avrai bisogno di Appsflyer, Adjust o Branch insieme a Elido per il livello di attribuzione. Per le app che necessitano solo di 'apri la schermata corretta se installata, altrimenti vai allo store', Elido sostituisce completamente Firebase Dynamic Links.
Team mobile che utilizzano i deep link di Elido
I nomi sono segnaposto per ora — i nomi dei clienti reali appariranno qui man mano che i casi studio verranno pubblicati.
“Siamo passati da Firebase Dynamic Links la settimana in cui hanno annunciato la dismissione. La configurazione di AASA e assetlinks.json in Elido ha richiesto mezza giornata. La catena di fallback smart-link ha sostituito la logica dell'SDK Firebase che avevamo nell'app per l'instradamento allo store.”
“L'analisi dei clic per link sui deep link ci ha detto che il 35% dei nostri link di condivisione veniva cliccato su desktop — non avevamo configurato alcun fallback web. Aggiungere il fallback ha richiesto 10 minuti; il tasso di conversione dei link di condivisione è aumentato perché gli utenti che cliccavano da desktop potevano ora completare l'azione.”
“Usiamo gli short link di Elido con configurazione deep-link per i programmi di referral. Il passthrough UTM all'URL dell'App Store significa che la nostra MMP rileva correttamente il referrer dell'installazione — l'attribuzione funziona senza lavoro personalizzato sull'SDK da parte nostra.”
Elido deep links vs Branch.io vs Adjust vs Firebase Dynamic Links (sunset)
Branch e Adjust sono piattaforme complete di attribuzione mobile — più potenti per il deep-linking differito e l'attribuzione MMP. Elido è lo strumento giusto quando i deep link fanno parte di una configurazione di abbreviazione più ampia, non il prodotto principale.
| Feature | Elido | Branch.io | Adjust |
|---|---|---|---|
| Universal Links (iOS) | AASA servito automaticamente dal tuo dominio | Gestito completamente su scala | No — solo MMP, non host per deep-link |
| App Links (Android) | assetlinks.json servito automaticamente dal tuo dominio | Gestito completamente | No |
| SDK richiesto nell'app | No — intercettazione a livello di sistema operativo | Sì — SDK Branch | Sì — SDK Adjust |
| Deep-linking differito | No — richiede SDK nell'app | Sì — funzionalità principale | Sì — con SDK Adjust |
| Mobile attribution (MMP) | Passthrough click ID; cablaggio MMP manuale | MMP nativo — integrazioni Appsflyer, Kochava | Piattaforma MMP completa |
| UTM passthrough allo store | Sì — tramite parametro query sull'URL di fallback | Sì, con contesto di attribuzione | Sì |
| Analytics on link clicks | ClickHouse — geo, dispositivo, per link | Analitiche approfondite di attribuzione mobile | Dati di attribuzione installazione + evento |
| Sostituzione Firebase Dynamic Links | Sì per il pattern di base; no deep-link differito | Sostituzione completa incluso differito | Parziale — solo lato MMP |
Domande sui deep link
Ho bisogno di un SDK Branch o di un qualsiasi SDK nella mia app per usare i deep link di Elido?
No. I deep link di Elido utilizzano iOS Universal Links e Android App Links — meccanismi a livello di sistema operativo. La tua app deve solo gestire l'URL in entrata nel modo standard di iOS (scene:openURLContexts o application:continueUserActivity) o Android (intent-filter nel manifest). Non viene installato alcun SDK di terze parti; il sistema operativo gestisce l'intercettazione in base ai file AASA e assetlinks.json che Elido serve dal tuo dominio.
Qual è il flusso di configurazione AASA?
Nelle impostazioni del dominio Elido → Deep link: inserisci il bundle ID della tua app iOS (es. com.tuasocieta.app) e il Team ID Apple (stringa di 10 caratteri dal tuo account Apple Developer). Elido genera il JSON AASA e lo serve in /.well-known/apple-app-site-association sul tuo dominio personalizzato. Verifica che sia raggiungibile con curl prima di inviare la tua app a TestFlight o all'App Store. iOS scarica il file AASA durante l'installazione dell'app su dispositivi con iOS 9+.
Posso avere più app su un solo dominio?
Sì — il file AASA supporta più voci per app. Configura il bundle ID e il Team ID di ogni app nelle impostazioni del dominio; Elido genera un AASA combinato con tutte le app elencate. Anche assetlinks.json di Android supporta più combinazioni di package name + impronta. Caso d'uso comune: app principale e un App Clip, o app principale e un'estensione widget.
Dismissione di Firebase Dynamic Links — qual è il percorso di migrazione?
Sostituisci gli URL brevi page.link con gli short link di Elido (il tuo dominio personalizzato o il dominio condiviso di Elido). Configura AASA e assetlinks.json nelle impostazioni del dominio di Elido. Imposta la catena di fallback tramite le regole smart-link (regola iOS → App Store, regola Android → Play Store, fallback → web). Aggiorna la generazione dei link di condivisione nella tua app per chiamare l'API create_link di Elido invece di Firebase. Cosa non migra: se la tua app si affida al deep-linking differito di Firebase (passaggio dell'intento post-installazione), avrai bisogno di Branch o Adjust per quella parte.
Come posso testare i Universal Links prima di pubblicare sull'App Store?
Usa xcrun simctl openurl booted 'https://go.tuasocieta.com/test-slug' con la tua app installata su un simulatore. Su un dispositivo fisico con una build di debug, premi a lungo su un link in Safari e vedi se appare 'Apri nella tua app'. Apple fornisce anche l'App Association File Validator su developer.apple.com — incolla l'URL del tuo AASA e controlla raggiungibilità, Content-Type e validità JSON. L'AASA di Elido supera tutti e tre i controlli.
Cos'è il deep-linking differito e perché Elido non lo fa?
Il deep-linking differito passa il contesto (es. 'l'utente stava visualizzando il prodotto ID 123') dal clic sul link attraverso l'installazione di un'app e al primo avvio dell'app. Richiede un SDK di fingerprinting o attribuzione nell'app (Branch, Appsflyer, Adjust) che abbini l'installazione al clic durante il processo di installazione. Elido non installa codice SDK nella tua app; serviamo solo AASA e assetlinks.json. Senza l'SDK, non c'è alcun meccanismo per passare il contesto attraverso un'installazione. Per il caso d'uso base 'apri la schermata corretta se installata', Elido è sufficiente. Per passare l'intento attraverso l'installazione, è necessaria una MMP.
Posso usare i deep link sul dominio condiviso di Elido (s.elido.me)?
No. I Universal Links e gli App Links richiedono il tuo dominio — non puoi rivendicare *.elido.me come dominio Universal Link per la tua app. I deep link richiedono un dominio personalizzato su Pro o Business. Il dominio personalizzato è quello che configuri nel tuo AASA e assetlinks.json, ed Elido serve quei file da esso.
Come gestisco il caso in cui il browser dell'utente blocca l'intercettazione dell'app?
Alcuni browser (in particolare Chrome su Android precedente alla 6.0 e alcuni browser in-app come quello di Instagram) bloccano l'intercettazione di App Links o Universal Link. L'URL di fallback è ciò che vedono. Per i browser in-app: reindirizza prima al browser di sistema utilizzando un URL intent (Android) o un messaggio per l'utente. Per i browser in-app di Instagram / TikTok: l'approccio standard è mostrare un messaggio 'tocca per aprire nel tuo browser'. Elido non inserisce questo messaggio automaticamente — l'URL di fallback è la tua destinazione e tu controlli cosa succede lì.
Keep reading
Configurazione dominio personalizzato — richiesta per i deep link; AASA e assetlinks.json serviti dal tuo hostname.
iOS → App Store, Android → Play Store, desktop → web — la catena di fallback che utilizza le regole smart-link.
Come i team di prodotto utilizzano i deep link insieme a varianti A/B e regole smart-link.
Integrazioni MMP — Appsflyer, Adjust e Branch per il deep-linking differito insieme a Elido.
Pronto a provarlo?
Inizia con il piano gratuito, effettua l'upgrade quando hai bisogno di un dominio personalizzato.