Comparação entre Corona, Phonegap, Titanium

Sou desenvolvedor da web e quero mover meus produtos da web para o iPhone. Um dos produtos é como o Google Maps: mostre o mapa na tela do telefone, você pode arrastar ou redimensionar o mapa e visualizar algumas informações que adicionamos ao mapa.

Eu sei que existem algumas tecnologias que permitem usar HTML, CSS e Javascript para desenvolver aplicativos nativos do iPhone. Eu identifiquei alguns:

• Ansca Mobile
• PhoneGap
• Appcelerator

Existem outros produtos similares? Quais são as diferenças entre eles? Qual devo escolher?

Registrei-me no stackoverflow apenas para comentar a resposta mais votada no topo. O lado ruim é que o stackoverflow não permite que novos membros publiquem comentários. Então, eu tenho que fazer esse comentário parecer mais uma resposta.

A resposta de Rory Blyth contém alguns pontos válidos sobre as duas estruturas móveis javascript. No entanto, seus pontos principais estão incorretos. A verdade é que Titanium e PhoneGap são mais parecidos que diferentes. Ambos expõem as funções do telefone celular por meio de um conjunto de APIs javascript, e a lógica do aplicativo (html, css, javascript) é executada dentro de um controle nativo do WebView.

1. O PhoneGap não é apenas um invólucro nativo de um aplicativo da web. Por meio das APIs javascript PhoneGap, o "aplicativo da web" tem acesso às funções do telefone celular, como geolocalização, câmera do acelerômetro, contatos, banco de dados, sistema de arquivos etc. Basicamente, qualquer função fornecida pelo SDK do telefone celular pode ser "conectada" ao mundo javascript. Por outro lado, um aplicativo Web normal que é executado no navegador da Web móvel não tem acesso à maioria dessas funções (a segurança é o principal motivo). Portanto, um aplicativo PhoneGap é mais um aplicativo móvel do que um aplicativo da web. Você certamente pode usar o PhoneGap para agrupar um aplicativo da Web que não usa nenhuma API do PhoneGap, mas não foi para isso que o PhoneGap foi criado.

2. O Titanium NÃO compila seu código html, css ou javascript em "bits nativos". Eles são empacotados como recursos para o pacote executável, como um arquivo de imagem incorporado. Quando o aplicativo é executado, esses recursos são carregados em um controle UIWebView e executados lá (como javascript, não bits nativos, é claro). Não existe um compilador de javascript para código nativo (ou para objetivo-c). Isso é feito da mesma maneira no PhoneGap também. Do ponto de vista arquitetônico, essas duas estruturas são muito semelhantes.

Agora, eles são diferentes? Sim. Primeiro, o Titanium parece ser mais rico em recursos do que o PhoneGap, conectando mais funções do telefone celular a javascript. O mais notável é que o PhoneGap não expõe muitos componentes da interface do usuário (se houver) nativos ao javascript. O Titanium, por outro lado, possui APIs de interface do usuário abrangentes que podem ser chamadas em javascript para criar e controlar todos os tipos de controles de interface de usuário nativos. Utilizando essas APIs da interface do usuário, um aplicativo Titanium pode parecer mais "nativo" que um aplicativo PhoneGap. Segundo, o PhoneGap suporta mais plataformas de telefonia móvel do que o Titanium. As APIs do PhoneGap são mais genéricas e podem ser usadas em diferentes plataformas, como iPhone, Android, Blackberry, Symbian etc. O Titanium está direcionado principalmente para iPhone e Android, pelo menos por enquanto. Algumas de suas APIs são específicas da plataforma (como as APIs da interface do usuário do iPhone).

Portanto, se sua preocupação com o aplicativo é torná-lo mais "nativo", o Titanium é uma escolha melhor. Se você deseja "portar" seu aplicativo para outra plataforma com mais facilidade, o PhoneGap será melhor.

Atualizado em 13/08/2010: Link para a resposta de um funcionário do Titanium à pergunta de Mickey.

Atualizado em 04/04/2010: decidi fazer uma revisão anual neste post para manter suas informações atualizadas. Muitas coisas mudaram em um ano, tornando algumas das informações do post inicial desatualizadas.

