Blog/one-qr-code-ios-app-store-case-study

Caso de estudio: cómo Baifo envía un solo QR a la App Store en iOS y a la web en el resto

Actualizado · Aug 24, 2026

Baifo es una app de oración / bendiciones en línea — y un cliente de DYQR. Recientemente lanzaron dos superficies para compartir: un póster «recomendar a amigos» y un póster del registro de oración. Ambos llevan un QR con una regla simple: si el dispositivo que escanea es un iPhone, enviarlo a la App Store para descargar la app; si es otro tipo de dispositivo (aún sin app), guiar al usuario a la versión web.

Casi todos los equipos que promocionan una app móvil se topan con esto. Lo que sigue es su historia de integración y, a la vez, un tutorial que quizá te haga falta.

¿Por qué no un fork casero de User-Agent?

Al principio pensaron en una ruta /get en baifo.life: leer el User-Agent, detectar iOS con regex y hacer 302 al destino correcto. El QR apuntaría siempre a esa URL.

Es viable — pero implica montar toda una infraestructura:

  • Reglas de enrutamiento — más adelante enlaces de store Android, destinos por región: cada cambio = código, tests y redespliegue
  • Analítica del QR — más allá del escaneo, hacen falta stats de clics, desglose por dispositivo, etc.
  • Crecimiento de canales — más campañas = más QR; reconstruir un sistema de enlaces cortos en casa es muy costoso de mantener

Así que el equipo de Baifo dejó ese trabajo en una plataforma de QR / enlaces cortos: la nuestra.

Tutorial: enrutamiento por OS con DYQR

Los pasos siguen el asistente Nuevo enlace de cinco pasos (capturas reales de app.dyqr.me). Smart Routing (incl. reglas por OS) es de pago — la cuenta free ve «Upgrade required» en el paso 2. ¿Prefieres terminal? CLI / API al final.

1. Crear un enlace corto con destino web por defecto

Panel → Nuevo enlace. Define el destino por defecto (todo escaneo que no coincida con una regla cae aquí):

  • Title: p. ej. «Descarga app Baifo»
  • Default destination: https://baifo.life/

Crear enlace: destino por defecto = web

Elige el defecto para «la mayoría de la gente» — en Baifo, la web. iOS se sobrescribe con una regla en el siguiente paso.

2. Añadir Smart Routing: OS = iOS → App Store

En el paso Smart Routing, añade una regla:

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

Smart Routing: condición OS = iOS, destino App Store

Notas:

  • Usa Operating system, no Device — Device solo distingue mobile / desktop y no separa iPhone de Android
  • Con la regla activa, iPhone (incluido el navegador in-app de WeChat) hace 302 a la App Store; el resto va a la web por defecto
  • Más adelante un store Android o stores por país = solo editar reglas, sin nuevo QR ni release de app

3. Exportar el QR e insertarlo en el póster

Último paso del asistente: previsualiza y exporta el QR. El póster solo embebe esta imagen (codifica el enlace corto, no la URL final):

Exportar QR: enlace corto fijo; el enrutamiento puede cambiar

App y ops ya no mantienen la lógica de bifurcación. Lo que previsualizas es lo que reciben los escaneos.

4. Tras crear

Al guardar, el enlace aparece en Links & QR codes con miniatura QR; título, URL corta y destino por defecto se ven de un vistazo.

Lista de enlaces tras crear

Qué hace un escaneo:

  • iPhone (incl. WeChat in-app) → App Store (regla)
  • Android / navegadores de escritorio → web baifo.life (por defecto)
  • Analytics → cada escaneo se registra automáticamente

Opcional: CLI / API

Si tu equipo prefiere terminal o automatización:

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

Adjuntar la regla OS (token Bearer: panel → 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"] }]
    }]
  }'

Lo que esta integración real enseñó al producto

Las necesidades reales de los clientes suelen dar justo en nuestras costuras. Esta integración nos obligó a cerrar varios huecos con rapidez — y también a revalidar todo el camino:

  • Nueva condición os: { type: 'os', os: ['ios'|'android'|'windows'|'macos'|'linux'] } de extremo a extremo — tipos compartidos, resolvers de gateway + admin, permisos de plan, UI de reglas, esquema del asistente de IA. El orden del UA importa: los UA de iOS contienen like Mac OS X (iOS antes que macOS); los de Android contienen Linux (Android antes que Linux).
  • npx @dyqr/cli no se instalaba: las deps publicadas apuntaban a una versión workspace no publicada → 404 en el primer login.
  • Docs y MCP desalineados: el skill del agente decía que el enrutamiento era «solo en el panel» cuando la API ya lo soportaba — MCP simplemente no exponía el campo.

Los tres problemas aparecieron en un camino real de cliente, se corrigieron y se volvieron a verificar en el mismo camino.

Para quién es

Si también necesitas un QR de «un escaneo, varias destinos» — descarga de app, landings por canal, contenido por región o dispositivo — no hace falta reconstruir una pila UA / GEO en tu backend. Deja esa capa a los enlaces cortos de DYQR + Smart Routing: cambia reglas en el panel o vía API / CLI / MCP; el QR impreso nunca tiene que cambiar.