En términos generales, existen dos partes para tener un código multiplataforma portátil (es decir, “con solo una pequeña fijación”) en objetivos modernos:
- un lenguaje de programación portátil
- un ambiente común
Para el lenguaje de programación portátil, la mayoría de los lenguajes semi-modernos pueden funcionar. Para lenguajes de programación de sistemas como C y C ++, querrá tener cuidado con algunos aspectos del lenguaje (por ejemplo, no asuma el rango de tipo long ), pero no es un problema difícil. Dicho esto, algunos idiomas son “menos compatibles” en algunas plataformas que en otras. Por ejemplo, C # está disponible en iOS y Android, pero las comunidades asociadas son mucho más pequeñas que en Windows (y, creo, más pequeñas que, por ejemplo, la comunidad C ++). Por el contrario, Swift está disponible en Windows, pero todavía solo tiene una comunidad naciente allí.
La parte del entorno común es a menudo más difícil de decidir. En el caso de las plataformas orientadas al usuario (que presumiblemente es lo que le importa, ya que incluye iOS y Android entre sus objetivos deseados), algunas tiendas optan por escribir aplicaciones web en su lugar: la pila HTML5 + CSS + JavaScript es bastante portátil y todo Las plataformas modernas proporcionan esa pila “fuera de la caja”. La mayoría de los sistemas operativos cliente modernos incluso ofrecen formas de disfrazar las aplicaciones web resultantes como aplicaciones comunes (básicamente integrando el navegador y la aplicación). Sin embargo, el rendimiento es limitado, al igual que el acceso a los recursos de hardware.
Para C ++, el entorno portátil más popular del lado del cliente es probablemente Qt (pronunciado “lindo”; consulte El futuro está escrito con Qt: desarrollo de software multiplataforma para incrustado y de escritorio). Ha existido durante mucho tiempo y tiene una comunidad amplia.
C # tiene algo similar en Xamarin: desarrollo de aplicaciones móviles y software de creación de aplicaciones. No tengo mucha experiencia con él, pero algunas buenas aplicaciones de iOS que uso se desarrollaron de esa manera. Tengo entendido que su capacidad de acceder a servicios nativos en plataformas que no son de Windows es más limitada.
El primer reclamo de Java fue “escribir una vez, ejecutar en cualquier lugar”, y eso sigue siendo una fuerza motivadora para usar Java. Sin embargo, mi experiencia limitada es que no es terriblemente agradable en los sistemas operativos Apple, principalmente debido a estrategias de administración de memoria divergentes (MacOS e iOS; no estoy seguro de su alcance para watchOS y tvOS).
Dicho todo esto, para obtener la mejor experiencia en cada plataforma, una aplicación se beneficia del uso de expresiones idiomáticas de la interfaz de usuario local, y eso no se puede hacer realmente “con solo un poco de corrección”.