A maior mudança veio do titânio. No início deste ano, o Appcelerator lançou o Titanium 1.0, que saiu drasticamente de suas versões anteriores do ponto de vista arquitetônico. Na 1.0, o controle UIWebView não está mais em uso. Em vez disso, você chama APIs de titânio para quaisquer funções da interface do usuário. Essa mudança significa algumas coisas:

1. A interface do usuário do seu aplicativo se torna completamente nativa. Não há mais interface do usuário da web no seu aplicativo, pois as APIs nativas do Titanium assumem o controle de todas as suas necessidades de interface do usuário. O Titanium merece muito crédito por ser pioneiro na fronteira da "Interface do usuário nativa entre plataformas". Ele oferece aos programadores que preferem a aparência da interface do usuário nativa, mas não gostam da linguagem de programação oficial como alternativa.

2. Você não poderá usar HTML ou CSS em seu aplicativo, pois a visualização da Web desapareceu. (Nota: você ainda pode criar uma visualização da Web no Titanium. Mas existem alguns recursos do Titanium que podem ser aproveitados na visualização da Web.) Perguntas e respostas sobre o Titanium: O que aconteceu com HTML e CSS?

3. Você não poderá usar bibliotecas JS populares, como JQuery, que assumem a existência de um objeto DOM. Você continua usando o JavaScript como sua linguagem de codificação. Mas essa é praticamente a única tecnologia da web que você pode utilizar se vier ao Titanium 1.0 como programador da web.

Vídeo Titanium: O que há de novo no Titanium 1.0.

Agora, o Titanium 1.0 compila seu JavaScript em "bits nativos"? Não. O Appcelerator finalmente se esclareceu sobre esse problema com este blog de desenvolvedor: Projeto Titanium Guides: JS Environment. Nós programadores somos pessoas mais genuínas do que aquelas do departamento de Marketing, não somos? :-)

Vá para o PhoneGap. Não há muitas coisas novas a dizer sobre PhoneGap. Minha percepção é de que o desenvolvimento do PhoneGap não estava muito ativo até a IBM entrar no mercado ainda este ano. Algumas pessoas chegaram a argumentar que a IBM está contribuindo com mais código para o PhoneGap do que o Nitobi. Sendo verdade ou não, é bom saber que o PhoneGap está sendo desenvolvido ativamente.

O PhoneGap continua a basear-se em tecnologias da web, como HTML, CSS e JavaScript. Parece que o PhoneGap não planeja conectar recursos nativos da interface do usuário ao JavaScript, como o Titanium está fazendo. Enquanto a interface do usuário da Web ainda fica atrás da interface do usuário nativa em desempenho e aparência nativa, essa lacuna está sendo rapidamente preenchida. Há duas tendências nas tecnologias da web que garantem um recurso brilhante à interface da web da web móvel em termos de desempenho:

1. Mecanismo JavaScript passando de um intérprete para uma máquina virtual. O JavaScript é JIT compilado no código nativo para uma execução mais rápida. Mecanismo Safari JS: SquirrelFish Extreme

2. Renderização de página da Web, passando de confiar na CPU para usar a aceleração de GPU. Tarefas intensivas em gráficos, como transição de página e animação 3D, tornam-se muito mais suaves com a ajuda da aceleração de hardware. Composição acelerada por GPU no Chrome

Essas melhorias originadas nos navegadores de desktop estão sendo entregues rapidamente aos navegadores móveis. De fato, desde o iOS 3.2 e o Android 2.0, o controle de visualização na Web para dispositivos móveis se tornou muito mais eficiente e compatível com HTML5. O futuro da web móvel é tão promissor que atraiu um grande garoto para a cidade: a JQuery anunciou recentemente sua estrutura da web móvel. Com o JQuery Mobile fornecendo gadgets de interface do usuário e o PhoneGap fornecendo recursos de telefone, os dois combinados criam uma plataforma da Web móvel perfeita na minha opinião.

Também devo mencionar o Sencha Touch como outra estrutura de gadget da interface do usuário da Web para dispositivos móveis. O Sencha Touch versão 1.0 foi lançado recentemente sob um modelo de licenciamento duplo que inclui GPLv3. O Sencha Touch funciona bem com o PhoneGap, assim como o JQuery Mobile.

Se você é um programador de GWT (como eu), pode consultar o GWT Mobile , um projeto de código aberto para criar aplicativos da Web móveis com o GWT. Ele inclui um wrapper PhoneGap GWT que permite o uso do PhoneGap no GWT.

