APPLE: xCode, iPhone OS, etc...

Yo despues de leer el contrato te doy animos porque los vas a necesitar

Yo estoy como tú, solo que en vez de para iPhone, para OSX. Tengo que entregar dentro de 24 días un proyecto de un editor de texto online vía paso de mensajes (una especie de Google Docs) para OSX, desarrollado en Cocoa con Xcode.

Estuve con Objective-C, pero no me leí toda la documentación ni harto coca. Como dices, es MUY MUY AMPLIA. Viniendo de C++ no cuesta mucho ir pillando el tema, pero es diferente (no se llama al objeto, se le envía un mensaje xDD). Ando con la documentación de Cocoa sobre creación básica de aplicaciones en Xcode con Objective-C, Interface Builder, el modelo MVC y toda la hostia puta. Voy contrarreloj pero tengo que reconocer que es maravilloso la cantidad de documentación que hay, lo bien hecho que está todo y lo exageradamente sencillo que lo han querido hacer.

Si flipé con QT, con Cocoa me estoy llevando una muy grata sorpresa también.

Sigue comentando tus experiencias, están interesantes xD

#7 Aquí tienes cómo hacerlo, pero es básicamente lo que comentabas antes, dar de alta el UDID del iPhone + instalar un provisioning profile.

Lo que te comentaba en el otro hilo de usar un framework intermedio como Appcelerator Titanium yo lo hago (más bien lo voy a hacer) por dos razones:

1) Porque no tendré que aprender Objective-C, sino que puedo programar la app al completo en Javascript + HTML5 + CSS, que ya conozco.

2) Porque el mismo código que generas se puede compilar y distribuir para otras plataformas, como Android, con cuatro cambios mínimos.

Pero también tiene inconvenientes claro, como que la API de Titanium por ejemplo no soporta aún todas las características del SDK, pero sí la mayoría de ellas.

Un framework per se no es nada malo, ni restrictivo ni emperora la calidad del software, más bien al contrario. Es una manera de facilitar la programación y establecer metologías para hacer ciertas cosas de manera más simple en vez de reinventar la rueda reescribiendo código que ya existe y ha sido testeado, lo cual a su vez trae más y más posibilidades de introducir bugs.

Ahora, en este caso en concreto, al usar Appcelerator Titanium tienes unas ventajas y unos inconvenientes, que ya te he comentado brevemente. Es cuestión de ponerlo en una balanza y sopesarlos a ver qué es lo más conveniente para tu caso en particular. A mi personalmente me parece muy ventajoso porque puedo crear una aplicación y distribuirla para iPhone y Android simultáneamente, sin tener que escribir el código en 2 lenguajes distintos. Aparte, yo ya sé Javascript con lo cual puedo comenzar a desarrollar desde ya.

Si en algún momento me encuentro con un obstáculo insalvable, como alguna funcionalidad específica del SDK que no esté soportada aún por Titanium, entonces será el momento de plantearse si merece la pena dar marcha atrás y escribir código nativo, pero es algo que en general puedes preveer durante la fase de analisis. Además Titanium en concreto es un framework muy bien construido y te permite insertar tus propios modulos escritos en el código nativo de la plataforma.

El cómo funciona Titanium, pues es bastante sencillo. Lo que hace es básicamente utilizar controles WebView nativos para meter screens construídas con HTML y CSS dentro de una aplicación nativa. Además tiene su propia API en Javascript que sirve de "puente" para acceder a funciones del dispositivo, como la cámara, el acelerómetro, sonido, vibración, etc. Y todo esto lo haces sin preocuparte de si debajo hay un iPhone OS o un Android.

Si te da por probarlo tienen una demo app llamada KitchenSink que sirve como fuente de ejemplos de código y como batería de pruebas de la API de Titanium, para que veas todo lo que es capaz de hacer, y es impresionante ver cómo el resultado es indistinguible de una app nativa, tanto gráficamente como en velocidad de reacción, suavidad, etc.