Ingeniería
Estudio
Por área de la empresa
Por sector · 12
Veodar
Tecnología · Apps para iOS y Android
React Native permite escribir la app una vez y publicarla en iPhone y en Android, con pantallas hechas de los componentes propios de cada sistema. Desarrollamos apps nuevas así, y también continuamos, actualizamos o rescatamos las que ya están hechas con React Native.
Situaciones
React Native compensa cuando la app tiene que estar en los dos sistemas y no hay motivo para escribirla dos veces. La mayor parte del código es común; lo propio de cada teléfono se programa aparte, solo donde hace falta.
Un solo equipo, un solo código y una sola lista de tareas pendientes. Las dos versiones salen juntas y hacen lo mismo, cada una con los gestos y controles de su sistema.
Quedó en una versión antigua, las tiendas piden actualizarla o falla en los teléfonos nuevos. Se pone al día por pasos, sin reescribirla, y se vuelve a publicar.
Leer códigos con la cámara, imprimir por Bluetooth, cobrar con un terminal o seguir una ruta. Se programa como módulo nativo y el resto de la app lo usa como una pieza más.
Si tu web ya está hecha en React, las reglas de negocio, la validación y la conexión con tu servidor se comparten en lugar de escribirse dos veces.
Servicios
Cuatro tipos de encargo. Una app nueva suele empezar por el primero y necesitar el segundo en algún punto.
Módulo 1 · Doble salidaLa app completa desde una sola base de código: navegación, pantallas, formularios y conexión con tu servidor. Se prueba en teléfonos reales de los dos sistemas antes de cada entrega.
Ejemplos de entregables
Módulo 2 · Módulo nativoCuando la app necesita algo que solo el teléfono sabe hacer, se escribe en el lenguaje de cada sistema, Swift o Kotlin, y se ofrece al resto de la app con una sola interfaz.
Ejemplos de entregables
Módulo 3 · ConsolaActualización de versiones de React Native y de sus dependencias, paso a la arquitectura actual, corrección de cierres inesperados y de rechazos de las tiendas.
Ejemplos de entregables
Módulo 4 · Salida webLas reglas de negocio, los tipos de datos y el cliente de tu API viven en un paquete común que usan la app y la web. Un cambio de regla se hace una vez.
Ejemplos de entregables
Un ejemplo en funcionamiento
Ejemplo ilustrativo con datos ficticios. Añade una tarea, márcala como hecha o cambia de técnico: los dos teléfonos responden a la vez porque ejecutan el mismo código. Fíjate también en lo que no es igual.
El código común
Lo que comparten
Lo propio de cada sistema
Los dos teléfonos están dibujados en tu navegador: no hay ninguna app instalada ni se envía nada. Lo que enseña es el reparto real entre código común y piezas propias de cada sistema.
Integración
Una app es la parte visible de algo que ya existe: tus datos, tus usuarios y tus procesos. React Native se ocupa del teléfono; lo demás se conecta.
De dónde viene
A dónde llega
Cómo trabajamos y qué entregamos
Miramos lo que hay: el código si existe, las cuentas de las tiendas, los teléfonos del equipo y lo que la app tiene que hacer.
Escribimos las pantallas, qué es común y qué necesita módulo nativo, y qué queda fuera de la primera versión.
Una versión instalable en tus teléfonos, de los dos sistemas, con el recorrido principal funcionando contra datos reales.
La prueba quien va a usarla, en sus teléfonos y en su sitio de trabajo. Lo que falla ahí se corrige antes de publicar.
Cómo se compila, cómo se publica una versión nueva y qué revisar cuando Apple o Google cambien sus requisitos.
Preguntas
¿Falta la tuya? Escríbela a info@veodar.com y te respondemos con una pregunta concreta, no con un dossier.
En las apps de gestión, con listas, formularios, mapas y cámara, la diferencia rara vez se aprecia: las pantallas son componentes del propio sistema. Donde sí conviene código nativo es en gráficos muy exigentes o en funciones muy pegadas al aparato, y eso se decide antes de empezar.
La interfaz no, la lógica sí. Las reglas de negocio, la validación y el acceso a tu API se pueden compartir con una web en React. Las pantallas se escriben para cada medio porque un teléfono y un navegador no se usan igual.
Sí. Primero la compilamos y la revisamos: versión, dependencias sin mantenimiento y partes sin pruebas. Con eso delante te decimos qué se puede continuar tal cual y qué conviene rehacer, antes de comprometer nada.
Cada año cambian requisitos y a veces comportamientos. La app se entrega con una nota de qué comprobar en cada versión nueva, y el mantenimiento, si lo contratas, incluye esas revisiones.
Depende de cuánto de la app es común. Si casi todo son pantallas y datos, una base de código ahorra trabajo duplicado. Si la app vive de una función muy propia de un sistema, el reloj o un terminal de trabajo, por ejemplo, suele compensar hacerla nativa. Lo valoramos contigo con el caso concreto.
No es obligatorio, pero hoy es la forma recomendada de empezar un proyecto de React Native y simplifica compilar, publicar y actualizar. En una app existente sin Expo se puede seguir trabajando igual o incorporarlo por partes.
Actualizado:
Servicios relacionados
Otras tecnologías
Empezar
Con una frase de lo que debe hacer y en qué teléfonos nos basta para una primera respuesta. Si ya existe, mejor aún.
Qué ayuda a valorarlo
¿Antes de escribir? Mira cómo presupuestamos un proyecto o las soluciones por área de la empresa.
Cookies
Guardamos tu idioma y esta elección para que la web funcione. Con tu permiso medimos visitas y velocidad de forma anónima, sin cookies de seguimiento ni publicidad.
Cookies
Necesarias
Tu idioma, esta elección y la protección antispam del formulario de contacto.
Medición anónima
Páginas vistas y tiempos de carga, en conjunto, con Vercel. No usan cookies ni te siguen por otros sitios.