Pelo que reuni, aqui estão algumas diferenças entre os dois:

• O PhoneGap basicamente gera wrappers nativos para o que ainda são aplicativos da web . Ele cospe um projeto WhateverYourPlatformIs, você o constrói e implanta. Se estamos falando sobre o iPhone (que é onde eu passo meu tempo), não parece muito diferente de criar um iniciador de aplicativos da web (um atalho que obtém seu próprio ícone do Springboard, para que você possa iniciá-lo como ( como )) um aplicativo nativo). O "aplicativo" em si ainda é html / js / etc. E é executado dentro de um controle de navegador hospedado. O que o PhoneGap fornece além disso é uma ponte entre JavaScript e APIs de dispositivos nativos. Então, você escreve JavaScript nas APIs do PhoneGap e o PhoneGap faz a chamada nativa correspondente apropriada. A esse respeito, é diferente de implantar um aplicativo Web simples e antigo.

• A fonte de titânio é compilada em bits nativos. Ou seja, seu html / js / etc. não são simplesmente anexados a um projeto e hospedados em um controle de navegador da Web - eles são transformados em aplicativos nativos. Isso significa, por exemplo, que a interface do seu aplicativo será composta por componentes de interface do usuário nativos . Existem maneiras de obter a aparência nativa sem ter um aplicativo nativo, mas ... bem ... que pesadelo costuma ser.

Os dois são semelhantes: você escreve todas as suas coisas usando tecnologias típicas da Web (html / js / css / blá blá blá) e obtém acesso à funcionalidade nativa por meio de APIs JavaScript personalizadas.

Mas, novamente, os aplicativos PhoneGap (PhonGapps? Eu não sei ... é um nome estúpido? É mais fácil dizer - eu sei disso) que iniciam suas vidas como aplicativos da Web e terminam como aplicativos da Web. No iPhone, seu html / js / etc. é executado apenas dentro de um controle UIWebView e as APIs PhoneGap JavaScript que suas chamadas js são roteadas para APIs nativas.

Os aplicativos Titanium se tornam aplicativos nativos - eles são desenvolvidos apenas usando a tecnologia de desenvolvimento da Web.

O que isso realmente significa ?

1. Um aplicativo Titanium parecerá um aplicativo "real" porque, em última análise, é um aplicativo "real".

2. Um aplicativo PhoneGap se parecerá com um aplicativo Web hospedado em um controle de navegador porque, em última análise, é um aplicativo Web hospedado em um controle de navegador.

Qual é o certo para você?

• Se você deseja escrever aplicativos nativos usando habilidades de desenvolvedor da Web, o Titanium é sua melhor aposta.

• Se você deseja escrever um aplicativo usando as habilidades de desenvolvedor da Web que você pode implantar realisticamente em várias plataformas (iPhone, Android, Blackberry e o que mais eles decidirem incluir), e se deseja acessar um subconjunto de recursos nativos da plataforma (GPS, acelerômetro etc.) por meio de uma API JavaScript unificada, o PhoneGap é provavelmente o que você deseja.

Você pode estar se perguntando: por que eu gostaria de escrever um PhoneGapp (decidi usar o nome) em vez de um aplicativo da web hospedado na web? Ainda não consigo acessar alguns recursos nativos do dispositivo dessa maneira, mas também tenho a conveniência de uma verdadeira implantação na Web em vez de forçar o usuário a baixar o meu aplicativo "nativo" e instalá-lo?

A resposta é: porque você pode enviar seu PhoneGapp para a App Store e cobrar por ele. Você também recebe o ícone do iniciador, o que dificulta o usuário esquecer o seu aplicativo (é bem mais provável que eu esqueça um marcador do que um ícone do aplicativo).

Você certamente poderia cobrar pelo acesso ao seu aplicativo da web hospedado na web, mas quantas pessoas realmente passarão pelo processo para fazer isso? Com a App Store, eu escolho um aplicativo, toque no botão "Comprar", digite uma senha e pronto. Instala. Segundos depois, estou usando. Se eu tivesse que usar a interface única de transações da Web móvel de outra pessoa, o que provavelmente significa ter que digitar meu nome, endereço, número de telefone, número CC e outras coisas que não quero digitar, quase certamente não '. Não continue com isso. Além disso, confio na Apple - estou confiante de que Steve Jobs não vai registrar minhas informações e depois cobrar um monte de assinaturas de revistas impertinentes no meu CC por chutes.

