Reseña del dominio .app: HSTS, móvil y el TLD por defecto en HTTPS

.app se lanzó en 2018 con una característica estructural que ningún otro TLD importante tenía: cada dominio .app ha estado precargado en HSTS desde el día uno, lo que significa que los navegadores se rehúsan a cargar cualquiera de ellos por HTTP plano. Google, que opera el registro, lo enmarcó como un TLD "seguro por defecto". Ocho años después, esa decisión resulta ser lo más interesante de él — y la razón por la que .app se ha tallado un nicho sostenible donde muchos gTLDs de la misma ola de lanzamiento no lo lograron.

Resumen

.app es la elección correcta para apps móviles y web orientadas al consumidor donde el comprador conoce la palabra "app". Es una peor elección para B2B SaaS, infraestructura, o cualquier cosa que le hable a ingenieros. Los precios son razonables, el registro es profesional, y el tema de HSTS es una característica real (aunque invisible).

Por qué importó la precarga de HSTS

La mayoría de los TLDs piden a cada dominio inscribirse en HSTS individualmente. .app los inscribió a todos a nivel de registro. Los efectos prácticos:

Sin tropiezos por contenido mixto. No puedes accidentalmente servir un sitio .app por HTTP. Los navegadores no dejan pasar a los usuarios.
Sin phishing por HTTPS mal configurado. Un sitio .app que no tiene certificado válido simplemente no carga. Los phishers no pueden malconfigurar a la ligera.
Una pequeña pero real señal de confianza en audiencias conscientes de seguridad. Los ingenieros y la gente de seguridad sabe sobre el HSTS preloading; los consumidores no, pero el efecto de segundo orden (ningún .app jamás carga inseguramente) es algo que experimentan sin nombrarlo.

Ocho años después, está claro que el HSTS a nivel de registro no fue un eslogan de marketing — ha sido una característica defensiva real.

Dónde funciona realmente .app

Apps móviles de consumo con un sitio de marketing. Cuando la audiencia ya sabe lo que es una "app" y quieres un dominio que solo diga "esta es la casa de la app", .app se lee exactamente como eso.
Apps multiplataforma. Cuando el mismo producto es iOS + Android + web, .app es la forma más limpia de decir "esta es la página de aterrizaje agnóstica de plataforma". También es corto.
Apps web independientes que no son SaaS B2B. Side projects, herramientas para aficionados, cosas de indie makers — .app es el peso correcto.
PWAs y productos mobile-first. Cualquier cosa construida mobile-first tiene un encaje natural aquí.

Dónde .app rinde menos

SaaS B2B. Los compradores de B2B no piensan en el producto como una "app". Piensan en él como una plataforma, una herramienta, un sistema, un workflow. .app se lee como consumidor para compradores empresariales.
Infraestructura y herramientas de desarrollo. Los ingenieros van por .io o .dev por defecto para esto. .app se lee como la capa de producto sobre infraestructura, no como la infraestructura misma.
Productos de IA. .ai se ha comido este segmento. No hay razón para pelear contra eso con un .app a menos que el producto sea genuinamente consumer-mobile-first.
Nombres premium de una palabra. El mercado de .app de diccionario es real pero está caro; para muchos de estos, el .com equivalente (donde sea alcanzable) sigue haciendo más por la marca.

Patrones de precios que vemos

.app se ha asentado en precios sorprendentemente razonables para un TLD alternativo con audiencia real:

Una palabra de diccionario en .app: $10K–$80K para palabras generales, más para palabras que definen categoría ("draw", "note", "track"). Estable durante ~3 años.
Dos palabras brandables en .app: $500–$5K. El mercado amplio. La calidad de la segunda palabra importa más que el TLD.
Tres letras en .app: $2K–$15K, con LLLs pronunciables comandando la prima.

Los precios de renovación están alineados con otros gTLDs modernos ($15–$25/año al retail), sin señales del tipo de shock impulsado por el registro que tuvo .io en 2024.

Cómo lee la audiencia el .app

Hay una división distinta de percepción entre lectores técnicos y no técnicos:

Lectores no técnicos interpretan .app como "la app" — una versión corta de "aplicación". Esta es la lectura que quieres: es simple, es precisa, ya está en su vocabulario.
Lectores técnicos interpretan .app como "este es un TLD de Google con HSTS". Esto no es malo, pero es una lectura ligeramente más cargada que el caso no técnico.

La asimetría es por qué .app funciona bien para productos de consumo y menos bien para productos técnicos. La última audiencia tiene más contexto que proyectar sobre el TLD; la primera solo lo lee literalmente y sigue.

Cómo puntuamos los nombres .app

Seis dimensiones, con dos notas específicas para .app:

Los nombres de estilo app móvil puntúan más alto que los abstractos. .app premia nombres que suenan como apps que descargarías — verbos, palabras de acción, nombres cortos de producto. Los nombres abstractos o corporativos rinden menos en el mismo TLD.
HSTS no aparece en el puntaje, pero aparece en due diligence. Los compradores ocasionalmente preguntan si el HSTS preloading afecta entregabilidad de email, automatización de renovación de certificados, etc. La respuesta honesta es: en 2026, esto está resuelto en todos lados; asume que es un no-problema.

¿Deberías comprar un .app hoy?

Para un producto móvil de consumo donde el .com no está al alcance: sí, especialmente si el nombre se lee naturalmente como un sustantivo refiriéndose a la app misma.

Para SaaS B2B o herramientas de desarrollador: probablemente no. .com, .io, o .ai harán más trabajo dependiendo de tu categoría.

Si tienes un .app y quieres saber a cuánto se vendería realmente, envíalo para tasación. Miramos la palabra de segundo nivel, la lectura de la audiencia y los datos comparativos de nombres similares — igual que haríamos para cualquier reseña de TLD.