Yo diría que es posible, pero no útil.
Los dos beneficios realmente importantes para XCode son:
- Desde el ecosistema de Apple, puede desarrollar aplicaciones para iPhone / iPad / iPod Touch
- Puede desarrollar aplicaciones nativas de plataforma para computadoras portátiles y de escritorio Mac OS X
Para el primero, Apple tiene prácticamente cero beneficios al desarrollar la capacidad de desarrollar aplicaciones para dispositivos móviles en plataformas que no sean Mac OS X:
- ¿Cómo se mejora en el desarrollo de iOS?
- ¿Existe una aplicación móvil para la edición comunitaria de Sugar Crm?
- ¿Cuánto tiempo llevó desarrollar Periscope?
- ¿Cuáles son los pros y los contras de construir con Adobe Flex, en comparación con el desarrollo nativo de iOS o Android?
- ¿Qué tan útil es el plegado de código en varios IDE?
- No vende más computadoras portátiles o de escritorio Mac OS X
- No aumentará sustancialmente la cantidad de aplicaciones de calidad disponibles para dispositivos móviles
- Es un dolor de cabeza de apoyo continuo
- No es como si pudiera usarlo para desarrollar aplicaciones nativas para plataformas Microsoft o Linux: seamos generosos e incluyamos teléfonos y tabletas Windows, y teléfonos y tabletas Linux (Android) en este paquete
Hay otras razones, pero estas son las cuatro principales.
Obviamente, escribir software para una plataforma distinta de las plataformas de Apple no va a contribuir a las ventas de las plataformas de Apple. Pero, ¿qué pasa con los dispositivos para los que utilizaría estas herramientas?
Resulta que si está desarrollando para dispositivos móviles, a menos que sea una pequeña aplicación de mercado vertical, o a menos que tenga los recursos de un Rovio, que puede apuntar a todas las plataformas a la vez, estará desarrollando para el iPhone. Puede o no desarrollar para Android; pero definitivamente estás desarrollando para el iPhone.
Entonces, ¿tener el SDK y las herramientas disponibles en plataformas que no sean de Apple aumentará la cantidad de aplicaciones de calidad para los dispositivos móviles de Apple?
No. Generalmente no. Porque si eres tan adicto a una plataforma Windows o Linux como tu entorno de programación, no vas a utilizar los paradigmas, derivados de Mac OS X, que crean las mejores aplicaciones en dispositivos Apple Mobile.
Piensa mal en el desarrollo de aplicaciones.
Y por qué puede pensar en la gestión de componentes de la manera correcta … Apple no lo hace, por lo que, a menos que lo piense de la manera de Apple, también se encontrará con problemas.
Linux es una plataforma enormemente móvil. Es casi imposible, a menos que elija una única distribución comercial (Android no es una versión única) y apunte a eso, es prácticamente todas las apuestas están apagadas.
Y si lo hace … podrá alcanzar, en el mejor de los casos, entre el 12 y el 16% del mercado con su producto.
Windows es igualmente un objetivo móvil, y tienen un IDE ( Entorno de desarrollo interactivo ) competitivo, y para empeorar las cosas: en muchos sentidos, es funcionalmente mucho mejor que XCode.
Por lo tanto, siempre tendrá al menos un lanzamiento del sistema operativo en cualquier plataforma a la que transfiera sus herramientas de desarrollo y que no esté bajo su control directo.
Hay una buena razón por la que las herramientas de desarrollo suministradas por el proveedor han superado y superado a todas las herramientas de terceros: no es que las herramientas de terceros no sean tan buenas, o en algunos casos, mejores, que las herramientas del proveedor. Es que casi nunca son actuales .
Mantenerlos actualizados es perseguir un objetivo móvil, y perseguir un objetivo móvil en software significa comprometer una cantidad absurda de recursos para el proyecto.
Lo que nos lleva a nuestro punto final …
La razón principal por la que no será útil para la aplicación nativa en las plataformas de Microsoft y Linux es que la infraestructura subyacente, los marcos, los encabezados y el código de pegamento, simplemente no están allí.
De hecho, esto es casi imposible en Linux, que no tiene un único conjunto de bibliotecas dominantes del mercado para escribir. E incluso si lo hicieran: no funcionarán como las bibliotecas de Apple funcionan en Mac OS X, por lo que no es que los componentes simplemente se transfieran con una nueva compilación.
Apple ni siquiera piensa en el almacenamiento de datos de la misma manera, y mucho menos en el acceso a bibliotecas y componentes compartidos que podrían no haber estado allí cuando se escribió su código.
Para decirlo en términos simples: Apple piensa en términos de usted hablando con uno de sus programas para acceder y manipular los datos utilizados por ese programa; Microsoft y Linux piensan en términos de bibliotecas compartidas, y salen y manipulan los datos usted mismo usando una biblioteca que conoce el formato de almacenamiento.
La forma en que las plataformas piensan sobre la resolución de problemas es demasiado ajena a los paradigmas principales de los demás para poder lograrla de manera útil, a menos que tenga un gran presupuesto para hacerlo.