De qualquer forma, exceto pelo fato de a web dev tech estar envolvida, o PhoneGap e o Titanium são muito diferentes - a ponto de serem apenas superficialmente comparáveis.

Eu odeio aplicativos da web, a propósito, e se você ler as resenhas da iTunes App Store, os usuários são muito bons em identificá-las. Não vou citar nenhum nome, mas tenho no meu telefone alguns "aplicativos" que parecem e funcionam como lixo, e é porque eles são aplicativos da Web hospedados nas instâncias do UIWebView. Se eu quisesse usar um aplicativo da Web, eu abriria o Safari e, você sabe, navegaria para um. Comprei um iPhone porque quero coisas que são iPhone-y. Não tenho problema em usar, digamos, um aplicativo da web do Google no Safari, mas me sentiria enganado se o Google colocasse um marcador no Springboard apresentando um aplicativo da web como nativo.

Tenho que ir agora. Minha namorada tem aquele olhar de "você pode parar de usar esse computador por três segundos" no rosto.

Estou fazendo um curso de desenvolvimento para Android / iPhone e passamos 8 semanas com Titanium (não em tempo integral) (a versão era Titanium 1.4.2 e o tempo era em novembro de 2010). Aqui está a minha experiência.

segmentação dupla para iPhone Android

Embora os guias da API afirmem que a funcionalidade está disponível para Android e iPhone, esse não é o caso. Muitas das coisas simplesmente não funcionam em uma das plataformas. Algumas coisas funcionam de maneira diferente.

Muitas pessoas da classe fizeram aplicativos para iPhone e não conseguem fazê-los funcionar no Android sem grandes reescritas. Desenvolvi um aplicativo simples para crianças chamado Animap (consulte Android Market / Appstore na Suécia) e comecei a desenvolver no Windows. Quando o destino do Android estava funcionando, abri o projeto no OS X. Ele não mostra nenhum material de compilação para o iPhone, apenas para o Android. Você precisa iniciar um projeto de destino duplo no OS X. (Ok, copiei os arquivos relevantes para um novo projeto). Próximo problema - as animações não funcionam no iPhone (elas funcionam no Android). Os eventos de rolagem não funcionam da mesma forma no iPhone. (ou seja, no Android, você obtém o evento untouch quando o usuário para de rolar e libera o dedo da tela, isso não acontece no iPhone).

Como isso não é mencionado em algum lugar, você basicamente precisa executar a programação de tentativa e erro na primeira plataforma e depois na outra plataforma. Por tentativa e erro, quero dizer que levará cerca de dois dias para que um aplicativo tão simples como o Animap funcione na outra plataforma. Você também precisará ter if (android) then ... ou if (iphone) ... em todo o código ...

Download e configuração

Você deve seguir as instruções da carta. Não tente usar java de 64 bits. Ele não compila o aplicativo de demonstração KitchenSink 1.4.0. (1.3 funciona bem!) Você deve colocar os arquivos diretamente na unidade C, desde que os nomes de caminho façam com que o programa externo não receba todos os parâmetros da linha de comando se eles chegarem muito tempo. (Bom para programas pequenos) 1/3 das vezes, a cadeia de ferramentas simplesmente para e você deve pressionar 'launch' novamente. Então provavelmente funcionará ... muito pouco confiável. O simulador não será encontrado na inicialização e, em seguida, você deve simplesmente eliminar o adb.exe com Ctrl + Alt + Delete e tentar novamente.

Conexão de rede

Em uma rede wifi, você às vezes perde a conexão ao vivo e o Titanium trava em você (a interface de compilação / implantação). Se você não tem uma conexão de internet em funcionamento, ela não será iniciada, pois não poderá fazer o logon nos servidores deles.

API

CSS, HTML e jQuery é muito fácil em comparação com isso. O Titanium se parece com qualquer outra API da GUI antiga e você precisa definir algumas propriedades para cada botão / campo / etc. Errar um campo é fácil, lembrando-se de todas as propriedades que precisam ser definidas? Você o escreveu com letras maiúsculas no lugar certo? (como isso não é detectado pelo compilador, mas será visto como um erro de tempo de execução se você tiver sorte de testar essa parte)

