El costo de compartir código entre iOS y Android

Dropbox usó C++ al comenzar en 2013 para compartir código entre ambas plataformas.

En ese momento el equipo era pequeño, y era para respaldar una hoja de ruta móvil que crecía rápidamente.

Actualmente cambiaron a usar Swift y Kotlin, y esto se debe a los siguientes costos ocultos de compartir código (de hecho, no están tan ocultos)

• sobrecarga por frameworks y bibliotecas personalizadas

• sobrecarga por un entorno de desarrollo personalizado

• sobrecarga por manejar las diferencias entre plataformas

• sobrecarga de capacitar, contratar y retener desarrolladores

En conclusión, escribir una sola base de código suena bien, pero la sobrecarga es grande.

Es importante que el último párrafo de este artículo sea "¡Estamos contratando desarrolladores de Android / iOS!"

[godrm]

¿No será cuestión de si es una sobrecarga que la organización puede asumir o no?

Si se puede asumir cualquier opción, creo que lo correcto es enfocarse en aquello que mejor saben hacer.

Al final, parece que las diferencias entre plataformas son inevitables. Incluso si se hace híbrido, esas diferencias no desaparecen.

[iolothebard]

Cross-platform no es más que otra plataforma.

Y además, más compleja y torpe..

[ohjongin]

Últimamente React Native ha alcanzado un nivel de madurez bastante alto..

Claro, si se trata de una app dependiente del dispositivo como Dropbox, el sufrimiento de las apps híbridas tradicionales probablemente siga igual..

[xguru]

El texto es largo, pero en realidad Dropbox es un caso particular porque usa C++,

y la verdad es que para organizaciones pequeñas resulta tentador al principio dar soporte multiplataforma con una sola base de código.

Hace 10 años eso pasaba con el desarrollo híbrido usando HTML5 y Phonegap,

y hoy en día aparecen cosas como React Native y Flutter, tentando a todos con la idea de que es posible dar soporte a varias plataformas de una sola vez.

En mi opinión, para organizaciones pequeñas compartir código de esa manera sí tiene ventajas claras.

Pero a medida que el producto crece, eso vuelve a convertirse en deuda técnica.

Cuando aumentan los usuarios, crece la organización y se suman más desarrolladores, creo que el resultado final es que Web/iOS/Android terminan evolucionando cada uno con la tecnología adecuada para su caso.

Como en el buen artículo sobre deuda técnica que está en https://es.news.hada.io/topic?id=309

lo importante es crear deuda técnica con intención. Paguemos la deuda antes de que los intereses se disparen.