QR que lleva a App Store o Play Store: cómo se construye

El problema: un QR, tres destinos

Matt Huggins, fundador de PokerNexus, lo expone con claridad: un código QR codifica exactamente una URL, pero la acción «descarga la app» significa tres lugares distintos según quién lo escanee. La App Store para usuarios de iPhone, Google Play para Android y el sitio web para todo lo demás — escritorio, tablets sin la app, gente que simplemente quiere saber más antes de instalar.

Si imprimes un QR en la tarjeta de presentación de tu startup, ese problema aparece el día que lanzas. Y se vuelve permanente: una vez que las tarjetas están en los bolsillos de tus primeros clientes, no puedes cambiarlas. Por eso Huggins construyó un servicio de shortlinks propio en go.pokernexus.com/app que toma la decisión por el visitante en milisegundos.

Según Forbes, alrededor de 89 millones de usuarios de smartphones escanearon un código QR en 2022 solo en Estados Unidos — una práctica que se aceleró tras la pandemia y que hoy sigue creciendo como puente entre el mundo físico y las apps móviles.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

La solución: una URL propia que decide por el usuario

En lugar de poner una URL de tienda directa en el QR, Huggins imprime un dominio que controla y deja que un servidor pequeño decida a dónde enviar a cada visitante. El servicio está hecho con Hono, un framework web minimalista para TypeScript, y se reduce a una tabla de rutas y una función que lee el header User-Agent.

La lógica de enrutamiento es directa:

Si el User-Agent contiene bot, crawl, spider, slurp, preview o facebookexternalhit → sitio web
Si contiene iPhone, iPod o iPad → App Store
Si contiene Android → Google Play
En cualquier otro caso → sitio web

El detalle no obvio es el orden de las comprobaciones. Googlebot para smartphones se identifica como un teléfono móvil y su User-Agent contiene «Android» y «iPhone». Si las comprobaciones de dispositivo se ejecutaran primero, Google indexaría una URL de tienda mientras un humano de escritorio iría al sitio web. Eso es exactamente lo que Google llama cloaking y es penalizable. Por eso el chequeo de bots va primero: cada crawler termina en el mismo lugar que un visitante de escritorio.

Como Huggins señala en su post, esa asimetría es intencional: una respuesta incorrecta que lleva al sitio web sigue siendo una página funcional, mientras que una respuesta incorrecta que lleva a una tienda es un intento de instalación en un dispositivo que no puede correr la app.

Las decisiones técnicas que importan

El servicio tiene varios detalles que parecen menores hasta que los necesitas. Huggins los documenta porque le costaron iteraciones.

302 en lugar de 301. Es tentador usar un redirect permanente porque el QR es permanente, pero un 301 se cachea agresivamente en navegadores y CDNs. Si más adelante necesitas cambiar el destino — porque lanzas en una tienda nueva, porque la app cambia de nombre, porque decides cerrar — los usuarios que ya escanearon verán la respuesta vieja cacheada. Un 302 obliga a pasar por tu servidor en cada visita, que es exactamente lo que quieres cuando el QR es un punto de control que esperas reorientar.

El header Vary: User-Agent. Por defecto, un caché guarda una respuesta indexada solo por URL. /app devuelve tres destinos distintos según el dispositivo, así que sin ese header un proxy corporativo o una CDN podría servirle al próximo iPhone el redirect que le dio a un Android. Vary: User-Agent le dice al caché: esta respuesta depende también de este header, no la reutilices si no coincide.

Un dominio aparte, no un path del dominio principal. pokernexus.com/app sería una URL más corta, pero no funcionaría. El archivo apple-app-site-association de PokerNexus reclama todos los paths del dominio para Universal Links, y Android hace lo propio con verified app links en el host apex. Cualquier URL en el dominio principal sería interceptada por la app ya instalada — y un path ahí pondría el sniffing de dispositivo delante de todo el sitio web, donde un bug podría enviar a todos los visitantes a la App Store.

Huggins separó el shortlink en un servicio Hono independiente, en un subdominio (go.pokernexus.com) que ninguna plataforma reclama. Eso convierte «nunca sirvo la app en este host» de regla a memorizar en propiedad del despliegue. Y como no importa ningún paquete del workspace principal, la imagen Docker es chica y se deploya en su propio schedule.

Query strings hacia adelante o descartadas. El sitio web reenvía los parámetros UTM de la URL del QR (?utm_source=cards&utm_medium=qr) para que puedas atribuir instalaciones a la campaña. Las tiendas, en cambio, los descartan — y en el caso de Google Play es obligatorio: el ID del paquete (?id=com.pokernexus.app) vive en la query string de la URL de Play, y reenviar un parámetro de campaña lo sobrescribiría, abriendo una ficha vacía.

Paths desconocidos devuelven 404, no caen al sitio web. Un typo en una URL impresa que silenciosamente lleva al home parece que está funcionando. El momento de descubrir ese typo es mientras testeas el QR, no después de que lleguen las tarjetas impresas.

Qué significa esto para tu startup

El patrón de Huggins es un caso de estudio porque cualquier founder que lance una app móvil con presencia impresa enfrenta las mismas preguntas. Cuatro decisiones prácticas que puedes tomar hoy:

Si tu app usa Universal Links o verified app links, no pongas tu QR en el dominio principal. Usa un subdominio o dominio aparte que ninguna plataforma reclame. Tu vida va a ser mucho más simple.
Si vas a imprimir QRs en packaging, tarjetas o signage, haz que apunten a una URL que controles. No a una URL de tienda. Una URL propia te deja cambiar de tienda, hacer A/B testing, medir campañas con UTM y agregar fallbacks sin reimprimir nada.
Si decides implementar esto tú mismo, los dos errores más caros son el orden de los chequeos (bots antes que dispositivos) y el tipo de redirect (302 antes que 301). Ambos están bien documentados en el código de Huggins y son directamente aplicables a cualquier stack.
Si no quieres implementar nada, servicios como Firebase Hosting, Vercel Edge Functions o un simple Cloudflare Worker resuelven el mismo problema en menos de cien líneas. Lo que no puedes hacer es imprimir una URL de tienda directa y esperar que funcione en todos los dispositivos.

Un detalle que Huggins dejó como trade-off aceptado: Safari en iPad desde iPadOS 13 se identifica igual que Safari en Mac, así que esos visitantes caen al sitio web. La app tiene badges de App Store y Google Play en su página About, así que el fallback no es un callejón sin salida. Es la clase de compromiso que un founder debe documentar explícitamente en lugar de descubrirlo cuando un usuario se queja.