No Titanium, as coisas simplesmente quebram quando você adiciona outra exibição em cima de um controle ou clica em outro lugar na GUI.

Documentação

Várias páginas da API carregam o símbolo do Android, mas retornarão um valor nulo quando você tentar criar o controle. Eles não estão simplesmente disponíveis na plataforma Android, apesar dos símbolos. Às vezes, o Android é mencionado para não oferecer suporte a um método específico, mas a API inteira está ausente.

Pia da cozinha

O aplicativo de demonstração. Eu mencionei que ele não será compilado se você o colocar na pasta do projeto Eclipse porque o caminho é muito longo? Deve ser colocado na sua unidade C na pasta raiz. Atualmente, uso um link simbólico (mklink / J ...)

Métodos não documentados

Você deve usar as coisas como label.setText ('Hello World') para alterar um rótulo como confiável, mas isso não está documentado.

Depuração

Titanium.API.info ('As impressões são a única maneira de depurar');

Edição

As APIs não estão disponíveis em nenhum formato bom, portanto, você não pode obter a conclusão normal do código com ajuda, etc. no Eclipse. Aptana por favor me ajude!

Hardware

Parece que o compilador / ferramentas não são multithread, portanto, um computador rápido com um disco rígido rápido é obrigatório, pois você deve executar várias tentativas e erros. Eu mencionei a documentação pobre? Você deve experimentar tudo lá, pois não pode confiar!

Algumas coisas positivas

• Código aberto

• De projetos anteriores, prometi a mim mesmo nunca mais usar código fechado novamente, pois você não pode simplesmente consertar as coisas apenas jogando horas e mão de obra nele. Importante quando você está atrasado no projeto e precisa cumprir um prazo final. Este é um código aberto e eu pude ver por que a cadeia de ferramentas quebra e também a corrige.

• Bugdatabase

• Também está aberto. Você pode simplesmente ver que não está sozinho e fazer uma solução alternativa em vez de outras 4 horas gastas em tentativa e erro.

• Comunidade

• Parece estar ativo em seus fóruns.

Insetos

• O Titanium 1.4 não é seguro para threads . Isso significa que, se você usar os threads (use a propriedade url: em uma chamada createWindow) e programar como os threads estão funcionando e enviar eventos com dados para frente e para trás, você encontrará muitas coisas muito, muito estranhas - manipuladores perdidos, perdidos janelas, muitos eventos, poucos eventos etc. etc. Isso tudo depende do tempo, colocar as linhas de código em ordem diferente pode travar ou curar seu aplicativo. A adição de uma janela em outro file.js interrompe a execução do app.js ... Isso também prejudica as estruturas de dados internas no Titanium, pois às vezes elas podem atualizar as estruturas de dados internas em paralelo, substituindo um valor alterado por outra.

Muitos dos problemas que tive com o Titanium vêm da minha experiência em sistemas em tempo real como o OSE, que oferecem suporte a centenas de threads, eventos e passagem de mensagens. Isso deve funcionar no Titanium 1.4, mas simplesmente não é confiável.

• Javascript (que é novo para mim) morre silenciosamente devido a erros de tempo de execução. Isso também significa que erros pequenos e comuns, como digitar incorretamente o nome de uma variável ou ler um ponteiro nulo, não travam quando necessário, para que você possa depurá-lo. Em vez disso, partes do seu programa simplesmente param de funcionar, por exemplo, um manipulador de eventos, porque você perdeu / digitou um caractere.

• Temos então bugs mais simples no Titanium, como alguns parâmetros que não funcionam nas funções (o que é bastante comum na plataforma Android).

• Velocidade do ciclo de depuração de tentativa e erro Depois de executar o Titnium Developer em vários computadores, notei que o gargalo é o disco rígido. Uma unidade SSD em um laptop torna o ciclo de construção cerca de 3-5 vezes mais rápido do que em uma unidade de 4200 rpm. Em uma área de trabalho, ter unidades duplas no RAID 1 (modo de distribuição) torna a compilação cerca de 25% mais rápida do que em uma única unidade com uma CPU um pouco mais rápida e também supera o laptop da unidade SSD.

Resumo

• A partir dos comentários neste tópico, parece haver uma briga pelo número de plataformas pelas quais uma ferramenta como essa pode fornecer aplicativos. O número de API parece ser o principal ponto de venda.

