Comparación entre Corona, Phonegap, Titanium

Me registré con stackoverflow sólo con el propósito de comentar sobre la respuesta más votada en la parte superior. Lo malo es que stackoverflow no permite a los nuevos miembros publicar comentarios. Así que tengo que hacer este comentario más parecido a una respuesta.

La respuesta de Rory Blyth contiene algunos puntos válidos sobre los dos marcos móviles javascript. Sin embargo, sus puntos clave son incorrectos. La verdad es que Titanium y PhoneGap son más similares que diferentes. Ambos exponen las funciones del teléfono móvil a través de un conjunto de API javascript, y la lógica de la aplicación (html, css, javascript) se ejecuta dentro de un control WebView nativo.

1. PhoneGap no es sólo un contenedor nativo de una aplicación web. A través de las API de JavaScript de PhoneGap, la "aplicación web" tiene acceso a las funciones del teléfono móvil como Geolocalización, Cámara Acelerómetro, Contactos, Base de datos, Sistema de archivos, etc. Básicamente cualquier función que el teléfono móvil SDK proporciona puede ser "puenteada" Javascript mundo. Por otro lado, una aplicación web normal que se ejecuta en el navegador web móvil no tiene acceso a la mayoría de estas funciones (la seguridad es la razón principal). Por lo tanto, una aplicación de PhoneGap es más una aplicación móvil que una aplicación web. Sin duda puedes usar PhoneGap para envolver una aplicación web que no utilice ninguna API de PhoneGap en absoluto, pero eso no es para lo que PhoneGap fue creado.

2. Titanium no compila su código html, css o javascript en "bits nativos". Se empaquetan como recursos para el paquete ejecutable, al igual que un archivo de imagen incrustada. Cuando se ejecuta la aplicación, estos recursos se cargan en un control UIWebView y se ejecutan allí (como javascript, no bits nativos, por supuesto). No hay tal cosa como un compilador javascript-to-native-code (o to-objective-c). Esto se hace de la misma manera en PhoneGap también. Desde el punto de vista arquitectónico, estos dos marcos son muy similares.

Ahora, ¿son diferentes? Sí. En primer lugar, Titanium parece ser más rica característica de PhoneGap por puente más funciones de teléfono móvil a javascript. Más notablemente, PhoneGap no expone muchos (si los hay) componentes nativos de la interfaz de usuario a javascript. Titanium, por otro lado, tiene una API de interfaz de usuario completa que se puede llamar en javascript para crear y controlar todo tipo de controles de interfaz de usuario nativos. Utilizando estas API de interfaz de usuario, una aplicación Titanium puede parecer más "nativa" que una aplicación de PhoneGap. En segundo lugar, PhoneGap soporta más plataformas de telefonía móvil que Titanium. Las API de PhoneGap son más genéricas y pueden utilizarse en diferentes plataformas como iPhone, Android, Blackberry, Symbian, etc. Titanium está orientado principalmente a iPhone y Android al menos por ahora. Algunas de sus API son específicas de la plataforma (como las API de interfaz de usuario de iPhone). El uso de estas API reducirá la capacidad multiplataforma de su aplicación.

Por lo tanto, si su preocupación por su aplicación es hacerlo más "nativo" buscando, Titanium es una mejor opción. Si desea ser capaz de "puerto" de su aplicación a otra plataforma más fácilmente, PhoneGap será mejor.

Actualizado el 13/8/2010: Enlace a la respuesta de un empleado de Titanium a la pregunta de Mickey.

Updated 12/04/2010: Decidí dar a este puesto una revisión anual para mantener su información actual. Muchas cosas tienen cambios en un año que hizo que algo de la información en el post inicial fuera obsoleta.

El mayor cambio vino de Titanium. A principios de este año, Appcelerator lanzó Titanium 1.0, que salió drásticamente de sus versiones anteriores desde el punto de vista arquitectónico. En 1.0, el control UIWebView ya no está en uso. En su lugar, puede llamar a API de Titanio para cualquier función de interfaz de usuario. Este cambio significa un par de cosas:

1. Tu interfaz de usuario de aplicación se vuelve completamente nativa. No hay más interfaz de usuario web en tu aplicación, ya que las API de Titanium nativas asumen el control de todas tus necesidades de interfaz de usuario. Titanium merece mucho crédito al ser pionero en la frontera "Cross-Platform Native UI". Da a los programadores que prefieren la apariencia de la interfaz de usuario nativa, pero no les gusta el lenguaje de programación oficial una alternativa.

2. No podrás usar HTML o CSS en tu aplicación, ya que la vista web se ha ido. (Nota: todavía puedes crear una vista web en Titanium, pero hay algunas características de Titanium que puedes aprovechar en la vista web.) Q & A de Titanium: ¿Qué pasó con HTML y CSS?

3. No será posible utilizar las bibliotecas JS populares como JQuery que asumen la existencia de un objeto DOM. Continúa utilizando JavaScript como idioma de codificación. Pero eso es más o menos la única tecnología web que puede utilizar si viene a Titanium 1.0 como un programador web.

Titanium video: Lo nuevo en Titanium 1.0.

Ahora, ¿Titanium 1.0 compila su JavaScript en "bits nativos"? No. Appcelerator finalmente llegó limpio en este tema con este blog de desarrolladores: Titanium Guides Project: JS Environment. Los programadores somos personas más genuinas que las del departamento de marketing, ¿no? Todos los derechos reservados

Vaya a PhoneGap. No hay muchas cosas que comentar sobre PhoneGap. Mi percepción es que PhoneGap desarrollo no estaba muy activo hasta que IBM saltó a bordo a finales de este año. Algunas personas incluso argumentaron que IBM está contribuyendo más código a PhoneGap que Nitobi. Que sea cierto o no, es bueno saber que PhoneGap se está desarrollando activamente.

PhoneGap sigue basándose en las tecnologías web, a saber HTML, CSS y JavaScript. No parece que PhoneGap tenga algún plan para conectar las características nativas de la interfaz de usuario con JavaScript, como Titanium está haciendo. Mientras que la interfaz de usuario web sigue estando a la zaga de la interfaz de usuario nativa en el rendimiento y la apariencia nativa, esta brecha se está cerrando rápidamente. Hay dos tendencias en las tecnologías web que aseguran característica brillante a la interfaz de usuario web móvil en términos de rendimiento:

1. Motor de JavaScript que se mueve de un intérprete a una máquina virtual. JavaScript es JIT compilado en código nativo para una ejecución más rápida. Motor Safari JS: SquirrelFish Extreme

2. Rendimiento de páginas Web pasando de la dependencia de la CPU a la aceleración de la GPU. Tareas gráficas intensivas como la transición de páginas y la animación 3D se vuelven mucho más suaves con la ayuda de la aceleración de hardware. Composición Acelerada de GPU en Chrome

Tales mejoras que se originan desde los navegadores de escritorio se están entregando a los navegadores móviles rápidamente. De hecho, desde iOS 3.2 y Android 2.0, el control de vista web móvil se ha vuelto mucho más eficaz y amigable para HTML5. El futuro de la web móvil es tan prometedor que ha atraído a un gran chico a la ciudad: JQuery ha anunciado recientemente su marco web móvil. Con JQuery Mobile proporcionando gadgets de interfaz de usuario y PhoneGap proporcionando características de teléfono, dos combinados crea una perfecta plataforma web móvil en mi opinión.

También debo mencionar Sencha Touch como otro framework de gadget de interfaz de usuario web móvil. Sencha Touch versión 1.0 fue lanzado recientemente bajo un modelo de licencia dual que incluye GPLv3. Sencha Touch funciona bien con PhoneGap como lo hace JQuery Mobile.

Si usted es un programador GWT (como yo), puede que desee comprobar GWT Mobile , un proyecto de código abierto para la creación de aplicaciones web para móviles con GWT. Incluye un envoltorio de PhoneGap GWT que permite el uso de PhoneGap en GWT.

De lo que he recogido, aquí hay algunas diferencias entre los dos:

• PhoneGap genera básicamente envoltorios nativos para lo que todavía son aplicaciones web . Escupe un proyecto de WhateverYourPlatformIs, lo construye y lo despliega. Si estamos hablando del iPhone (que es donde paso mi tiempo), no parece muy diferente de la creación de un lanzador de aplicaciones web (un atajo que recibe su propio icono de trampolín, por lo que puede lanzarlo como ( como ) Una aplicación nativa). La "aplicación" en sí es todavía html / js / etc, y se ejecuta dentro de un control de navegador alojado. Lo que PhoneGap proporciona más allá es un puente entre JavaScript y las API de dispositivos nativos. Por lo tanto, usted escribe JavaScript contra PhoneGap APIs, y PhoneGap luego hace la correspondiente llamada nativa correspondiente. En ese sentido, es diferente de desplegar una simple aplicación web antigua.

• La fuente de titanio se compila a bits nativos. Es decir, su html / js / etc. No están simplemente conectados a un proyecto y luego alojados dentro de un control de navegador web – se convierten en aplicaciones nativas. Esto significa, por ejemplo, que la interfaz de la aplicación se compondrá de componentes nativos de la interfaz de usuario. Hay maneras de obtener look-and-feel nativo sin tener una aplicación nativa, pero … bueno … qué pesadilla que normalmente resulta ser.

Los dos son similares en que usted escribe todas sus cosas usando tecnologías web típicas (html / js / css / bla bla bla), y que obtiene acceso a la funcionalidad nativa a través de API JavaScript personalizado.

Pero, una vez más, PhoneGap aplicaciones (PhonGapps? No sé … es que un nombre estúpido? Es más fácil decir – sé que mucho) comenzar sus vidas como aplicaciones web y terminar sus vidas como aplicaciones web. En el iPhone, su html / js / etc. Se ejecuta dentro de un control UIWebView y las API de JavaScript de PhoneGap sus llamadas js se encaminan a las API nativas.

Las aplicaciones de titanio se convierten en aplicaciones nativas: solo se desarrollan con tecnología de desarrollo web.

¿Qué significa esto en realidad?

1. Una aplicación Titanium se verá como una aplicación "real" porque, en última instancia, es una aplicación "real".

2. Una aplicación de PhoneGap se verá como una aplicación web alojada en un control de navegador porque, en última instancia, se trata de una aplicación web alojada en un control de navegador.

¿Cuál es el adecuado para usted?

• Si quieres escribir aplicaciones nativas usando habilidades de desarrollo web, Titanium es tu mejor opción.

• Si quieres escribir una aplicación con habilidades de desarrollo web que puedas implementar de forma realista en varias plataformas (iPhone, Android, Blackberry, y cualquier otra cosa que decida incluir), y si quieres acceder a un subconjunto de características nativas de la plataforma (GPS, Acelerómetro, etc.) a través de una API JavaScript unificada, PhoneGap es probablemente lo que desea.

Usted podría estar preguntando: ¿Por qué me gustaría escribir un PhoneGapp (he decidido utilizar el nombre) en lugar de una aplicación web que está alojado en la web? ¿Todavía no puedo acceder a algunas características de dispositivos nativos de esa manera, pero también tengo la conveniencia de un despliegue web real en lugar de obligar al usuario a descargar mi aplicación "nativa" e instalarla?

La respuesta es: Debido a que puede enviar su PhoneGapp a la App Store y cobrar por ella. También obtendrá el icono del lanzador, lo que dificulta que el usuario se olvide de su aplicación (es mucho más probable que olvide un marcador que un icono de aplicación).

Sin duda podría cobrar por el acceso a su aplicación web web alojada, pero ¿cuántas personas realmente van a pasar por el proceso para hacer eso? Con la App Store, elijo una aplicación, presiona el botón "Comprar", ingresa una contraseña y terminé. Se instala. Segundos después, lo estoy usando. Si tuviera que usar la interfaz de transacción de una web móvil de otra persona, lo que probablemente significa tener que aprovechar mi nombre, dirección, número de teléfono, número de CC y otras cosas que no quiero aprovechar, T pasar con ella. Además, confío en Apple – estoy seguro de que Steve Jobs no va a registrar mi información y luego cobrar un montón de suscripciones revistas travieso a mi CC para patadas.

De todos modos, a excepción del hecho de que la tecnología web dev está involucrado, PhoneGap y Titanium son muy diferentes – al punto de ser sólo superficialmente comparable.

