MonoTouch, programa para iOS de forma sencilla con tus conocimientos de C# y .NET

Vale es un wrapper, de todas formas yo soy partidario de usar lenguajes nativos de la plataforma. Al menos en mi caso para programar videojuegos es muy importante para asuntos de rendimiento. Conozco C#, he hecho algún videojuego para XBOX/PC, y sin duda tiene la ventaja que dices, es un lenguaje que toma lo mejor del Java y del C++. Pero ya digo, en iOS prefiero y necesito Objective C. De todas formas gracias por la aclaración.

Pero como tengas que hacer algo multiplataforma entonces estás fastidiado.

De hecho para juegos sería más recomendable hacerlo en c (o c++) y tener obj-c básicamente para el input y para inicializar opengl es / framework que uses.

C# básicamente era un Java mejorado cuando salió, pero luego tuvo su propio curso de evolución. Diez años después, es bastante más rico que Java e implementa miles de cosas que en Java ni se pensaron [expresiones lambda, LINQ, delegados, propiedades, extension methods, etc.]

Obj-C es más complejo desde el momento que tienes que gestionar la memoria, cosa que en c# y java no pasa.

Por otro lado, lo que se de MonoTouch es que también tienes acceso a CocoaTouch y a las APIs de iOS por medio de Bindings. MonoTouch es más como una capa intermedia para permitir multiplataforma, pero que funciona bastante bien al compilarse a nativo y no llevar una MV

En Objective C había que gestionar la memoria antes, ahora ya no es necesario. La tecnología ARC (Automatic Reference Counting) gestiona ahora la memoria en cada momento y elimina los objetos cuando no hay referencias al mismo sin necesidad de que sea el programador el que tenga que hacerlo. Esto ha sido un paso a mejor brutal.

Eso no es correcto. ARC simplifica, si, pero aún así tienes que saber lo que estás haciendo, ya que en realidad es el compilador el que está insertando automáticamente los comandos de retain/release si sigues los convenios.

Siempre hay que saber lo que se hace desde luego, no va a haber magia con ARC pero simplifica mucho el trabajo eso es seguro.

Objective-C no es assembler, así que no puede ser considerado un lenguaje de bajo nivel.

Creo que el concepto puede emplearse términos relativos, y decirse, por ejemplo, que '…Objective C es de más bajo nivel que MonoTouch'

Comparar de esa manera MonoTouch con Appcelerator es como comparar peras con castañas. Lee mi comentario anterior, de todas formas, puedo ser más explícito: para usar MonoTouch tienes que conocer CocoaTouch para Appcelerator, no.

Y claro que puedes usar PhoneGap o AdobeAir, pero entonces estás perdiendo calidad (rendimiento en el caso de PhoneGap) y usabilidad porque no estás siguiendo el Look&Feel de la plataforma y créeme los usuarios, aunque en ocasiones no lo aprecien, lo valoran. Al final una de las caracerísticas del mundo Apple es el cuidado del diseño, ¿no?

Si lo tienes que llenar de ifs lo más probable es que estés diseñando el programa MUY mal. Si hay cosas específicas para cada plataforma hay maneras mucho mejores de hacerlo que llenarlo todo de condicionales.

Y en HTML5 y Air vas a estar exactamente igual, que si te crees que HTML5 es  multiplataforma, perfecto y todo bonito, te vas a llevar un chasco pero bien fino. 

Air no lo he probado, pero estoy por apostar que tendrá problemas similares, por una razón muy sencilla: No existe lo que tu llamas 100% multiplataforma, y de hecho tu mismo lo dices: si hay algo que no puedo hacer escribo el código nativo. Pues exactamente igual que con MonoTouch y todas las demás.

Se que HTML5 se queda "coja" en compatibilidad y rendimiento... pero a la hora de desarrollar una App multi-plataforma hay una diferencia importante entre HTML5 / AIR y MonoTouch / Titanium: los componentes que utiliza HTML5 / AIR no son los nativos. Es decir, la misma App en iOS será igual a la de Android.

Este es un handicap que te puede gustar mas o menos, pero como cada SO tiene una UI distinta (componentes, contenedores, acciones...),lleva mucho mas trabajo hacer una app multi-plataforma usando esos componentes nativos.

Para una App "pequeña" MonoTouch puede ser la solución, pero según se incrementa el tamaño... se aumenta la dificultad del mantenimiento.

Cito extracto de una opinion de mono:

"... If your app is essentially pure UI, with very little backend logic, you will not be able to reuse a lot of code..."

http://www.quora.com/Mono/Has-anyone-successfully-used-MonoTouch-MonoDevelop-to-create-a-mobile-app-that-runs-on-iOS-and-Android-What-percentage-of-the-codebase-can-be-shared-across-these-platforms

Insisto, para hacer una App nativa mejor escribirla en nativo, para hacerla multi-plataforma para mi AIR es la mejor opción ya que se ejecuta en una máquina virtual y te garantiza que se vea exactamente igual en iOS que en Android ¡Y a 60 FPS!

