De nativo a React Native sin romper el equipo

Contexto

Las apps eran 100% nativas, con Kotlin en Android, Swift en iOS y un equipo nativo pequeño que cargaba con casi todo. Al mismo tiempo, la empresa quería ir más rápido en mobile, experimentar con más agilidad y aprovechar a una gran cantidad de ingenieros de frontend que sabían React y no podían contribuir a las apps.

Problema

Tres cosas a la vez:

• Los tiempos de mobile no acompañaban el ritmo que pedía producto.
• Mantener Android, iOS y web por separado no escalaba.
• Los ingenieros de web querían ayudar y no tenían un camino razonable para hacerlo.

Y una cuarta, la que no sale en los documentos. El equipo nativo, que es el que más sabe de mobile, iba a escuchar “vamos a cambiar de tecnología” y, con razón, había preocupación.

Qué decidimos (y qué descartamos)

Elegimos React Native como opción por defecto para features nuevas, sin tirar el código nativo. La decisión fue por criterios, no por moda. Donde el rendimiento es crítico, se queda en nativo. Donde la velocidad de entrega y la contribución de más gente pesan más, va React Native.

Descartamos reescribir todo (caro y arriesgado), quedarnos como estábamos (no resolvía nada) y otras opciones multiplataforma que nos alejaban de la experiencia nativa o del talento que ya teníamos.

Y dejamos por escrito qué evidencia nos haría volver atrás en una decisión. Una decisión sin condiciones de revisión es un dogma.

Yo no estaba del lado cómodo del debate. Defendí con cariño lo nativo y, aun así, me tocó defender lo que el negocio y los equipos necesitaban. Ser un buen ingeniero también es saber cuándo ceder una preferencia técnica por algo más grande.

Cómo lo hicimos

1. Primero la integración, después la feature. Una primera integración de React Native en las apps existentes y una primera feature chica, para descubrir los problemas reales antes de pedirle algo a diez equipos.
2. Microfeatures. Features pequeñas y aisladas, con ownership claro, para poder mover una sin tocar el resto.
3. Una guía. Estructura de proyecto, cómo crear vistas nativas y exponerlas, cómo testear, cómo internacionalizar. Escrita para que alguien de web la pudiera seguir sin pedir permiso.
4. Herramientas compartidas. Puentes nativos, un puente de feature flags, localización por OTA y el tracker de tiempos del que hablo en otro caso. Si cada equipo reinventa esto, el modelo no se sostiene.
5. Reentrenar. Formación, sesiones de trabajo en conjunto y documentación para ingenieros web que no habían tocado mobile.
6. Comunidad. Foros, grupos de trabajo y reuniones para que el conocimiento nativo circulara en vez de quedarse en cuatro cabezas.

Resultado

Pasamos de un equipo nativo pequeño a una comunidad mobile de más de 100 contributors repartidos en unos diez equipos. Los ingenieros de web pasaron a entregar en mobile. La primera feature en producción abrió el camino para que las siguientes costaran menos.

Y el equipo nativo no se rompió porque se comunicó la decisión de forma transparente y con tiempo para discutirla. Nadie se enteró por un cambio en un tablero.

Qué haría distinto

Haría visible antes el costo oculto. Depurar JavaScript y código nativo a la vez es duro, el pipeline se complica y el tamaño de la app crece. Lo documentamos, pero lo hablé en voz baja y tendría que haberlo dicho en voz alta desde el principio.

Y le daría más espacio al equipo nativo para liderar la transición, no solo para opinar sobre ella.