Odio las aplicaciones web, por el por, y si usted lee comentarios iTunes App Store, los usuarios son bastante buenos en detectarlos. No voy a nombrar ningún nombre, pero tengo un par de "aplicaciones" en mi teléfono que se ven y se ejecutan como basura, y es porque son aplicaciones web que están alojados dentro de UIWebView instancias. Si quisiera usar una aplicación web, abriría Safari y, ya sabes, navegaría a uno. Compré un iPhone porque quiero cosas que son iPhone-y. No tengo ningún problema en usar, digamos, una atractiva aplicación web de Google dentro de Safari, pero me sentiría engañado si Google acaba de conseguir un marcador en Springboard presentando una aplicación web como nativa.

Debo irme ahora. Mi novia tiene esa mirada de poder-tú-por favor-parar-usar-ese-ordenador-para-tres-segundos en su cara.

Estoy tomando un curso en desarrollo de Android / iPhone y pasamos 8 semanas con Titanium (no a tiempo completo) (la versión era Titanium 1.4.2 y el tiempo era alrededor de noviembre de 2010). Aquí está mi experiencia.

Doble objetivo de Android para Android

Aunque las guías de la API afirman que la funcionalidad está disponible tanto para Android como para iPhone, este no es el caso. Muchas de las cosas simplemente no funcionan en una de las plataformas. Algunas cosas funcionan de manera diferente.

Muchas de las personas de la clase han hecho aplicaciones para iPhone, y no pueden hacerlas funcionar en Android sin grandes reescrituras. Desarrollé una simple aplicación para niños llamada Animap (ver android market / Appstore en Suecia) y comenzó a desarrollarse bajo Windows. Una vez que el objetivo de Android estaba funcionando, abrí el proyecto en OS X. No muestra ningún material de compilación para el iPhone, solo para Android. Es necesario iniciar un proyecto de doble objetivo bajo OS X. (Ok, he copiado los archivos pertinentes a un nuevo proyecto). Próximo problema – las animaciones no funcionan en el iPhone (que funcionan en Android). Los eventos de desplazamiento no funcionan igual en el iPhone. (Es decir, en Android se obtiene el evento untouch cuando el usuario deja de desplazarse y libera el dedo de la pantalla, esto no sucede en el iPhone).

Dado que esto no se menciona en algún lugar que básicamente necesita hacer la programación de prueba y error en la primera plataforma, a continuación, en la otra plataforma. Por ensayo y error, quiero decir que se tardará unos dos días para obtener una aplicación tan simple como Animap trabajando en la otra plataforma. También necesitará tener (android) entonces … o si (iphone) … todo sobre su código …

Descargar y configurar

Usted debe seguir las instrucciones a la carta. No intente utilizar Java 64 bits. No compilará la aplicación de demostración de KitchenSink 1.4.0. (1.3 funciona bien!) Debe colocar los archivos directamente en la unidad C, ya que los nombres de ruta largos harán que el programa externo no reciba todos los parámetros de la línea de comandos si llegan a largo. (Bueno para pequeños programas sin embargo) 1/3 de las veces, la cadena de herramientas simplemente se detiene y debe presionar 'lanzar' de nuevo. Entonces probablemente trabajará … muy poco fiable. El simulador no se encontrará en el arranque y entonces usted debe simplemente matar de adb.exe con Ctrl + Alt + Suprimir y reintentar.

Conexión de red

En una red wifi a veces se pierde la conexión en vivo y Titanium se bloquea en usted (la interfaz de compilación / despliegue) Si no tiene una conexión a Internet de trabajo no se iniciará, ya que no puede iniciar sesión en sus servidores.

API

CSS, HTML y jQuery es una brisa en comparación con esto. Titanium se asemeja a cualquier otra interfaz gráfica de usuario antigua, y es necesario establecer algunas propiedades para cada botón / campo / etc. Conseguir un campo equivocado es fácil, recordando todas las propiedades que necesita ser fijado? ¿Lo deletreaste con letras mayúsculas en el lugar correcto? (Como esto no es atrapado por el compilador, pero se verá como un error de tiempo de ejecución si tienes la suerte de probar esa parte)

En Titanium las cosas simplemente se rompen cuando se agrega otra vista encima de un control o se hace clic en otro lugar de la GUI.

Documentación

