Apps de logística con React Native: lecciones de cinco proyectos

He desarrollado apps móviles para cinco clientes del sector logístico. Cuatro de ellas están orientadas al cliente: para Buzmavi, Mitlog, CDA Lojistik y Almark Global Lojistik, apps que facilitan a los clientes de estas empresas el seguimiento logístico y la comunicación. La quinta es interna: una app de operaciones que controla con código de barras las entradas y salidas de carga en el almacén de TCT Lojistik. Soy Berke Özyaşar, y en este artículo he reunido las lecciones prácticas que saqué de estos proyectos. Si estás pensando en una app móvil para tu empresa de logística, aquí tienes buena parte de lo que conviene saber antes de empezar.

Primero, la pregunta: ¿para quién es la app?

En logística, al hablar de «app móvil» pueden venir a la mente dos productos muy distintos. El primero es la app orientada al cliente: tu cliente exportador o importador ve desde el móvil dónde está su carga, en qué fase se encuentra y con quién tiene que hablar. El segundo es la app de operaciones: el personal del almacén, el conductor o el personal de campo hace su trabajo desde el móvil. Incluso dentro de la misma empresa, deben ser apps separadas; sus usuarios, pantallas, necesidades de seguridad y criterios de éxito son completamente diferentes.

En la app de cliente, el objetivo es reducir las llamadas de «¿dónde está mi carga?» que recibe el equipo de operaciones y ofrecer al cliente un canal profesional. En la app de operaciones, el objetivo es la rapidez y la ausencia de errores: si escanear un bulto lleva más de lo necesario, el equipo deja de usar la app y vuelve al papel.

Por qué React Native

Desarrollé todos estos proyectos con React Native. Los clientes de las empresas de logística usan tanto iPhone como Android; escribir dos apps nativas por separado duplica el coste de desarrollo y de mantenimiento. Con React Native, desde una única base de código sale la app para las dos plataformas, y cuando se añade una función, se publica en ambas a la vez. Hay librerías maduras para funciones del dispositivo como la cámara, las notificaciones push, los mapas y la comunicación con impresoras; y, si hace falta, también se pueden escribir módulos nativos.

La elección de plataforma no fue la misma en todos los proyectos. Buzmavi y Mitlog están publicadas tanto en App Store como en Google Play; las apps de CDA y Almark, en Google Play. La app de almacén, por su parte, se preparó para los dispositivos Android que se usan en el almacén. Cuando la base de código se escribe desde el principio pensando en las dos plataformas, añadir más adelante una versión para iOS no es un proyecto nuevo, sino un trabajo mucho más pequeño.

Lo que debe tener una app de cliente

La primera versión de una app de logística orientada al cliente no necesita una larga lista de funciones. Cuando los puntos siguientes están bien hechos, la app se usa:

• Lista y detalle de envíos: Las cargas activas del cliente, el estado actual de cada una y su historial de movimientos. Los nombres de los estados deben escribirse en un lenguaje que entienda el cliente, no con la jerga interna del equipo de operaciones.
• Notificaciones: La notificación push que llega cuando cambia el estado es donde la app aporta más valor. Pero enviar una notificación por cada pequeño cambio acaba con el usuario desactivándolas; hay que elegir junto con el equipo de operaciones qué eventos merecen una notificación.
• Comunicación: Llamada, correo o mensaje al representante correspondiente con un solo toque. Cuando el cliente tiene un problema, no debería tener que buscar con quién hablar.
• Documentos: Si el sistema de la empresa los guarda en formato digital, acceso a documentos como el conocimiento de embarque, las facturas y la documentación aduanera.
• Inicio de sesión seguro: Cada cliente debe ver solo sus propias cargas. Los permisos deben gestionarse en el servidor; no hay que fiarse de la propia app.

La parte más difícil: conectar con el sistema existente

Casi todas las empresas de logística tienen un software de operaciones o una base de datos que llevan años usando. El valor de la app móvil depende de que muestre los datos de ese sistema de forma correcta y actualizada. Por eso, la fase más crítica del proyecto muchas veces no es la interfaz, sino la integración.