Isso brilha muito quando você começa a usá-lo. Se você olhar para o rastreador de erros aberto, verá que o número de bugs continua aumentando mais rapidamente do que o número de bugs corrigidos. Isso geralmente é um sinal de que os desenvolvedores continuam adicionando mais funcionalidades, em vez de se concentrar em diminuir o número de bugs.

Como consultor tentando entregar aplicativos bastante simples para multiplataformas para um cliente - não tenho certeza se isso é realmente mais rápido do que o desenvolvimento de aplicativos nativos em duas plataformas. Isso se deve ao fato de que, quando você está em alta velocidade, é rápido com o Titanium, mas de repente você olha para baixo e se encontra em um buraco tão profundo que não sabe quantas horas devem ser gastas para uma solução alternativa. Você simplesmente não pode prometer uma certa funcionalidade por um determinado prazo / tempo / custo.

Sobre mim: Uso Python há dois anos com wxPython. (essa GUI é inconsitente, mas nunca quebra assim. Pode ser que eu não tenha entendido o modelo de encadeamento usado por Javascript e Titanium, mas não estou sozinho de acordo com os fóruns de discussão abertos, os objetos da GUI estão subitamente usando o contexto errado / não atualizando .. ???) antes disso, eu tenho experiência em programação C e ASM para dispositivos móveis.

[edit - parte adicionada com bugs e não sendo seguro para threads] [edit - agora tendo trabalhado com isso por mais de um mês, principalmente no PC, mas alguns no OS X também. Adicionado direcionamento duplo para iPhone e Android. Adicionada velocidade do ciclo de depuração de tentativa e erro.]

O SDK da Corona (Ansca Mobile) usa Lua como sua linguagem de codificação. Veja lua.org para mais informações sobre Lua.

Embora planejemos adicionar mais integração à Web e elementos de interface do usuário nativa, nosso foco tenderá a ser em aplicativos com muitos gráficos, como desenvolvimento de jogos, em oposição às tecnologias baseadas na Web. Em outras palavras, não imaginamos pessoas escrevendo aplicativos Corona inteiramente em Javascript / HTML / CSS.

Eu trabalho com o Titanium há mais de uma semana e sinto que tenho uma boa impressão sobre sua fraqueza.

1) Se você espera usar o mesmo código em várias plataformas, boa sorte! Você verá algo como backgroundGradient e ficará surpreso até descobrir que a versão do Android não é compatível. Então, se você voltar a usar uma imagem de gradiente, é melhor usá-la nas duas versões para facilitar o código, certo?

2) Muitos comportamentos estranhos, no android sdk Titanium, você precisa entender o que é uma janela "pesada" apenas para fazer com que o botão voltar funcione, ou ainda melhor acompanhamento de eventos de orientação. Não é assim que a plataforma Android realmente é; é exatamente como o Titanium tenta fazer a API funcionar.

3) Quando jogado no escuro, o Things falhará e você terá que começar a comentar o código e, quando o encontrar, nunca o usará. Existem alguns erros óbvios, como orientação e porcentagens no Android, que são um problema há mais de seis meses.

4) Bugs .... existem muitos bugs e eles serão relatados, ficarão sentados por meses, serão consertados em alguns dias. Estou surpreso que eles estejam planejando lançar um sdk móvel black berry quando há muitos outros problemas com o android.

5) Os motores de javascript para iPhone Titanium versus Titanium Android são completamente diferentes. Na versão Android, você pode baixar arquivos javascript remotos, incluir e usar bibliotecas como mootools, jquery e assim por diante. Eu estava no céu quando descobri isso porque não precisava compilar meu aplicativo para Android. O processo de instalação do apk Android leva tanto tempo! Iphone nada disso é possível, também a versão para iphone tem um mecanismo javascript muito mais rápido.

Se você ficar longe de muitas partes nativas da interface do usuário, por exemplo, use setInterval para detectar alterações de orientação, mantendo imagens gradientes, esqueça o botão voltar, crie suas próprias animações, esqueça o cabeçalho da janela, as barras de ferramentas e o painel. Você realmente pode criar uma API que funcione em ambas, que não exija muita reescrita. Mas, nesse ponto, é tão lento quanto um aplicativo da web.