Varias páginas de la API llevan el símbolo de Android, pero sólo devolverá un valor nulo cuando intente crear el control. No están simplemente disponibles en la plataforma Android a pesar de los símbolos. A veces, Android menciona que no es compatible con un método en particular, pero luego falta toda la API.

Cocina

La aplicación de demostración. ¿He mencionado que no compila si lo pones en tu carpeta de proyectos de Eclipse porque la ruta de acceso es demasiado larga? Debe ser puesto en su unidad C en la carpeta raíz. Actualmente utilizo un enlace symbolik (mklink / J …)

Métodos indocumentados

Debe utilizar propably las cosas como label.setText ('Hello World') para cambiar una etiqueta fiable, pero esto no está documentado en absoluto.

Depuración

Titanium.API.info ('Las impresiones son la única manera de depurar');

Edición

Las API no están disponibles en ningún buen formato, por lo que no puede obtener la terminación de código normal con ayuda, etc. en Eclipse. Aptana por favor ayuda!

Hardware

Parece que el compilador / herramientas no son multiproceso por lo que una computadora rápida con un disco duro rápido es una necesidad, ya que debe hacer un montón de ensayo y error. ¿Mencioné la pobre documentación? Usted debe probar todo lo que no se puede confiar en él!

Algunas cosas positivas

• Fuente abierta

• De proyectos anteriores me he prometido a mí mismo nunca volver a utilizar la fuente cerrada de nuevo, ya que no se puede simplemente arreglar las cosas con sólo lanzar horas y mano de obra en ella. Importante cuando se retrasa en el proyecto y la necesidad de entregar para un plazo difícil. Esto es de código abierto y he sido capaz de ver por qué la cadena de herramientas se rompe y realmente arreglarlo también.

• Bugdatabase

• También está abierto. Usted puede simplemente ver que su no solo y hacer una solución en lugar de otras 4 horas gastado en ensayo y error.

• Comunidad

• Parece estar activo en sus foros.

Loco

• Titanium 1.4 no es resistente a los hilos . Eso significa que si usted hace uso de hilos (use la propiedad url: en una llamada createWindow) y el programa como los hilos están trabajando y enviar eventos con datos de ida y vuelta que se ejecutan en un montón de cosas muy, muy extraño – perdidos manipuladores, perdido Ventanas, demasiados eventos, demasiados eventos, etc. etc. Todo depende de la sincronización, poniendo las filas de código en orden diferente podría bloquear o curar su aplicación. Añadir una ventana en otro archivo.js rompe su ejecución app.js … Esto también trashes estructuras de datos internas en Titanium, ya que a veces puede actualizar las estructuras de datos internas en paralell, sobrescribiendo un valor simplemente cambiado con otra cosa.

Muchos de los problemas que he tenido con Titanium provienen de mi experiencia en sistemas en tiempo real como OSE que soportan cientos de hilos, eventos y mensajes que pasan. Esto se supone que funciona en Titanium 1.4, pero simplemente no lo hace de manera fiable.

• Javascript (que es nuevo para mí) muere silenciosamente en errores de ejecución. Esto también significa que los errores pequeños y comunes, como la falta de ortografía de un nombre de variable o la lectura en un puntero nulo no se bloquea cuando se debe para que pueda depurar. En lugar de las partes de su programa simplemente dejar de trabajar, por ejemplo, un eventhandler, porque usted mal colocado / misstyped un personaje.

• Entonces tenemos errores más simples en Titanium, como algunos parámetros que no funcionan en las funciones (que es bastante común en la plataforma Android al menos).

• Velocidad de prueba y ciclo de depuración de errores Después de ejecutar Titnium Developer en varios ordenadores, me di cuenta de que el cuello de botella es el disco duro. Una unidad SSD en una computadora portátil hace que el ciclo de construcción de 3-5 veces más rápido que en una unidad de 4200 rpm. En un escritorio, tener dos unidades en RAID 1 (modo striping) hace que la construcción sea un 25% más rápida que en una sola unidad con una CPU un poco más rápida y también supera la unidad portátil SSD.

Resumen

• De los comentarios en este hilo parece que hay una lucha por el número de plataformas de una herramienta como esta puede entregar la aplicación para. El número de API parece ser el punto de venta clave.

