Crear aplicaciones móviles multiplataforma sin arrepentirte
Cuándo una sola base de código en React Native es lo correcto, cuándo es una pelea con la plataforma y el trabajo de publicación con el que nadie cuenta.
No hay respuesta por defecto
«Multiplataforma o nativo» se discute normalmente como una cuestión de gusto. No lo es. Es una pregunta sobre la lista de funcionalidades, y equivocarse cuesta meses.
He publicado de las dos formas. Android en Kotlin con detección de documentos con OpenCV y un módulo compartido de Kotlin Multiplatform en Crossinx. Tres aplicaciones de GlavUpDK en las que la suite Avto es React Native con Expo sobre un backend FastAPI, mientras que el cliente OTRS es nativo a propósito. Y una aplicación iOS mía que habla con un anillo inteligente por Bluetooth Low Energy.
Elige multiplataforma cuando la aplicación es sobre todo formularios y listas
Si las pantallas son listas, formularios, una vista de detalle y una llamada a la API, una sola base de código en React Native es la elección honesta. Pagas una vez la navegación, el flujo de autenticación y la canalización de compilación, y obtienes las dos tiendas.
La suite Avto encaja en esa descripción: órdenes de servicio, registros de vehículos, un login y un backend que ya existe. Expo se encargó de la compilación, las actualizaciones y las lanes de publicación en las tiendas, y nada de eso necesitaba la plataforma.
Elige nativo cuando la funcionalidad es la plataforma
La señal que decide es si tu funcionalidad principal es una capacidad de la plataforma o una pantalla. Bluetooth, canalizaciones de cámara, ejecución en segundo plano, fusión de sensores, almacenamiento local cifrado. Si una de esas cosas es el producto, la capa multiplataforma se convierte en una capa de traducción entre tú y el hardware, y te pasas el proyecto peleando con ella.
La aplicación del anillo es el caso obvio: leer un protocolo binario específico del dispositivo por BLE, gestionar reconexiones y dormir entre sondeos. Nada de eso pertenece a un puente de JavaScript.
El modo sin conexión también importa. La aplicación Gosti funciona en eventos de protocolo diplomático donde puede que no haya red. El almacenamiento local cifrado, una barrera biométrica antes de exportar y el bloqueo de capturas de pantalla no son funcionalidades que pudiera sacar de un plugin multiplataforma y fiarme de ellas.
Cómo es compartir de verdad
Kotlin Multiplatform fue el mejor punto intermedio que he usado: el modelo de dominio, la validación y las reglas de negocio viven una sola vez, compiladas de forma nativa para Android e iOS, mientras cada plataforma conserva su propia interfaz. Compartes lógica, no pantallas. Eso mantiene compartido lo que merece la pena compartir sin arrastrar la interfaz a un compromiso.
Presupuesta la canalización de publicación, no solo el código
La compilación y la tienda son donde de verdad se retrasan los proyectos móviles. Claves de firma, códigos de versión, granjas de dispositivos de prueba, capturas de pantalla, rechazos de revisión por declaraciones de privacidad que faltan. Yo lo automatizo: lanes de Fastlane en iOS, EAS en Android y CI ejecutando las pruebas en dispositivos con un umbral de cobertura que bloquee, para que una compilación en rojo no pueda convertirse en una publicación.
Ese trabajo es invisible en una demo y es la diferencia entre publicar cada mes y publicar una vez.
La regla de decisión que uso
Escribe la lista de funcionalidades, marca cada punto que necesite la plataforma y cuenta. Cero o uno de esos, y multiplataforma gana en coste. Tres o más, y nativo gana en tiempo aunque el primer día parezca más caro.
El error es elegir la base de código por gusto y descubrir la cuestión de la plataforma en el cuarto mes, cuando la arquitectura ya está moldeada alrededor de la respuesta equivocada.