La web como núcleo, Android como superficie
Tenemos experiencia construyendo Android nativo con Kotlin, así que empezar otra aplicación desde cero sería una opción conocida. Precisamente por eso conviene separar lo técnicamente atractivo de lo que tiene sentido para este producto ahora.
PuzzleHub ya contiene una cantidad importante de trabajo en web: motores, páginas, estilos, catálogo, contenido y una arquitectura que seguimos consolidando. Reescribirlo todo antes de saber qué problemas reales nos plantea un contenedor web sería pagar el coste máximo por adelantado.
El coste real de una segunda implementación
Reescribir decenas de puzzles en Kotlin permitiría una experiencia completamente nativa, pero también duplicaría correcciones, QA y evolución. Una mejora de un generador o una regla tendría dos implementaciones que mantener mientras el producto todavía está cambiando rápido.
El coste no es solo código. También son dos sistemas visuales, dos navegaciones, dos conjuntos de estados y dos lugares donde una decisión puede quedarse desactualizada.
Tener dos clientes no debería obligarnos a tener dos productos.
Por qué no KMP, al menos todavía
Kotlin Multiplatform sigue siendo interesante, especialmente si en el futuro existe suficiente lógica de dominio que merezca compartirse entre plataformas. Pero no convierte automáticamente una plataforma web existente en código común.
Adoptarlo ahora implicaría decidir qué migrar, cómo convivir con JavaScript y qué parte de la interfaz permanece específica. Preferimos posponer esa complejidad hasta tener evidencia de que resuelve un cuello de botella real.
Capacitor como primer puente
La dirección elegida para la primera app Android es Capacitor. Permite empaquetar la experiencia web, conservar HTML, CSS y JavaScript como base y acceder a capacidades nativas mediante plugins o código específico.
No es una declaración de que todo deba permanecer web para siempre. Es una estrategia de secuencia: validar primero cuánto podemos reutilizar y mover después únicamente aquello que tenga una razón concreta para moverse.
La web tiene que merecer ser empaquetada
Esta decisión hace todavía más importantes las mejoras actuales: responsive, espacio de juego suficiente, controles táctiles, persistencia, temas, navegación y componentes compartidos. Capacitor no arregla una mala experiencia; solo la coloca dentro de una aplicación.
Eso nos parece una ventaja. En lugar de usar Android como excusa para empezar de nuevo, obliga a fortalecer la base que también utilizan los usuarios web.
El tacto cambia las prioridades
Una interfaz jugable con ratón no es automáticamente cómoda con el pulgar. Áreas táctiles, gestos, scroll accidental, tamaño del tablero, teclado virtual y orientación necesitan probarse como problemas de producto.
La buena noticia es que muchas de esas mejoras benefician también a la web móvil. Preparar PuzzleHub para Android y mejorar PuzzleHub en teléfonos son, en gran parte, el mismo trabajo.
Qué sí puede ser nativo
Capacitor deja una frontera útil para notificaciones, almacenamiento, compartir, vibración, comportamiento de la barra de estado, integración con el sistema o futuras compras. Podemos añadir esas capacidades sin trasladar todos los motores.
- necesita una API del dispositivo que la web no cubre bien;
- mejora claramente la experiencia Android;
- su coste de mantenimiento está justificado;
- puede aislarse detrás de una interfaz estable;
- no obliga a duplicar innecesariamente la lógica del juego.
Offline y persistencia importan más en una app
Una aplicación instalada crea expectativas diferentes. Abrir rápido, conservar la partida y funcionar de forma razonable sin conexión son comportamientos que tendremos que revisar explícitamente.
Esto no invalida la estrategia web; señala las áreas donde el empaquetado debe ir acompañado de trabajo de producto y almacenamiento.
Una arquitectura que conserva opciones
Lo que más nos gusta de esta decisión es que no cierra el futuro. Si un juego concreto demuestra necesitar rendimiento o interacción nativa, podremos evaluarlo con datos. Si más adelante la plataforma justifica código compartido más ambicioso, podremos plantearlo desde una base estable.
La reversibilidad tiene valor. En una etapa donde PuzzleHub cambia cada semana, preferimos decisiones que nos permitan aprender antes de hipotecar toda la arquitectura.
Antes de Android, producto
Las tareas de empaquetado ya forman parte del roadmap, pero no queremos que una segunda plataforma se convierta en una distracción. La prioridad inmediata sigue siendo hacer coherente PuzzleHub web: mejores juegos, mejor UI, mejor catálogo y una base compartida.
Cuanto mejor sea ese núcleo, menos código específico necesitará cualquier cliente que construyamos encima. Si Capacitor funciona bien, habremos evitado una reescritura enorme. Si encontramos límites reales, sabremos exactamente qué partes merecen otra solución.
Ese conocimiento vale mucho más que elegir hoy la arquitectura más ambiciosa sobre el papel.