En el proyecto de TCT, la app se conectó a la infraestructura ASP.NET Core y SQL Server que ya tenía la empresa; se construyó sobre el sistema existente en lugar de sustituirlo. Ese es también mi enfoque general: la app móvil no debe conectarse directamente a la base de datos, sino a una capa de API que hace la autenticación y devuelve solo los datos necesarios. Así, aunque cambie la estructura de la base de datos, la app móvil no se ve afectada y la seguridad se gestiona desde un único punto.

Los puntos a los que presto atención en la integración:

• Validar uno por uno con el equipo de operaciones el significado de los códigos de estado y de los campos. El nombre de un campo en la base de datos no siempre coincide con aquello para lo que se usa en realidad.
• Tiempos de espera, reintentos y mensajes de error comprensibles para que la app no se congele en redes lentas o inestables.
• Paginación en las listas largas; no traer al móvil de una sola vez los datos acumulados durante años.
• Duración de la sesión y renovación del token. En la app de TCT, la autenticación se hace con JWT.

La app de operaciones es otro mundo

La app de almacén de TCT supuso un trabajo muy distinto al de las apps de cliente. Aquí el usuario es el personal del almacén; en la entrada y la salida de carga, la app lee con la cámara los códigos de barras de los bultos, cuando el código no se puede leer lee con OCR el texto de la etiqueta, se selecciona la matrícula del vehículo y las etiquetas se imprimen en impresoras Zebra a través de la red. En una app así, el criterio de éxito no es el aspecto de las pantallas, sino que alguien con guantes, con mala luz, pueda trabajar rápido y sin errores. Por eso son importantes las zonas táctiles grandes, una respuesta clara y los flujos con el mínimo de pasos. Explico los detalles técnicos de este proyecto en el artículo sobre la app de almacén con código de barras.

El proceso en las tiendas: planifica la cuenta desde el principio

En los proyectos para clientes, hay que dejar claro desde el principio a nombre de quién se publicará la app. Buzmavi y Mitlog están publicadas en App Store con las cuentas de desarrollador de las propias empresas; la app aparece en la tienda con el nombre de la empresa y la cuenta se queda en la empresa. Para ello hace falta una cuenta de Apple Developer de organización, y por pasos como el número D-U-N-S este proceso puede alargarse más de lo esperado. Iniciar la solicitud de la cuenta al empezar el desarrollo es la forma más sencilla de no retrasar la fecha de lanzamiento.

En la revisión de las tiendas hay algunos aspectos propios de las apps de logística:

• Cuenta demo: Si la app se abre con inicio de sesión, hay que dar al equipo de revisión una cuenta de prueba con datos de ejemplo. Prepararla sin mostrar datos reales de clientes es un trabajo en sí mismo.
• Eliminación de la cuenta: Si en la app se puede crear una cuenta, hay que ofrecer al usuario una forma de eliminarla.
• Explicación de los permisos: Hay que explicar con claridad por qué se piden permisos como la ubicación, las notificaciones y la cámara; no se deben pedir permisos que no se usan.
• Las apps que solo envuelven una web pueden tener problemas en la revisión. La app tiene que ofrecer una experiencia móvil real, con notificaciones y pantallas nativas.

Después del lanzamiento

Una app móvil no se termina el día en que se publica. iOS y Android lanzan nuevas versiones cada año, Google Play actualiza con regularidad sus requisitos de SDK de destino y el propio React Native evoluciona rápido. Una app sin mantenimiento planificado puede volverse imposible de actualizar en uno o dos años. Por eso recomiendo seguir publicando actualizaciones de versión con regularidad después del lanzamiento; es necesario tanto por seguridad como para cumplir con las tiendas.

En resumen

Una buena app móvil para una empresa de logística empieza con pocas pantallas, pero las adecuadas: estado del envío, notificaciones útiles y comunicación fácil. La verdadera dificultad está en conectar con el sistema existente mediante una API sólida y en planificar desde el principio el proceso en las tiendas. Si estás pensando en una app similar para tu empresa, en la página de desarrollo de apps móviles puedes ver cómo trabajo y contactarme desde allí.