Estudo de caso: como o Baifo envia um único QR para a App Store no iOS e para a web no resto

Baifo é um app de oração / bênçãos online — e um cliente do DYQR. Eles lançaram recentemente duas superfícies de compartilhamento: um pôster «recomendar a amigos» e um pôster do registro de oração. Ambos têm um QR com uma regra simples: se o dispositivo que escaneia for um iPhone, enviar para a App Store baixar o app; se for outro tipo de dispositivo (ainda sem app), guiar o usuário para a versão web.

Quase todo time que promove um app mobile esbarra nisso. Abaixo está a história de integração deles e, ao mesmo tempo, um tutorial que você pode precisar.

Por que não um fork caseiro de User-Agent?

No início pensaram em uma rota /get em baifo.life: ler o User-Agent, detectar iOS com regex e fazer 302 para o destino certo. O QR apontaria sempre para essa URL.

Funciona — mas implica montar uma infraestrutura completa:

• Regras de roteamento — depois, links da loja Android, destinos por região: cada mudança = código, testes e redeploy
• Analítica do QR — além do scan, é preciso stats de cliques, quebra por dispositivo, etc.
• Crescimento de canais — mais campanhas = mais QR; reconstruir um sistema de links curtos internamente é caro demais de manter

Então o time do Baifo colocou esse trabalho numa plataforma de QR / links curtos — a nossa.

Tutorial: roteamento por OS com DYQR

Os passos seguem o assistente Novo link em cinco etapas (capturas reais de app.dyqr.me). Smart Routing (incl. regras por OS) é pago — conta free vê «Upgrade required» no passo 2. Prefere o terminal? CLI / API no final.

1. Criar um link curto com destino web padrão

Painel → Novo link. Defina o destino padrão (todo scan que não bater em uma regra cai aqui):

• Title: ex. «Download app Baifo»
• Default destination: https://baifo.life/

Escolha o padrão para «a maioria das pessoas» — no Baifo, a web. O iOS é sobrescrito por uma regra no próximo passo.

2. Adicionar Smart Routing: OS = iOS → App Store

No passo Smart Routing, adicione uma regra:

• When: Operating system
• Matches: iOS
• Then go to: https://apps.apple.com/cn/app/id6782394476 (sua URL da App Store)

Notas:

• Use Operating system, não Device — Device só separa mobile / desktop e não distingue iPhone de Android
• Com a regra ativa, iPhone (incluindo o navegador in-app do WeChat) faz 302 para a App Store; o resto vai para a web padrão
• Depois, loja Android ou lojas por país = só editar regras, sem novo QR nem release do app

3. Exportar o QR e colocar no pôster

Último passo do assistente: pré-visualize e exporte o QR. O pôster embute só esta imagem (codifica o link curto, não a URL final):

App e ops não mantêm mais a lógica de bifurcação. O que você pré-visualiza é o que os scanners recebem.

4. Depois de criar

Ao salvar, o link aparece em Links & QR codes com miniatura de QR; título, URL curta e destino padrão ficam óbvios de relance.

O que um scan faz:

• iPhone (incl. WeChat in-app) → App Store (regra)
• Android / navegadores desktop → web baifo.life (padrão)
• Analytics → cada scan é registrado automaticamente

Opcional: CLI / API

Se o time preferir terminal ou automação:

npx @dyqr/cli login
dyqr link create "https://baifo.life/" --title "Baifo App download"
dyqr qr <alias> --format svg -o poster-qr.svg

Anexar a regra de OS (token Bearer: painel → Account → Connected apps):

curl -X PATCH https://app.dyqr.me/api/links/<alias> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetUrl": "https://baifo.life/",
    "routingRules": [{
      "id": "ios_app_store",
      "enabled": true,
      "targetUrl": "https://apps.apple.com/cn/app/id6782394476",
      "conditions": [{ "type": "os", "os": ["ios"] }]
    }]
  }'

O que esta integração real ensinou ao produto

Necessidades reais de clientes costumam acertar em cheio nossos pontos fracos. Esta integração nos forçou a fechar várias lacunas com rapidez — e também a revalidar o caminho inteiro:

• Nova condição os: { type: 'os', os: ['ios'|'android'|'windows'|'macos'|'linux'] } de ponta a ponta — tipos compartilhados, resolvers de gateway + admin, permissões de plano, UI de regras, schema do assistente de IA. A ordem do UA importa: UAs de iOS contêm like Mac OS X (iOS antes de macOS); UAs de Android contêm Linux (Android antes de Linux).
• npx @dyqr/cli não instalava: deps publicadas apontavam para versão workspace não publicada → 404 no primeiro login.
• Docs e MCP desalinhados: o skill do agent dizia que o roteamento era «só no painel» quando a API já suportava — o MCP simplesmente não expunha o campo.

Os três problemas apareceram num caminho real de cliente, foram corrigidos e revalidados no mesmo caminho.

Para quem é

Se você também precisa de um QR «um scan, vários destinos» — download de app, landings por canal, conteúdo por região ou dispositivo — não precisa reconstruir uma pilha UA / GEO no backend. Deixe essa camada para os links curtos do DYQR + Smart Routing: mude regras no painel ou via API / CLI / MCP; o QR impresso nunca precisa mudar.