Te dijeron que un WebView es «gratis» y «siempre está ahí». Así que construiste tu checkout, tu registro, tu catálogo sobre él: pantallas que se cargan como documentos desde tu servidor, que a su vez dependen de un SDK de mapas, un servicio de enlaces profundos, un SDK de pagos, un proveedor de analítica. Cada uno es infraestructura de otro, y la decisión de precio, disponibilidad y política es de otro. El patrón es anterior a lo móvil: cuando una plataforma controla una capacidad de la que dependes, tarde o temprano reprograma precios, restringe o retira. La única pregunta es cuándo.

El guion del rug pull es la norma, no la excepción

En 2018, Google reescribió la pricing de Maps API de un día para otro; apps de entrega y logística que habían construido toda su pila de geolocalización sobre ella despertaron con facturas un 1,400% más altas, con algunas empresas de viajes pasando de unos $30,000 a $450,000 al mes. En 2016, Facebook anunció que Parse cerraría en un año, forzando la migración de 600,000+ apps — muchas no se recuperaron. En 2023, X (Twitter) terminó el acceso gratuito a la API y todo un ecosistema de empresas construidas sobre ella tuvo que pivoter o morir. En agosto de 2025, Firebase Dynamic Links se dio de baja; cada enlace cliqueado desde entonces devuelve 404. Ninguno de estos proveedores era pequeño. Esa es la clave: el tamaño no garantiza estabilidad, solo un radio de explosión mayor cuando cambia la estrategia.

Tu WebView multiplica la exposición

Una función nativa vive dentro de tu binario compilado y firmado — tú decides cuándo se lanza y si sigue funcionando. Una pantalla WebView es un documento que se obtiene de un servidor en cada sesión, y ese documento solo vive mientras vivan todas las dependencias detrás. Si el SDK de mapas reprograma precios, el servicio de enlaces desaparece o el proveedor de analítica cambia su API, la pantalla que ve el usuario puede romperse o degradarse en silencio. Y quizá ni sepas cuál «gratis» falló, porque la falla aparece como un mosaico en blanco o un botón muerto, no como una alerta roja.

La tienda es el último punto único de fallo

Incluso con tu propia pila perfecta, el canal que entrega tu app es de otro. En 2025, la aplicación de Apple de la DSA de la UE retiró 135,000+ apps en días por falta de información de comerciante; en el mismo período, las prohibiciones de cuentas bajo la cláusula 3.2(f) subieron un 300% interanual, y una app social perdió sus 200,000 usuarios acumulados de la noche a la mañana al ser retirada. No puedes apelar un cambio de política lo suficientemente rápido para salvar un trimestre.

La salida de emergencia es un runtime que controlas

Un runtime propio del host ejecuta tu mini-programa como un componente de primera parte, firmado y sandboxeado. La lógica se entrega en un paquete que tú firmas y versionas — no en un documento que sirve otro. Cuando un servicio de terceros reprograma precios o desaparece, cambias la integración dentro de tu propio componente y republicas a tu ritmo; la app sigue funcionando. No eres rehén de la hoja de ruta de un proveedor, porque los flujos que más toca el usuario son tuyos: versionados, auditables, recuperables.

El trade-off de un vistazo

DimensiónWebView + servicios de tercerosRuntime propio del host
Dónde vive la lógica centralDocumento obtenido del servidor por sesiónPaquete firmado y versionado que controlas
Exposición a reprogramación de preciosAlta — mapas, enlaces, SDK cambian de precio de un día a otroContenida — cambias la integración internamente
Exposición a cierre de servicioAlta — cierres tipo Parse o FDL rompen flujosBaja — el flujo central corre sin el servicio externo
Tiempo de recuperaciónEsperar al proveedor, migrar, reenviarMinutos — republicas tu propio componente
Riesgo de canalLa política de la tienda puede retirar la appLa app sigue corriendo; tú controlas el runtime

Fuentes