Los 60FPS será si lo usas bien y sabes lo que haces, como todo. Es que pareces repetirlo mucho, y no se por qué. Sólo faltaría que tirando de GPU no llegara a eso, sería para matarles.

Por otro lado, se te olvida comentar que para una aplicación normal, se reutiliza entre el 60% - 70% de código, a la vez que mantienes el estilo visual de cada plataforma al usar los componentes nativos. Vamos, justo lo contrario de lo que indicas.

Unity puede ser totalmente multiplataforma, y de máximo rendimiento y flexibilidad. Para juegos sin duda lo recomiendo, así como su complemento 'Vizio-Universe', que le proporciona programación gráfica, para los que, como yo, la encuentran más productiva, y con una penalización en rendimiento asumible.

Totalmente de acuerdo. Por mi parte me quedo con Unity.

Tienes razón, pero no hay que ser un experto en el tema para escribir "objetive C" en vez de Objective C. Igual, el artículo me parece bastante "fanboy"-ero, porque hace referencia a "otros lenguajes" como "tecnologías más simples" no siendo ese el caso.

De hecho la complejidad de Objective C comparada con la de C++ es bastante sencilla.

Éste no es un comentario directo hacia ti, sólo que me parece cómico que en la jerga de Objective C, al conteo de referencias se le haya puesto un nombre (ARC) y se hable de eso como una gran ventaja del nuevo Objective C.

De hecho, COM de Microsoft usa contadores de referencia y CComPtr de ATL facilita el conteo de referencias. En C++ se pueden implementar smart pointers basados en conteo de referencias desde hace mucho tiempo y el nuevo estándar implementa std::shared_ptr y std::weak_ptr para el manejo de contadores de referencia también. RAII es un idiom de C++ bastante útil para manejar memoria y recursos y hace que nuestras aplicaciones sean exception-safe. Como ven, montón de tecnologías implementan conteo de referencias y no hacen pompa de eso.

Nadie hace pompa de nada. Nos alegramos de que exista ARC, nada más. Está claro que otros lenguajes han implementado soluciones similares antes pero más vale tarde que nunca.

Pues yo prefiero manejar la memoria, a que lo haga el compilador por mi.

Los que se vanaglorian de que C# lo haga automaticamente, pues hombre, así pasa, que luego los programas ocupan RAM innecesaria, hasta que el recolector de basura hace su trabajo.

Saludos.

Siempre que no sea un leak, usar momentáneamente una cantidad de memoria no óptima es más que aceptable en la gran mayoría de las situaciones, comparado con la facilidad de desarrollo que aporta.

Si el uso de memoria es un problema, también se pueden usar técnicas para paliarlo, aunque no tengas control total sobre cómo se gestiona la memoria.

Pues puedes ... solo tienes que desactivar ARC y punto.

Esta es una pregunta:

Todos sabemos que el problema principal del manajo de memoria usando contadores de referencia es que es imposible usarlos cuando tenemos referencias cíclicas (si A tiene un puntero a B, B a C y C a A, digamos); en C++ eso se resuelve mediante el uso de weak pointers, que son punteros que usan contadores de referencia, pero que no incrementan el contador de referencia ni evitan que un objeto se destruya cuando su contador de referencia ha llegado a 0 (así, A apunta a B, B apunta a C y C apunta "débilmente" a A resolvería el problema de las referencias cíciicas).

¿Cómo se maneja esto en Objective-C usando contadores de referencia?

Los weak pointers (supongo que weak_ptr) no son más que la implementación del concepto de weak reference. http://en.wikipedia.org/wiki/Weak_reference#Objective-C_2.0 En obj-c si no actualizas manualmente el contador ya tendrías un weak pointer. Sin embargo, hay una keyword específica para weak pointers en propiedades, ya que ese código se genera automáticamente: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW2

A ver, no es exactamente lo mismo. Contador de referencia había desde siempre en Obj-C para iphone, y usaban los mensajes retain y release, y es lo que se usaba hasta ios4.

El ARC es nuevo en el aspecto que si sigues ciertas convenciones o usos, el compilador es capaz de inferir automáticamente cuando debe usar esos retain y release, y los inserta automáticamente en el código compilado, por lo que tu no tienes que hacerlo en el código fuente. Vamos que te ahorra ligeramente gestionar manualmente la memoria, de ahí la ventaja.

Y sobre todo, ARC es *opcional* Por defecto se usa al crear un proyecto nuevo pero se puede ignorar y gestionar tu mismo la memoria.

"Desarrollo en iOS? nativo, Objetive C y XCode por favor."

mientras parezca nativa y se comporte como nativa; pues sirve. He leído sobre aplicaciones exitosas en la Mac App Store que están escritas en Java Swing y C++ Qt; así que, creo que si del lado del usuario la aplicación funciona bien, el programador debe pensar también en su comodidad y en la tecnología que mejor maneja.