Todo líder de producto que ha lanzado en más de una plataforma conoce el impuesto silencioso. La misma pantalla de login, el mismo checkout, la misma página de ajustes — escritas tres veces, en tres lenguajes, por tres equipos que nunca terminan de coincidir. iOS en Swift. Android en Kotlin. Web en TypeScript. Una función se convierte en tres presupuestos de ingeniería, tres colas de bugs y tres trenes de release que se alejan.
He visto equipos quemar a su mejor gente manteniendo tres implementaciones sincronizadas en lugar de construir lo siguiente. La redundancia no es un costo único. Se acumula.
La aritmética de tres superficies
El mercado móvil no te deja elegir cobertura. Android tiene la gran mayoría del share global fuera de Norteamérica; iOS domina los segmentos de alto valor de Norteamérica y Japón; y un fallback web es la entrada para escritorio y enlaces compartibles. Las cifras de StatCounter ponen a Android por encima del 70% del uso móvil global y a iOS en los altos dieces — no puedes servir el mercado con uno solo. Así que dotas de personal a tres stacks.
El costo aparece en tres lugares. Primero, costo de build: la misma lógica re-implementada tres veces, con bugs específicos por plataforma cada vez. Segundo, mantenimiento: un defecto arreglado en iOS sigue vivo en Android y web hasta que alguien lo nota. Tercero, deriva: las tres versiones se bifurcan en comportamiento en silencio, así que tu «un producto» se siente inconsistente para usuarios que cambian de dispositivo.
Cara a cara
| Dimensión | iOS + Android + Web nativos | Runtime universal (un código) |
|---|---|---|
| Stacks de ingeniería | Tres (Swift, Kotlin, TS) | Uno |
| Costo de build | Función × 3 | Función × 1 |
| Superficie de bug | Triplicada, por plataforma | Única, compartida |
| Cadencia de release | Tres trenes, deriva | Una pipeline |
| Alcance | Debe cubrir todas las plataformas | Corre en hosts/plataformas |
| Tamaño de equipo | Tres especialistas | Un equipo multiplataforma |
Un runtime universal cambia la unidad de trabajo. Escribes el servicio una vez contra un runtime que provee identidad, pagos y componentes de UI de forma consistente en cada host y plataforma. Las diferencias nativas — cómo se ve un botón en iOS vs Android — las maneja el adaptador de plataforma del runtime, no tu re-implementación. El modelo de catálogo abierto significa que el mismo mini-programa corre dentro de muchas apps host sin que lo portes por host.
La salvedad honesta: un runtime no es esfuerzo cero. Las capacidades nativas de plataforma aún necesitan mapeo, y cambias la libertad de tres stacks a medida por la restricción de una superficie de API de runtime. Pero el intercambio convierte un costo estructural — todo por triplicado — en uno manejable. Para la mayoría de los equipos, esa es la diferencia entre lanzar y no lanzar.
Si estás dotando de personal a tres equipos para decir lo mismo de tres formas, la pregunta no es «qué herramienta cross-platform». Es «por qué estamos pagando por decirlo tres veces».
