Como configurar Universal Links e App Links depois do Firebase

Se ainda existem links antigos de app em QR code, email, landing page, mídia paga, bio social ou referral, o seu problema já não é só "substituir o Firebase". O seu problema é manter links públicos funcionando sem quebrar abertura de app, fallback nem medição.

É por isso que vale separar o que o Firebase Dynamic Links juntava em um produto só:

1. a URL pública com marca
2. a abertura do app instalado
3. o fallback para App Store, Google Play ou web
4. a preservação de UTM e parâmetros de campanha

Segundo a FAQ oficial do Firebase Dynamic Links, o serviço foi encerrado em 25 de agosto de 2025. Se esses links ainda vivem em campanhas, fluxos de onboarding ou materiais já publicados, o caminho mais seguro é reorganizar a camada de links em vez de procurar um clone 1:1.

O que Universal Links e App Links realmente resolvem

Apple Universal Links

Apple Universal Links permitem abrir um app iOS instalado a partir de um link HTTPS normal quando:

• o domínio está associado corretamente ao app
• a capability foi configurada
• o domínio entrega um apple-app-site-association válido
• o app consegue tratar o path recebido

Android App Links

Android App Links fazem o equivalente no Android. Para isso você precisa de:

• domínio verificado
• manifest correto
• assetlinks.json válido
• tratamento de rotas dentro do app

O que isso não cobre sozinho

Universal Links e App Links não resolvem por conta própria:

• fallback para desktop
• destino para quem não tem o app
• URL com marca para campanhas
• roteamento por dispositivo
• preservação de UTM
• mudanças temporárias em campanhas ou lançamento

É aí que entra a camada de redirect.

A arquitetura mais prática depois do Firebase

Para a maioria dos times, a estrutura mais estável se parece com isto:

go.suamarca.com/promo
  -> detecção de dispositivo no edge
  -> iPhone com app: Universal Link
  -> iPhone sem app: App Store
  -> Android com app: App Link
  -> Android sem app: Google Play
  -> Desktop: landing page, docs ou página com QR

Essa abordagem é boa porque:

• o domínio continua sob seu controle
• o fallback fica explícito
• marketing compartilha uma URL limpa
• mobile, growth e produto testam o mesmo fluxo real

O gargalo mais comum: os arquivos de verificação

Na prática, muita equipe não trava no conceito. Trava em:

• apple-app-site-association
• assetlinks.json

Isso acontece bastante quando o site principal está em Shopify, Webflow, Wix ou algum CMS que complica arquivos em root ou .well-known.

Aqui a UrlEdge ajuda de forma prática. Com custom response, dá para servir esses arquivos no edge sem transformar isso em outro mini projeto de infra.

Como montar a migração

1. Faça o inventário de todos os links públicos

Revise:

• campanhas pagas
• QR codes
• botões de download
• emails de lifecycle
• páginas de suporte
• links na bio e redes sociais
• flows de referral

2. Separe abertura de app e fallback

Para cada link importante, responda:

1. se o app estiver instalado, ele deve abrir?
2. se não estiver instalado, a pessoa vai para a loja ou para a web?
3. o que desktop deve ver?
4. UTM e outros parâmetros precisam ser mantidos?

3. Escolha o domínio público canônico

Normalmente algo como:

• go.suamarca.com
• app.suamarca.com
• links.suamarca.com

Isso evita depender de hostname de terceiro para o link que vai para campanha e material público.

4. Valide os arquivos de associação

Use sempre a documentação oficial:

• Apple Universal Links
• Android App Links

Se essa etapa estiver errada, a abertura nativa seguirá inconsistente, mesmo que o redirect geral pareça correto.

5. Defina fallback explícito

Por exemplo:

• iOS com app -> app
• iOS sem app -> App Store
• Android com app -> app
• Android sem app -> Google Play
• desktop -> landing ou QR handoff

Não deixe isso implícito.

6. Teste em contexto real

Confira pelo menos:

• iPhone Safari
• Android Chrome
• navegadores in-app de campanhas sociais
• desktop
• QR aberto no celular
• links com UTM

É aí que aparece a diferença entre "o link responde" e "a experiência está correta de ponta a ponta".

Erros mais comuns

Achar que roteamento por dispositivo substitui Universal Links e App Links

Não substitui. O roteamento escolhe o destino. Universal Links e App Links cuidam da abertura nativa confiável no sistema operacional.

Esquecer desktop

Um fallback desktop mal pensado quebra rápido páginas de ajuda, docs, materiais de vendas e fluxos com QR.

Perder UTM

Se os links vivem em email, QR, paid social, influenciadores ou CRM, os parâmetros precisam ser preservados de forma intencional.

Acumular camadas demais

Quanto mais encurtadores, redirects intermediários e páginas de transição você soma, mais lenta e confusa fica a análise do fluxo.

Onde a UrlEdge entra

UrlEdge é forte quando você quer juntar:

• URL pública com marca
• roteamento por dispositivo
• fallback para loja ou web
• preservação de UTM
• analytics de clique
• entrega dos arquivos de verificação no edge

Isso não substitui sozinho toda a parte de mobile attribution avançada. Mas devolve controle sobre a parte mais visível: o link público e o comportamento do fallback.

Resumo

Depois do Firebase Dynamic Links, a melhor resposta raramente é "outra caixa preta". Na maioria das vezes, é uma arquitetura mais limpa:

• domínio com marca
• roteamento por dispositivo
• Universal Links e App Links bem validados
• fallback explícito
• parâmetros de campanha preservados

Menos mágica. Mais controle.