Então isso vale a pena? Depois de toda a dor, vale a pena cada minuto. Você pode abstrair a lógica e criar uma interface do usuário diferente para cada uma delas, e se estiver em qualquer lugar. O titânio permite fazer aplicações fluidas, que parecem rápidas. Você perde as poderosas habilidades de layout de cada plataforma, mas se você acha simples, as coisas podem ser feitas em um único idioma.

Por que não um aplicativo da web? No mercado básico, os telefones Android são terrivelmente lentos para gerar uma visualização na Web e consomem muita memória que você poderia estar usando para fazer uma lógica mais complexa.

Aqui está uma análise mais recente e aprofundada do Appcelerator e PhoneGap: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

E aqui está ainda mais detalhes sobre como eles diferem programaticamente: http://savagelook.com/blog/portfolio/phonegap-is-web-based-appcelerator-is-pure-javascript

mapkit nativo é suportado no Titanium

Tornar os widgets HTML5 que se parecem com os widgets do iphone é uma coisa, mas fazê-los funcionar igualmente bem é outra questão. O desempenho das animações html5 (mesmo as simples transições de exibição), rolando longas listas, a capacidade de resposta a gestos parecem pegajosos e bruscos. Um usuário do iPhone notará a diferença.

Existem também algumas diferenças nos tipos de gestos suportados por diferentes dispositivos, o que resulta em problemas de código e usabilidade específicos da plataforma.

Eu vou ficar com aplicativos nativos por enquanto, eu acho.

Rhomobile Rhodes ( http://rhomobile.com/products/rhodes ) é muito semelhante na abordagem ao PhoneGap, mas é a única estrutura com:

1. um padrão do Model View Controller (como a maioria das estruturas da web fornece)
2. um gerenciador de objetos relacionais
3. suporte para todos os smartphones populares (incluindo Windows Phone 7)
4. um serviço de desenvolvimento hospedado (não apenas uma compilação hospedada): http://rhohub.com
5. um depurador completo e emulador sem SDK no IDE RhoStudio
6. suporte para dados offline sincronizados

Para qualquer pessoa interessada no Titanium, devo dizer que eles não possuem uma documentação muito boa, faltando algumas classes, propriedades e métodos. Mas muita coisa está "documentada" em seu aplicativo de amostra, o KitchenSink, para que não seja tão ruim assim.

Meu entendimento do PhoneGap é que eles fornecem APIs Javascript para grande parte das APIs do iPhone.

O titânio parece mais fácil para um desenvolvedor de web. É um arquivo XML simples para criar um aplicativo TabView básico e, em seguida, tudo na área de conteúdo é controlado por HTML / JS. Eu também sei que o Titanium fornece algum acesso javascript a algumas das estruturas (particularmente acesso a informações de localização, identificação do telefone etc.).

ATUALIZAÇÃO: o Titanium adicionou a API do Google Maps na versão 0.8 de sua estrutura.

Você deve aprender o objetivo ce programar aplicativos nativos. Não confie nessas coisas que você acha que facilitarão a vida. A Apple garantiu que a maneira mais fácil é usar suas ferramentas e idioma nativos. Para suas 100 linhas de javascript, posso fazer o mesmo em 3 linhas de código ou nenhum código, dependendo do elemento. Assista a alguns tutoriais - se você entende de javascript, o objetivo c não é difícil. As soluções alternativas são miseráveis ​​e a Apple pode desconectá-lo a qualquer momento.

Das soluções mencionadas, nenhuma delas parece fornecer acesso direto à estrutura do MapKit introduzida no OS 3.0.

Como os widgets HTML do Google Maps não são tão bons quanto o MapKit (consulte o Google Latitude, por exemplo), é melhor você desenvolver um aplicativo nativo do Cocoa touch ou escolher uma solução que possa ser estendida para adicionar a integração ao MapKit. O PhoneGap é extensível dessa maneira (é de código aberto, por padrão) e algumas das outras soluções também podem ser.

edit: Titanium agora tem suporte para o MapKit

Eu tentei corona. Foi bom até que eu descobri que não suporta streaming de áudio mp3. Então, eu parei ali. Acho que se realmente quero ser desenvolvedor de aplicativos para iPhone, devo aprender sobre o obj. Tudo o que eu queria era criar um aplicativo com uma lista de estações de rádio e você clicar nelas para começar a tocar.