Esto brilla a través de mucho cuando usted comienza a usarlo. Si observa el bugtracker abierto, verá que el número de errores sigue aumentando más rápido que el número de errores fijos. Esto suele ser una señal de que los desarrolladores siguen agregando más funcionalidad, en lugar de concentrarse en obtener el número de errores.

Como consultor tratando de ofrecer aplicaciones sencillas a multiplataforma para un cliente, no estoy seguro de que esto sea más rápido que el desarrollo de aplicaciones nativas en dos plataformas. Esto se debe al hecho de que cuando estás a la velocidad que son rápidos con titanio, pero luego de repente se mira hacia abajo y se encuentra en un agujero tan profundo que no sé cuántas horas deben gastarse para una solución. Simplemente NO puede prometer una cierta funcionalidad para un determinado plazo / tiempo / costo.

Sobre mí: He estado usando Python durante dos años con wxPython. (Que la interfaz gráfica de usuario es inconsistente, pero nunca se rompe como este.Puede ser yo que no han entendido el modelo de subprocesos utilizados por Javascript y Titanium, pero no estoy solo de acuerdo con sus foros de discusión abierta, los objetos GUI de repente utilizan el contexto / No actualizar .. ???) antes de que tengo un fondo en C y ASM de programación para dispositivos móviles.

[Editar – agregó parte con errores y no ser hilo seguro] [Editar – ahora que ha trabajado con él durante un mes +, sobre todo en la PC, pero algunos en OS X también. Añadido iPhone y Android doble objetivo. Se agregó la velocidad de ciclo de depuración de prueba y error.]

El SDK Corona (Ansca Mobile) utiliza Lua como su lenguaje de codificación. Vea lua.org para más información sobre Lua.

Aunque planeamos agregar elementos adicionales de integración web y elementos nativos de la interfaz de usuario, nuestro enfoque tenderá a utilizarse en aplicaciones con gran cantidad de gráficos, como el desarrollo de juegos, en comparación con las tecnologías basadas en la Web. En otras palabras, no imaginamos a las personas que escriben aplicaciones Corona completamente en Javascript / HTML / CSS.

He estado trabajando con Titanium durante más de una semana y siento que tengo una buena sensación sobre su debilidad.

1) Si usted espera que use el mismo código en plataformas múltiples buena suerte! Verás algo como backgroundGradient y te sorprenderás hasta que descubras que la versión de android no lo admite. Entonces tiene que volver a usar una imagen de degradado, podría también utilizarlo para ambas versiones para hacer el código más fácil?

2) Una gran cantidad de comportamientos extraños, en el sdk Titanium android que necesita para entender lo que es una ventana "pesado" es sólo para obtener el botón de vuelta para trabajar, o incluso un mejor seguimiento de eventos de orientación. Esto no es lo que realmente es la plataforma android, es sólo cómo Titanium intenta hacer que su API funcione.

3) Su tiro en la oscuridad, Las cosas se bloquean y tienes que empezar a comentar el código y luego cuando lo encuentre, nunca lo use. Hay ciertos errores obvios, como la orientación y los porcentajes en Android que han sido un problema durante más de seis meses.

4) bichos … hay un montón de bichos y se informará, sentarse alrededor de meses, se arreglaron en unos pocos días. Estoy sorprendido de que incluso están planeando lanzar un sdk móvil berry negro cuando hay tantos otros problemas con android.

5) Titanium Iphone vs Titanium Android motores de Javascript son completamente diferentes. En la versión android puedes descargar archivos javascript remotos, incluir y usar bibliotecas como mootools, jquery y así sucesivamente. Yo estaba en el cielo cuando me enteré de esto porque no tenía que seguir compilando mi aplicación para Android. El proceso de instalación de apk de Android tarda tanto! Iphone nada de eso es posible, también la versión de iphone tiene un motor mucho más rápido javascript.

Si te quedas lejos de muchas de las partes nativas de la interfaz de usuario, es decir, usa setInterval para detectar cambios de orientación, pegarse con imágenes de degradado, olvidar el botón de retroceso, construir tus propias animaciones, olvidar el encabezado de la ventana, las barras de herramientas y el tablero. Usted realmente puede hacer una api que funciona en ambos que no requiere de mucho de reescritura. Pero en ese punto es tan lento como una aplicación web.

Entonces ¿Vale la pena? Después de todo el dolor, vale cada minuto. Puede abstraer la lógica y construir sólo una interfaz de usuario diferente para cada uno, en lugar de hacerlo si quiere hacerlo en todas partes. Titanium le permite hacer aplicaciones fluidas, que se sienten rápido. Pierdes las potentes habilidades de diseño de cada plataforma, pero si crees que son simples, las cosas pueden hacerse bajo un solo idioma.

¿Por qué no una aplicación web? En el mercado de nivel de entrada teléfonos Android es horriblemente lento para generar una webview y consume una gran cantidad de memoria que podría estar utilizando para hacer la lógica más compleja.

Aquí hay un análisis más reciente y en profundidad de Appcelerator y PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

Y aquí hay aún más detalles sobre cómo se diferencian por programación: http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript

Native mapkit es compatible con Titanium

Hacer HTML5 widgets tha aspecto de widgets iphone es una cosa, pero hacer que funcionen igualmente bien es otra cuestión en conjunto. El rendimiento de las animaciones html5 (incluso las transiciones de vista sencillas), el desplazamiento de listas largas, la capacidad de respuesta a los gestos se sienten pegajosos y sacudidos. Un usuario de iPhone notará la diferencia.

También hay algunas diferencias en los tipos de gestos que son compatibles con diferentes dispositivos, lo que resulta en código de plataforma específica y problemas de usabilidad también.

Me quedaré con aplicaciones nativas por ahora, supongo.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) es muy similar en el enfoque de PhoneGap, pero es el único marco con:

1. Un patrón Model View Controller (como la mayoría de los frameworks web proporcionan)
2. Un gestor relacional de objetos
3. Soporte para todos los smartphones populares (incluido Windows Phone 7)
4. Un servicio de desarrollo alojado (no sólo alojado construir): http://rhohub.com
5. Un depurador completo y un emulador sin SDK en el IDE de RhoStudio
6. Soporte para datos sin conexión sincronizados

Para cualquier persona interesada en titanio debo decir que no tienen una documentación muy buena algunas clases, propiedades, métodos están desaparecidos. Pero mucho está "documentado" en su aplicación de ejemplo el KitchenSink por lo que no es tan malo.

Mi comprensión de PhoneGap es que proporcionan API Javascript a gran parte de las API del iPhone.

Titanium parece más fácil para un desarrollador web de fondo. Es un simple archivo XML para crear una aplicación TabView básica y luego todo en el área de contenido es controlado por HTML / JS. También sé que Titanium proporciona un cierto acceso del javascript a algunos de los marcos (particularmente acceso a la información de la localización, la identificación del teléfono, etc).

ACTUALIZACIÓN: Titanium agregó API de Google Maps en la versión 0.8 de su framework.

Usted debe aprender el objetivo c y programar aplicaciones nativas. No confíe en estas cosas que usted piensa harán la vida más fácil. Apple se ha asegurado de que la forma más fácil es usar sus herramientas nativas y su idioma. Para sus 100 líneas de javascript puedo hacer lo mismo en 3 líneas de código o ningún código en todo dependiendo del elemento. Ver algunos tutoriales – si usted entiende javascript entonces objetivo c no es difícil. Las soluciones son miserables y la manzana puede tirar del enchufe en usted en cualquier momento que quieran.

De las soluciones que mencionó, ninguna de ellas parece darle acceso directo al marco MapKit introducido en OS 3.0.

Como los widgets HTML de Google Maps no son tan buenos como MapKit (consulte Google Latitude para ver un ejemplo), es probable que sea mejor desarrollar una aplicación nativa de Cocoa Touch o elegir una solución que puede ampliar para agregar integración MapKit. PhoneGap es extensible de esta manera (es de código abierto por lo que es por defecto), y algunas de las otras soluciones podrían ser así.

Editar: Titanium ahora tiene soporte para MapKit

He intentado corona. Fue bueno hasta que descubrí que no soporta streaming de audio mp3. Así que me detuve allí. Creo que si realmente quiero ser un desarrollador de aplicaciones para iphone debería aprender obj c. Todo lo que quería hacer una aplicación que tiene una lista de estaciones de radio y haga clic en ellos empezar a jugar.