Comparação de abordagens para desenvolvimento de aplicativos móveis

Pós-graduação
MIT em Desenvolvimento Mobile
A WEB COMO UNIFICAÇÃO DAS
PLATAFORMAS MOBILE
Allan Marques Baptista
Coordenador: Thiago Cortat
Rio de Janeiro, maio de 2015

2
RESUMO
Este trabalho tem como objetivo fazer uma análise da atual situação das
plataformas móveis do ponto de vista tanto do desenvolvedor, quanto de negócios,
trazendo uma comparação técnica sobre cada uma das plataformas mais populares,
listando os benefícios e malefícios de cada abordagem e sugerindo uma opção mais
viável em termos de custo e tempo de desenvolvimento, utilizando a WEB e suas
tecnologias como uma interface de alto nível para os recursos nativos das
plataformas mobile. Se baseando em casos de uso do mundo real, este trabalho
explicita os problemas recorrentes nos projetos de desenvolvimento de aplicativos
para dispositivos móveis e tenta introduzir possíveis soluções utilizando uma
abordagem comumente chamada de multi-plataforma, que pode aproveitar ou não
de ferramentas e tecnologias já disponíveis na WEB, facilmente acessíveis e
assimiláveis. Finalizando, lista opções de ferramentas já consolidadas no
desenvolvimento de aplicações multi-plataforma, híbridas ou nativas, que tentam
solucionar justamente os problemas discutidos durante o discorrer deste trabalho,
deixando claros todos os caminhos disponíveis para evitar ao máximo o desperdício
de recursos e tempo em um projeto de aplicativo mobile.
Palavras-Chave: Dispositivos móveis, Desenvolvimento, Aplicativos, Android, iOS,
Windows Phone, Multi-Plataforma, Web

3
ABSTRACT
This paper has the goal of making an analysis of the current mobile
platforms situation, not only in the developer`s point of view, but in the business point
of view as well. Bringing a tecnical overview of each of the most popular platforms,
listing the pros and cons of each approach and suggesting a more viable option in
terms of cost and development time, using the web and it`s technologies as a high-
level interface for the native resources of mobile platforms. Based on real-world use
cases, this paper explains the recurrent problems in mobile application development
projects and tries to introduce possible solutions using a common approach called
cross-platform, which can make use or not, of accessible tools and technologies
already available on the web. Finally, it lists some tool options, that are already
consolidated in cross-platform applications development, hybrid or native, and tries to
solve the problems discussed during the discourse of this paper, making clear all
available paths in order to minimize the waste of resources and time in a mobile
application project.
Keywords: Mobile devices, Development, Apps, Android, iOS, Windows Phone,
Cross-Platform, Web

4
SUMÁRIO
Resumo ...................................................................................................................... 2
Abstract...................................................................................................................... 3
1 Introdução............................................................................................................... 5
1.1 Mobile não é o futuro, é o presente....................................................................... 5
1.2 A ascensão e queda das startups ......................................................................... 7
1.3 A abordagem multi-plataforma e a WEB............................................................. 11
2 Comparando as abordagens............................................................................... 14
2.1 Aplicativos nativos: vantagens ............................................................................ 15
2.2 Aplicativos nativos: desvantagens....................................................................... 16
2.3 Aplicativos multi-plataforma/hibridos: vantagens ................................................ 18
2.4 Aplicativos multi-plataforma/hibridos: desvantagens........................................... 19
2.5 Por que a abordagem multi-plataforma/hibrida é o ideal?................................... 19
3 Ferramentas para desenvolvimento de aplicativos multi-plataforma............. 21
3.1 Apache Cordova.................................................................................................. 22
3.2 Appcelerator Titanium ......................................................................................... 29
3.3 Intel XDK ............................................................................................................. 35
3.4 Sencha Touch ..................................................................................................... 40
3.5 NativeScript ......................................................................................................... 45
3.6 React Native........................................................................................................ 50
4 Conclusão ............................................................................................................. 57
Referências .............................................................................................................. 59

5
1 INTRODUÇÃO
Este trabalho irá tentar explicitar o quanto ferramentas oriundas do
desenvolvimento WEB têm influenciado de maneira positiva no desenvolvimento de
aplicativos mobile e o porque esta abordagem pode a vir se tornar a maneira mais
popular de desenvolver aplicativos, devido a sua facilidade, rapidez, baixo custo e
manutenibilidade. Também serão abordados cases e exemplos das ferramentas
citadas aqui e como seus benefícios podem ajudar a baratear o custo do
desenvolvimento de um aplicativo, se tornando uma ótima maneira de validar uma
ideia e ajudando uma pequena/media empresa, startup ou desenvolvedor autônomo
à entrar no disputado mundo dos apps.
1.1 MOBILE NÃO É O FUTURO, É O PRESENTE
A plataforma mobile já deixou de ser coadjuvante no atual contexto
tecnológico e continua a ganhar espaço, sendo o único aparelho tecnológico até
hoje com a possibilidade de ser acessível por toda a população terrestre.
Há pouquíssimo tempo atrás pensávamos em smartphones como a “segunda
tela”, ou seja, um aparelho secundário que complementava a experiência do seu
irmão maior, o laptop ou desktop PC. Era um mundo que visitávamos somente
quando não tínhamos um PC próximo, porém o comportamento das pessoas
mudaram muito, em pouquíssimo tempo. O tempo que passamos utilizando um
smartphone já ultrapassou o tempo que passamos em frente do PC ou da televisão.

6
De acordo com o um estudo da Millward Brown, nos EUA, as pessoas
passam 151 minutos por dia utilizando o smartphone contra 147 minutos diários na
frente da televisão. Limitando o escopo somente para o Brasil, os números são
ainda mais impressionantes, os brasileiros gastam em média 149 minutos por dia
utilizando o smartphone, enquanto passamos somente 113 minutos diários
assistindo televisão.
A mesma pesquisa também revela que 34% da utilização de dispositivos
eletrônicos como smartphones, tables, PCs e TVs, são feitos de forma simultânea.
Comportamento que aumentou muito a necessidade de uma boa experiência cross-
device, ou seja, uma experiência consistente para o usuário que utiliza aquele
mesmo serviço ou produto em múltiplas telas.
Proporção de tempo que passamos utilizando cada dispositivo. (Fonte:
http://www.millwardbrown.com/adreaction/2014)

7
Com esses números fica fácil de perceber como o mobile sendo o principal
canal de aquisição e retenção de clientes não é mais o futuro, e sim o presente, e as
empresas que não acompanharem esta tendência pode ficar para trás muito rápido
e alcançar as empresas que às ultrapassaram pode se revelar improvável.
1.2 A ASCENSÃO E QUEDA DAS STARTUPS
O contexto atual na área de tecnologia já está claro há algum tempo, qualquer
empresa que almeja continuar crescendo, seja ela pequena, média ou grande, deve
ter algum tipo de presença no mundo mobile, seja por meio de sites responsivos,
sites exclusivamente mobile ou aplicativos nativos. Sobre qual abordagem a
empresa deve tomar, depende muito do segmento, objetivo e aplicação, mas já é
comum ver as três abordagens serem utilizadas simultaneamente em grandes
produtos como Twitter, Pinterest e Gmail.
Além da necessidade de produtos já consolidados estenderem suas
presenças para o mobile, há também uma quantidade enorme de novas minúsculas
empresas que tentam validar suas ideias utilizando o mobile como escopo principal.
Essas empresas, comumente chamadas de startups, têm surgido no mundo todo,
incentivadas pelo sucesso de grandes cases como WhatsApp, Instagram e Vine.
Cases de sucesso que começaram como startups de pouquíssimos integrantes com
uma simples e inovadora ideia, e que em pouco tempo depois acabaram sendo
compradas por centenas de milhões, ou até dezenas de bilhões de dólares. Graças
à esses grandes cases, em 2015 o número de startups criadas no primeiro semestre
aumentou 300% em relação ao ano anterior.
Mas chegar no patamar dessas pequenas startups que se tornaram enormes
empresas, pode se revelar uma tarefa árdua. Segundo a revista Fortune, nove entre
dez startups acabam falindo antes de alcançar este objetivo, enterrando com ela
todo o esforço feito pelos envolvidos. A revista ainda lista os 20 principais motivos
pelo qual isso acontece.

8
São muitos motivos para se atentar, o que torna claro o quanto qualquer
pequeno erro nesta fase pode representar a falha da startup. Segundo o gráfico
acima o segundo maior motivo é o término do dinheiro para manter a pequena
empresa respirando, o que torna crucial para uma startup, que almeja chegar ao
patamar dos “peixes grandes”, planejar bastante seus custos na hora de validar uma
ideia que pode ou não ter valor no mercado.
As 20 razões pelas quais startups vem a falir, de acordo com seus fundadores (Fonte:
http://fortune.com/2014/09/25/why-startups-fail-according-to-their-founders/)

9
O primeiro grande motivo para a “morte” das startups é a falta de valor no
mercado, mas isso também pode ser amenizado com uma boa gestão de custos
nesta etapa tão crucial, afinal se a ideia se revelar não-produtiva, mas ainda houver
dinheiro em caixa para manter a empresa em funcionamento é comum acontecer o
que chamamos de “pivot”, uma palavra bastante utilizada no mundo das startups
para representar a adaptação de uma ideia para que ganhe valor de mercado. Por
exemplo, o Paypal começou como uma empresa de troca de dinheiro virtual entre
dispositivos Palm, mas com o tempo perceberam que seu serviço tinha mais
potencial nos micropagamentos e na troca de dinheiro via web, e agora o Paypal é
consolidado o maior serviço de troca de pagamentos online do mundo.
Quando percebemos que qualquer erro na gestão de custos pode levar à
extinção da startup, fica claro que toda e qualquer forma econômica de validar uma
ideia deve ser tratada como ótima opção nesta fase.
Voltando para o escopo mobile, que é o foco deste trabalho, existem grandes
diferenças entre os caminhos que uma grande e consolidada empresa, e uma
pequena startup devem seguir para serem bem sucedidos ao introduzir seu produto
ou serviço no competitivo mundo das telas pequenas.
Uma empresa consolidada dispõe dos recursos necessários para atacar em
todas as frentes (site responsivo, Web App ou Apps de múltiplas plataformas) e
medir o sucesso de cada uma delas, iniciando um ciclo de implementação, medição,
aprendizado e aprimoramento em todas elas.
Uma pequena startup possui recursos muito limitados e precisam cuidar muito
bem deles, então a abordagem de validar a ideia economizando o máximo possível
de recursos é o ideal. Mas existem várias dificuldades ao tentar validar uma ideia de
maneira barata no contexto mobile, algumas delas são:
• Para atingir todo o público mobile é necessário atender a múltiplas
plataformas
• Para um produto passar credibilidade e qualidade, devem respeitar as
particularidades visuais de cada plataforma
• Tempo de concepção multiplicado por cada plataforma atendida

10
• Custo de concepção multiplicado por cada plataforma atendida
• Falta de mão de obra qualificada
Deixando claro que o fato de ter de atender à mais de uma plataforma é o
principal motivo de aumento de custos na durante o processo de desenvolvimento
de um aplicativo nativo de smartphone. Este fato torna o mundo mobile em um mar
perigoso para uma pequena startup estar.
Ficando explicito que um dos principais motivos de uma startup falhar é a
pobre gestão de custos ao validar uma ideia, a metodologia Lean Startup trouxe a
abordagem de validar essas ideias com versões simplificadas do produto de maneira
que o custo, tempo e risco da implementação dele seja bem menor, tornando
mínimo o ciclo de implementá-lo, medir seu sucesso, aprender com os resultados e
aprimorá-lo. Esta versão simplificada do produto é chamada de MVP, acrônimo para
Minimium Viable Product que representa o produto minimamente viável para validar
uma ideia.
Ciclo de desenvolvimento sugerido pela metodologia Lean Startup (Fonte:
http://theleanstartup.com/principles)

11
Tendo em vista o que a metodologia Lean Startup prega fica claro que é uma
abordagem perfeita para pequenas startups, mas como podemos aplicá-la no
contexto mobile? Já que devemos ter em vista várias plataformas para maior
alcance, como podemos desenvolver um MVP que atenda todas as plataformas e
ainda sim ser simples, rápido e barato de implementar?
1.3 A ABORDAGEM MULTI-PLATAFORMA E A WEB
As plataformas mobile mais amplamente difundidas atualmente são duas:
Android (da Google, corresponde à 78% do mercado de smartphones) e iOS (da
Apple, corresponde à 18.3% do mercado de smartphones). Existem também
plataformas que alcançam bem menos pessoas mas ainda sim possuem seu lugar
no mercado e devem ser levadas em consideração, são elas: Windows Phone (da
Microsoft, corresponde à 2.7% do mercado de smartphones) e BlackBerry OS (da
Blackberry, corresponde 0.3% do mercado de smartphones). O gráfico abaixo
demonstra a mudança dessas estatísticas ao longo dos trimestres dos últimos três
anos.

12
Sabendo que há pelo menos quatro plataformas para serem atacadas,
existem várias abordagens para diminuir os custos de um projeto de aplicativo
mobile. Uma delas seria ignorar as plataformas menos populares no início e
somente atacar as outras plataformas assim que a ideia sendo validada se revelar
valiosa o bastante para continuar sua implementação. Embora essa estratégia seja
ótima para diminuir os custos de um projeto, uma grande massa de usuários em
potencial estão sendo ignoradas junto com as essas plataformas, o que pode
diminuir bastante as chances de sucesso na introdução de uma nova ideia no
mercado de aplicativos mobile.
E se existisse uma abordagem que tornasse possível atacar todas as
plataformas possíveis e ainda ter um custo menor que a abordagem descrita acima?
Essa abordagem existe, ela é conhecida como multi-plataforma.
A abordagem multi-plataforma surgiu da necessidade de atender à todas as
plataformas mobile existentes de forma mais barata, rápida e manutenível do que
criar e manter um projeto separado para cada plataforma que deseja atingir. Essa
Market share mundial de plataformas de smartphone (Fonte:
http://www.idc.com/prodserv/smartphone-os-market-share.jsp)

13
abordagem torna possível manter somente um projeto, uma base de código, e por
meio de algum tipo de ferramenta de build e compilação, esta base código é portada
para cada plataforma escolhida, provendo uma experiência consistente em todas
elas.
Já existem dezenas de ferramentas que implementam a abordagem multi-
plataforma, muitas delas já consolidadas no mercado, e todas elas implementam
esta abordagem de maneiras diferentes para justificar sua existência.
Algumas ferramentas utilizam de linguagens como Java e C# para abstrair e
unificar as APIs similares de cada plataforma, resultando em só uma API, só um
framework, que é encarregado de compilar para sua versão nativa de cada
plataforma. Outras utilizam uma abordagem mais simples, que consiste em utilizar
um componente de WebView, que funciona como um navegador “embarcado” na
aplicação que irá renderizar telas criadas com as tecnologias web mais conhecidas:
HTML, CSS e Javascript. Além de fornecer uma API, geralmente via Javascript, para
comunicação com as características nativas que todo dispositivo mobile oferece,
como GPS, contatos, armazenamento local, acelerômetro e giroscópio, vibração e
até bluetooth.
A abordagem multi-plataforma utilizando ferramentas web já está muito
difundida entre os desenvolvedores que já possuem experiência com a tecnologias
web, pelo fato de não precisarem abdicar de todas suas habilidades e aprenderem
um novo ecossistema de ferramentas, somente para desenvolver um aplicativo
mobile nativo. Várias grandes empresas também aderiram esta abordagem para
melhor utilização de seus recursos na validação de um produto como aplicativo de
smartphones.
Este trabalho irá apresentar cases de sucesso e exemplos utilizando a
abordagem multi-plataforma, utilizando ferramentas web já consolidadas como
espinha dorsal de sua implementação. Serão apresentadas as ferramentas mais
populares que implementam essa abordagem, suas vantagens e desvantagens, e
como a adoção destas ferramentas em grande escala está mudando o mundo do
desenvolvimento de aplicativos nativos para sempre.

14
2 COMPARANDO AS ABORDAGENS
Até então foram citadas três abordagens (sites responsivos/web apps, apps
nativos e apps multi-plataforma/híbridos) para desenvolvimento de aplicações
mobile, embora este trabalho foque em somente um deles, é preciso listar as
diferenças entre cada abordagem e o porquê da solução proposta aqui, poder ser
uma abordagem melhor dependendo do escopo.
Na tabela abaixo é feita uma comparação entre as abordagens de ao longo
de vários items.
App nativo
Web app / site
responsivo
App multi-plataforma
/ hibrido
Skill / ferramentas
necessárias para
desenvolvimento em
várias plataformas
• Objective-C /
Swift
• Java
• C++
• C#
• HTML
• CSS
• Javascript
• Linguagem de
back-end
(nodeJS, PHP,
Ruby...)
• HTML
• CSS
• Javascript
• Linguagem de
back-end
(nodeJS, PHP,
Ruby...)
• Framework de
desenvolvimen
to mobile
Apps necessários
para atingir todas as
plataformas mais
populares
4 1 1
Instalado no
dispositivo?
Sim Não Sim
Distribuição App Store/Market Internet App Store/Market
Integração com
dispositivo
Integração total:
(câmera, microfone,
GPS, giroscópio,
acelerômetro, upload
de arquivos, contatos,
bluetooth)
Integração parcial:
(GPS, giroscópio,
de arquivos)
Integração total:
(câmera, microfone,
GPS, giroscópio,
de arquivos, contatos,
bluetooth)

15
Na comparação acima fica nítida que a abordagem multi-plataforma
utilizando ferramentas web une as caraterísticas da aplicação nativa com as
características do web app, formando um “híbrido” que reúne as forças das outras
abordagens (por isso são chamados de Aplicativos Híbridos). Mas ainda assim, ao
desenvolver aplicativos mobile, há vantagens e desvantagens de seguir cada
abordagem, e é imprescindível que elas sejam levadas em consideração ao iniciar
um projeto, pois cada abordagem somente é adequada para um caso, se este
atende os requisitos que a abordagem necessita.
2.1 APLICATIVOS NATIVOS: VANTAGENS
Melhor performance gráfica possível: Quando criados utilizando a
linguagem nativa do dispositivo, os aplicativos oferecem a melhor performance
gráfica e animações possíveis. Se o aplicativo necessita ter grande performance
gráfica, como um jogo, aplicativos escritos com sua linguagem nativa são sua
melhor opção.
Distribuição nas lojas de aplicativos: Aplicativos nativos são distribuídos
pelas lojas e marketplaces de aplicativos da sua plataforma. Distribuição em lojas de
aplicativos é essencial se o aplicativo necessita ser acessível para consumidores em
larga escala, ou em aplicativos que precisam ser vendidos. É importante notar que
aplicativos híbridos também podem ser distribuídos em lojas de aplicativos.
Integração com o dispositivo: Aplicativos nativos possuem total acesso ao
hardware do dispositivo como seu sensor GPS, lista de contatos, câmera, microfone,
giroscópio, acelerômetro e bluetooth. Essas capacidades são essenciais para
aplicativos que necessitam de informações do dispositivo como localização
geográfica ou posição/deslocamento do dispositivo. É importante notar que
aplicativos híbridos também possuem total integração com essas capacidades do
dispositivo.

16
2.2 APLICATIVOS NATIVOS: DESVANTAGENS
Sem portabilidade: Como cada aplicação nativa roda somente em uma
plataforma, deve-se tomar a decisão de construir o aplicativo para uma só
plataforma ou para várias. Infelizmente não há respostas fáceis. Como ilustrado pela
imagem abaixo, o panorama mobile possui quatro consolidadas plataformas de
smartphones e quatro consolidadas plataformas de tablets. Construindo um
aplicativo para uma só plataforma, exclui outras sete, já construindo para todas as
plataformas necessita de uma significante quantidade de tempo e recursos.
Instabilidade de plataforma: O panorama das plataformas mobile é
notoriamente instável. Uma plataforma popular hoje pode desaparecer em alguns
anos. Por exemplo, ambos Blackberry e Palm dominaram a indústria mobile há
somente cinco anos atrás. Hoje, Blackberry está lutando para continuar viva e Palm
não existe mais. Quando se escolhe a abordagem nativa sempre há o risco de
desperdício de tempo e dinheiro, construindo um aplicativo para uma plataforma que
pode não durar muito tempo.
Custo de desenvolvimento: Enquanto o custo do desenvolvimento de
aplicativos nativos varia de acordo com a complexidade do aplicativo, é facilmente a
(Fonte: http://www.mrc-productivity.com/)

17
abordagem mais cara e que exige mais tempo para ser seguida. Por exemplo, a
Forrester Research, em uma de suas pesquisas, estima que aplicativos nativos
necessitam de pelo menos seis meses de trabalho e custam entre $20.000 e
$150.000 dependendo da sua complexidade. A mesma pesquisa resultou em uma
tabela de custos bem desanimadora para pequenos empreendedores.
Custo de um
aplicativo
Número de
aplicativos
necessários
Custo total
Aplicativo de uma
plataforma
$20.000 - $150.000 1 $20.000 - $150.000
Aplicativo de
várias
plataformas
$20.000 - $150.000 4 $80.000 - $600.000
Aplicativo de
varias
plataformas +
aplicativos de
tablets
$20.000 - $150.000 8
$160.000 -
$1.200.000
No brasil, segundo uma pesquisa feita pela Esauce, “Um aplicativo de celular
de pequeno porte consome de 150 a 500 horas para ser desenvolvido. Tem o custo
aproximado entre R$ 10 mil e R$ 60 mil. Aplicativos mais complexos podem custar
entre R$ 100 mil e R$ 200 mil.” (esauce.com.br, 2014)
Tempo de desenvolvimento: Como mencionado acima, a Forrester
Research estima que um único aplicativo nativo necessita de seis meses de tempo
de desenvolvimento. Quando desenvolvendo aplicativos para mais de uma
plataforma, o tempo requerido aumenta dependendo do número de desenvolvedores
necessários e complexidade da aplicação. Por exemplo, utilizando somente um
desenvolvedor para desenvolvimento de aplicativos para várias plataformas de

18
smartphones aumenta o tempo de desenvolvimento para dois anos (4 aplicativos x 6
meses para cada). Porém, estimação de tempo de desenvolvimento quando
utilizando múltiplos desenvolvedores não é nada fácil. Por exemplo, se uma startup
utiliza quatro desenvolvedores diferentes para cada plataforma de smartphone,
estes irão receber quatro designs diferentes da aplicação. Como qualquer
gerenciador de projetos sabe, garantir que múltiplos aplicativos, desenvolvidos por
múltiplos desenvolvedores, tenham comportamentos e experiências idênticas é uma
tarefa que consume bastante tempo.
Custo de manutenção: Enquanto todas as aplicações necessitam de
manutenções e atualizações regulares, aplicativos nativos necessitam de muito mais
manutenções futuras quando comparamos com as outras abordagens de
desenvolvimento. Além da manutenção regular, aplicativos nativos também podem
ter que ser atualizados sempre que a plataforma é atualizada. Adicionalmente,
quando construindo aplicativos nativos para várias plataformas, também é
necessário manter estes aplicativos em várias plataformas, ou sejas, cada pequena
mudança em um aplicativo nativo de smartphone e tablet que possui versão em
todas as plataformas mais populares pode ter que ser replicada até oito vezes, uma
vez para cada plataforma.
2.3 APLICATIVOS MULTI-PLATAFORMA/HIBRIDOS: VANTAGENS
Look-and-feel nativo (sem o custo do nativo): Como aplicativos nativos,
aplicativos híbridos também são instalados no dispositivo e funcionam como uma
típica aplicação nativa. Esses atributos nativos fazem com que o aplicativo hibrido se
torne praticamente indistinguível de aplicativos nativos. Na verdade, muitas pessoas
não sabem que aplicativos “nativos” populares como Linkedin, Foursquare, e Twitter
são na verdade aplicativos híbridos.
Integração com o dispositivo: Como mencionado acima, aplicativos
híbridos funcionam exatamente como aplicativos nativos, então possuem total
acesso à capacidades nativas do dispositivo, sem exceção.

19
Distribuição nas lojas de aplicativos: Novamente aqui, como aplicativos
nativos, aplicativos híbridos podem ser distribuídos nas lojas de aplicativos da
mesma maneira, então “win-win".
Desenvolvimento multi-plataforma de baixo custo: Como geralmente é
necessário uma base de código para desenvolver e manter aplicativos para várias
plataformas, o custo e o tempo necessário são bem menores quando comparados
com a abordagem nativa. Por exemplo, se uma startup já tem um web app, o tempo
e custo para portar este aplicativo como aplicativo nativo são quase nulos já que
toda base de código pode ser reutilizada. Adicionalmente, todo conhecimento dos
desenvolvedores web podem ser aproveitados no desenvolvimento de um aplicativo
hibrido, o que diminui o custo na perspectiva de que não será preciso alocar tempo
para aprender uma nova plataforma de desenvolvimento ou gastar dinheiro
contratando um desenvolvedor que possui proficiência naquela plataforma.
2.4 APLICATIVOS MULTI-PLATAFORMA/HIBRIDOS: DESVANTAGENS
Performance gráfica limitada: Apesar da sua aparência nativa, aplicativos
nativos possuem as mesmas capacidades gráficas que web apps. Embora na
maioria dos casos esta diferença na performance é negligenciável, quando o
aplicativo necessita de grande capacidades gráficas, como games, a abordagem
ideal é a nativa.
Necessita familiaridade com algum framework mobile hibrido:
Transformar um web app em um aplicativo mobile hibrido necessita do
conhecimento da ferramenta/framework mobile hibrido. Mesmo sendo muito mais
simples que o desenvolvimento nativo, a abordagem hibrida adiciona um nível de
complexidade ao processo de desenvolvimento do web app mobile, já que os
desenvolvedores necessitam se familiarizar com o framework hibrido.
2.5 POR QUE A ABORDAGEM MULTI-PLATAFORMA/HIBRIDA É O IDEAL?

20
A não ser que esteja num escopo onde o custo e tempo de desenvolvimento
não seja um problema (o que geralmente é improvável) ou que o produto final
necessite de magnifica performance no mobile (como games, por exemplo), não há
valor de negócios em seguir a abordagem nativa para validar um ideia ou ao iniciar
um projeto.
Após de levar em consideração os pontos levantados neste capitulo e os
conceitos que o Lean Startup prega, fica claro que a melhor maneira de desenvolver
um MVP no escopo mobile é seguir a abordagem multi-plataforma/hibrida. Ao fazer
isso, agrega-se os benefícios dos aplicativos nativos com os benefícios da web,
minimiza-se ao máximo suas desvantagens e ainda sim, com o menor custo
possível quando comparando com as outras abordagens.
Como a abordagem hibrida no desenvolvimento de aplicativos mobile nativos
possui maior valor de negócios, novas ferramentas que implementam essa
abordagem surgem todo dia, logo o principal problema se torna decidir qual
ferramenta é a ideal para o escopo da ideia que deseja validar, mas comparado à
problemas que podem extinguir uma startup embrionária, este é o menor deles.

21
3 FERRAMENTAS PARA DESENVOLVIMENTO DE APLICATIVOS MULTI-
PLATAFORMA / HIBRIDOS
Dentre todas as opções disponíveis para desenvolvimento de aplicativos
multi-plataforma/híbridos há aquelas ferramentas que se destacam, embora isso não
signifique que as ferramentas menos populares não devem ser levadas em
consideração. Além disso, o panorama de desenvolvimento é um muito volátil, é um
mundo em constante movimento, em que a todo momento novas ferramentas
nascem e outras se tornam obsoletas, portanto a escolha deve levar em
consideração vários pontos importantes como:
• Escopo do problema a ser solucionado;
• Custo (nem todas as ferramentas são gratuitas ou open-source);
• Tamanho da comunidade (geralmente quanto maior a comunidade em torno
da ferramenta, mais informação sobre ela pode ser encontrada online);
• Qualidade do suporte e documentação;
• Habilidades já dominadas pelos desenvolvedores da equipe;
• Curva de aprendizado;
• Velocidade de desenvolvimento e facilidade de manutenção.
Sabendo como avaliar as opções, falta saber que opções avaliar. Neste
capitulo serão apresentadas as opções mais populares, serão listadas suas
vantagens e desvantagens e e seus cases de sucesso.
As ferramentas que serão apresentadas aqui são:
• Apache Cordova (Adobe Phonegap, Ionic)
• Appcelerator Titanium
• Intel XDK
• Sencha Touch
• NativeScript
• React Native

22
3.1 APACHE CORDOVA
Antes chamado de Phonegap, projeto open-source iniciado e mantido pela
empresa Nitobi que foi comprada pela poderosa Adobe, e por ter um grande número
de contribuidores (inclusive de grandes empresas como IBM), foi incluída no Apache
Software Foundation.
No inicio, o nome do projeto foi alterado para “Apache Callback”, mas depois
renomeado para “Apache Cordova” (nome de uma rua onde os escritórios da Nitobi
se situavam). A mudança de nome foi necessária pois, diferentemente do projeto, a
marca Phonegap fazia parte da compra da Nitobi pela Adobe.
Hoje Phonegap é somente uma distribuição “comercial” do Apache Cordova.
Para ilustrar melhor, Brian Leraux (um dos criadores do Phonegap) fez a analogia de
que “o Apache cordova é para o Phonegap o que o Webkit é para o Chrome ou
Safari” (LERAUX, BRIAN, 2011).
Como definido pelo própria documentação, o Apache Cordova é um conjunto
de APIs que permite que o desenvolvedor acesse funções nativas do dispositivo,
como câmera e acelerômetro, via Javascript. Quando combinado com um framework
de interfaces de usuário como JQuery Mobile, Dojo Mobile ou Sencha Touch,
permite que um aplicativo de smartphone ou tablet seja desenvolvido utilizando
apenas HTML, CSS e Javascript.
Enquanto utilizando as APIs do Apache Cordova, um aplicativo pode ser
construído sem a necessidade do desenvolvedor escrever sequer uma linha de
código nativo (Java, Objecttive-C, Swift, C#, etc...). Ao invés disso, tecnologias web
são utilizadas e servidas localmente, direto do aplicativo (normalmente não em um
servidor HTTP remoto).
Devido ao fato das APIs Javascript serem consistentes em múltiplas
plataformas de dispositivos e serem construídas em cima dos padrões web, o
aplicativo se torna portável para outras plataformas, com poucas ou mesmo
nenhuma mudança.

23
O Apache Cordova provê uma série de bibliotecas Javascript uniformes que
abstraem o código nativo especifico de cada plataforma e está disponível nas
plataformas: iOS, Android, Windows Phone, Blackberry, Palm WebOS, Bada e
Symbian.
Construído desde o início com o mindset em extensibilidade e plugabilidade, o
Apache Cordova provê um sistema simples de desenvolvimento, consumo e
contruibuição de plug-ins. Com exceção do Core, todas as APIs de acesso às
capacidades nativas do dispositivo só estarão disponíveis assim que seu plug-in
equivalente estive instalado no projeto. Por exemplo, caso seja necessário o acesso
à câmera do dispositivo, será necessário instalar o plug-in de câmera no projeto
utilizando a ferramenta de interface de linha de comando (CLI) do Apache Cordova.
Após o plug-in ser instalado, a API de acesso a câmera do dispositivo estará
disponível para o desenvolvedor via Javascript.
A maior parte da utilização do Apache Cordova é feita a partir de sua
ferramenta de CLI. Como esta ferramenta é baseada em Node.js, e distribuída via
NPM (Node Package Manager), é necessário como pré-requisito que o usuário
instale o Node.js e um cliente Git (o mais utilizado gerenciador de versões). Após a
instalação destas ferramentas, basta utilizar o comando “sudo npm install –g
cordova” (OS X ou Linux) ou “npm install –g cordova” (Windows), e a ferramenta de
CLI do Apache Cordova estará pronta para ser utilizada.
Após a instalação da ferramenta de CLI do Apache Cordova o próximo passo
é criar um projeto do aplicativo, que pode ser facilmente feito a partir do comando
“cordova create $DIR_DO_APP $ID_DO_APP $NOME_DO_APP“ na interface de
linha de comandos do sistema operacional sendo utilizado. Com isso será criado um
projeto de aplicativo com o nome de “$NOME_DO_APP”, identificador de aplicativo
“$ID_DO_APP”, na pasta “$DIR_DO_APP”.

24
A estrutura de arquivos do Apache Cordova foi pensada de maneira que
qualquer desenvolvedor que tenha familiaridade com as mais conhecidas ferramenta
web de front-end se sinta à vontade em seu ambiente. A estrutura de um projeto de
aplicativo do Apache Cordova é composta basicamente por quatro pastas de
arquivos e um arquivo “config.xml” na raíz do projeto. Abaixo uma breve descrição
sobre cada parte da estrutura:
• config.xml: Arquivo de configuração XML global, agnóstico de plataforma,
que controla vários aspectos de comportamento do aplicativo (como
ícones, splash-screen, customizações de plataforma e etc...);
• hooks/: Pasta onde são armazenados scripts que podem ser adicionados
por plug-ins, pela aplicação ou scripts de build, para customizar comandos
do Apache Cordova;
• platforms/: Pasta onde ficam armazenados os projetos de código nativos
de plug-ins e da própria aplicação. Este código quando compilado que
origina o executável do aplicativo que poderá então ser distribuído nas
lojas de aplicativos;
• plugins/: Pasta onde ficam armazenados os plug-ins instalados no
projeto;
Estrutura de arquivos de um projeto de aplicativo do Apache Cordova

25
• www/: Pasta onde ficam os principais arquivos do aplicativo e onde o
desenvolvedor construirá a interface para ser consumida pelo usuário
mobile. O arquivo index.html contido aqui é o ponto de entrada para o
aplicativo.
Apesar de ser possível testar o aplicativo direto do navegador do desktop ou
notebook sendo utilizado como maquina de desenvolvimento, o que torna o
desenvolvimento mobile bem mais dinâmico (sem precisar compilar aplicação
sempre que fizer uma modificação), também é possível testar a aplicação direto de
um dispositivo smartphone/tablet, ou simplesmente de um simulador da plataforma
desejada.
O comando “cordova platform add $PLATAFORMA” adiciona um projeto de
código nativo da plataforma escolhida, que permite compilar o aplicativo para aquela
plataforma. Executando o comando “cordova build $PLATAFORMA”, o Apache
Cordova executa o build que compila o projeto nativo da plataforma escolhida e cria
o pacote que pode ser enviado para loja de aplicativos para ser baixado pelos
usuários finais. Por fim, o comando “cordova run $PLATAFORMA” executa o
aplicativo em um dispositivo conectado em modo de desenvolvedor ou no simulador
daquela plataforma, se estiver disponível.

26
Como falado mais acima, o Apache Cordova somente revela APIs de
comunicação com as APIs nativas do dispositivo, deixando o desenvolvedor com a
total liberdade de utilizar qualquer framework de interface de usuários ou conjunto de
bibliotecas em que ele tiver mais proficiência. Esta flexibilidade fez que com que
vários frameworks web exclusivos para dispositivos mobile tenham nascido com sua
arquitetura pensada para total interoperabilidade com as APIs que o Apache
Cordova fornece. Estes frameworks ajudam a abstrair grande parte das
complexidades existentes ao criar uma aplicação web voltada para o mobile,
deixando o desenvolvedor focar no que realmente importa. Dentre os vários
frameworks e bibliotecas existentes, há os mais aceitos pela comunidade e com a
maior gama de cases de sucesso, alguns deles são:
• Ionic Framework (Baseado no framework Javascript AngularJS da Google)
• Onsen UI (Pode ser utilizado com Angular JS ou JQuery)
• JQuery Mobile (Baseado em JQuery e JQuery UI)
Aplicativo do Apache Cordova simples, rodando nos simuladores de iOS e Android

27
• Reapp (Baseado no framework de UI ReactJS do Facebook
• Sencha Touch (Abordado aqui com mais profundidade mais abaixo)
• Famo.us (Baseado em canvas HTML5)
Como foi dito acima, há vários cases de sucesso que utilizaram o Apache
Cordova como espinha dorsal do seu desenvolvimento de aplicativos mobile,
entre eles:
• Wikipedia: O aplicativo oficial do Wikipedia foi construído utilizando o
Cordova/Phonegap;
• Facebook: Utiliza uma versão alterada do Apache Cordova na sua API
mobile;
• Salesforce: Utiliza uma versão alterada do Apache Cordova na dua API
mobile;
• IBM: A plataforma IBM/Worklight de desenvolvimento mobile é baseada em
cima do Apache Cordova;
• Microsoft: Utiliza a plataforma Apache Cordova para criar alguns aplicativos
multi-plataforma, além de contribuir para o projeto (especificamente para
plataforma Windows Phone);
• Adobe: Como dito acima, a Adobe é atual mantenedora da maior distribuição
do Apache Cordova existente, o Phonegap. A Adobe possui todo um
ecossistema de criação de aplicativos utilizando o Phonegap.

28
O Apache Cordova é uma das maiores e mais consolidadas ferramentas de
desenvolvimento multi-plataforma utilizando o ecossistema web como sua base para
criação de interfaces de usuário para aplicativos mobile. Porém possui alguns
pontos ruins que devem ser salientados. Por exemplo, sua documentação é bem
“rasa” e nada intuitiva, obrigando o desenvolvedor a procurar a solução de possíveis
problemas em fontes menos confiáveis como blogs ou fóruns. Outra desvantagem é
que o Apache Cordova é atualizado com uma frequência relativamente baixa, o que
torna o acesso à novas capacidades nativas e soluções de bugs bastante
burocrático.
Concluindo, o Apache Cordova é uma ótima opção para projetos que
necessitam de grande flexibilidade no aproveitamento de conhecimentos prévios de
ferramentas web dos desenvolvedores envolvidos. Possui vários plug-ins que
aceleram o desenvolvimento e consequentemente diminuem o custo, têm uma das
maiores comunidades em torno dela, vários casos de uso e exemplos para serem
estudados, e por ultimo, mas não menos importante, é open-source. Para sempre.
Aplicativos construídos com Apache Cordova/Phonegap. (Fonte:
http://phonegap.com/app/feature/)

29
3.2 APPCELERATOR TITANIUM
No ano de 2008, quando foi introduzido, o Titanium tinha como foco principal
o desenvolvimento multi-plataforma de aplicações desktop e era frequentemente
comparado ao Adobe Air, que tinha o mesmo propósito. Mas em 2009 foi adicionado
o suporte para desenvolver aplicações mobile para Android e iPhone, que foi
ganhando mais e mais importância e visibilidade, quando em 2012, o Titanium
Desktop foi separado e se transformou em um projeto mantido pela comunidade
chamado TideSDK. Durante os anos seguintes o Titanium Mobile SDK foi evoluindo
e ganhando suporte para cada vez mais plataformas como Blackberry, Tizen,
Tablets Android e iOS, e Windows Phone.
Em 2013, Jeff Haynie, CEO da Appcelerator (empresa criadora e
mantenedora do Titanium) anunciou que a tinham iniciado um projeto para
reescrever o Titanium SDK em Javascript para melhorias de performance e também
para tornar o acesso ao código de baixo nível do SDK mais simples para
desenvolvedores. Em um artigo ele escreveu: “Nós acreditamos que Javascript deve
ser a linguagem correta para construir o Titanium SDK em sí, e não somente
aplicativos desenvolvidos em cima do Titanium” (HAYNIE, JEFF, 2013). Neste ano,
segundo a Business Insider, estimava-se que 10% dos smartphones do mundo todo
estariam rodando aplicativos construídos com o Titanium, além disso, já possuía
uma base de mais de 500.000 desenvolvedores cadastrados.
O Appcelerator Titanium é um framework open-source, também licenciado
pela Apache, que permite a criação de aplicativos mobile multi-plataforma, e oferece
suporte para as plataformas Android, iOS, Windows Phone, Blackberry OS e Tizen,
com somente uma base de código em Javascript. O componente principal do
Titanium é o Titanium SDK, porém a Appcelerator desenvolveu também o Alloy, um
framework que segue o paradigma Modelo-Interface-Controladora (MVC) baseado
no Titanium que ajuda a acelerar ainda mais o desenvolvimento de aplicativos que
podem ser rodados nas mais populares plataformas mobile. Também incluído no
ecossistema do Titanium, a Appcelerator criou o Titanium Studio, um ambiente

30
integrado de desenvolvimento (IDE) proprietário que permite o desenvolvimento com
Titanium utilizando ferramentas visuais de criação de interfaces mobile.
As principais características do Appcelerator Titanium incluem:
• Uma API multi-plataforma para acessar componentes nativos de interfaces de
usuário, tais como barras de navegação, menus, e caixas de diálogo, além de
funcionalidades do dispositivo como sistema de arquivos, rede,
geolocalização, acelerômetro e mapas.
• Acesso transparente à funcionalidades nativas em que o SDK ainda não
oferece suporte.
Todo código-fonte da aplicação é instalado no dispositivo, onde é interpretado
utilizando o motor Javascript V8, da google. O carregamento do aplicativo pode levar
mais tempo do que em aplicativos desenvolvidos com sua respectiva SDK nativa.
Isso acontece porque o interpretador e todas as bibliotecas necessárias precisam
ser carregadas antes que a interpretação do código-fonte seja iniciada.
A Appcelerator afirma que o Titanium e seu ecossistema permite a
reutilização de 60% à 90% do código-fonte da aplicação quando desenvolvendo
para múltiplas plataformas, o que o torna uma ótima opção para prototipação e
validação de ideias com baixíssimo custo e curtíssimo tempo. A Appcelerator
também oferece uma extensa serie de ferramentas disponibilizadas por meio de
uma interface web simples e amigável que permite:
• Criar APIs para prover dados para os aplicativos;
• Gerenciar, escalar e estender APIs na nuvem;
• Enviar notificações Push;
• Gerenciar o ciclo de vida dos aplicativos;
• Receber visões diferenciadas de negócio;
• Monitorar performance e erros fatais de aplicativos;

31
Embora o Titanium SDK seja open-source, a melhor maneira de desenvolver
um aplicativo mobile utilizando-o, é por meio das ferramentas que a Appcelerator
oferece, e para isso ser possível é necessário o cadastro na base de
desenvolvedores do Appcelerator. O cadastro é gratuito, e suas ferramentas
também possuem versões gratuitas, porem para usufruir o máximo da plataforma
Appcelerator é necessário uma assinatura, que pode ser adquirida por $39 dólares
mensais. A plataforma Appcelerator permite três formas de iniciar a criação de um
aplicativo:
• Appcelerator Studio: Uma IDE baseada no Eclipse que provê uma ambiente
único e extensível para o desenvolvimento de aplicativos mobile;
• Appcelerator CLI: Ferramenta de interface de linha de comando que reúne
todos os comandos para criar e gerenciar aplicativos mobile;
• Importação de Aplicativos: Oferece ferramentas de análise, serviços e
testes para aplicativos construídos com Titanium SDK, ACS ou Node.ACS.
Representação do ecossistema Appcelerator (Fonte: http://www.appcelerator.com/)

32
Um projeto típico do Appcelerator Studio possui a seguinte arquitetura de
arquivos:
• app/: Diretório principal da aplicação, contém estrutura baseada em MVC;
o assets/: Arquivos que serão instalados como recursos do aplicativo
nativo;
o controllers/: Controladoras da aplicação;
o lib/: Bibliotecas de utilidades;
o migrations/: Arquivos de migrações necessárias de banco de dados
o models/: Modelos de acesso a dados da aplicação;
o styles/: Arquivos de estilo .tss, baseado em css, oferece uma
abstração unificada da construção de estilos de cada plataforma;
o views/: Arquivos de interface .xml, oferece uma abstração unificada na
construção de interface de usuários de cada plataforma;
o widjets/: Componentes pré-compilados reutilizáveis pela aplicação
o alloy.js: Arquivo executado antes da execução de qualquer controller,
utilizado para inicialização (bootstrapping)
Projeto criado no Titanium Studio

33
o config.json: Arquivo de configuração utilizado para revelar variáveis
disponíveis em toda execução da aplicação
• platform/: Contém cada projeto de código fonte nativo criado pelo Titanium;
• plugins/: Plugins utilizados pela aplicação;
• tiapp.xml: Configurações principais do aplicativo (como ID da App, versão,
etc...);
• ITunesConnect.png, MarketplaceArtwork.png: Imagens da loja de
aplicativos.
Graças ao tamanho de sua base de desenvolvedores e por ser consolidado
no mercado de híbridos por muito tempo, muitas empresas o escolhem como
primeira opção para criação de aplicativos mobile, o que tornou a lista de cases de
sucesso muito grande para serem listados aqui sem resumo. Uma lista dos
aplicativos mais populares construídos com Appcelerator Titanium inclui:
• Wunderlist (gerenciador pessoal de tarefas)
Mesmo aplicativo de mapa rodando no iOS e Android

34
• Paypal (serviço de pagamentos e troca de dinheiro online)
• ebay (anuncio de produtos)
• citi (gerenciamento de cartão de credito)
• Khan Academy (plataforma de treinamento de desenvolvimento)
• Vmware (virtualização)
• GameStop (loja de games)
Como foi dito anteriormente, o Appcelerator possui uma das maiores bases
de desenvolvedores cadastrados do mundo, é robusto, com um ecossistema
completíssimo de ferramentas que possibilitam a criação, manutenção e
monitoramento de aplicativos mobile. Oferece serviços de back-end em que o
aplicativo pode se apoiar, como criação de APIs e envios de notificações de Push. É
de fácil aprendizado, tem incrível performance quando comparado com outras
ferramentas de desenvolvimento multi-plataforma, simplifica e acelera o
desenvolvimento de protótipos e aplicativos pequenos. Porém o Appcelerator
Aplicativos desenvolvidos com Appcelerator Titanium (fonte:
http://www.appcelerator.com/customers/app-showcase/)

35
Titanium também possui alguns problemas que devem ser levados em
consideração:
• Para usufruir de todas as ferramentas é necessário assinar os serviços da
Appcelerator, o quem para uma pequena startup ou desenvolvedor autônomo
pode não ser nada atrativo;
• Todas as ferramentas, incluindo as gratuitas, necessitam de login para ser
utilizadas e ocasionalemente o sistema de autenticação se torna instável, o
que pode impedir que desenvolvedores trabalhem nos seus aplicativos;
• Normalizar aplicativos em todas as plataformas, embora possa ser
considerado uma vantagem, também é uma desvantagem, já que é
necessário o aprendizado de tecnologia proprietária que pode não ser
diretamente transferível fora do ecossistema do Titanium.
Baseado em tudo que foi falado aqui, fica claro o quanto o Titanium pode
baratear e diminuir o tempo de um projeto de aplicativo mobile. Os seus serviços
completos e robusto, junto ao fato de somente estarem disponíveis a partir de uma
assinatura torna o Appcelerator uma opção mais apropriadas para empresas
pequenas que já possuem algum recurso para investir na validação de um modelo
de negócios, mas ainda precisam gerenciar esses recursos de forma eficiente e
eficaz.
3.3 INTEL XDK
Em 2013, a Intel adquiriu a AppMobi, uma plataforma de serviços integrados
voltados para aplicativos mobile, na iniciativa de oferecer um ecossistema integrado
de construção, manutenção, monitoramento, e serviços de back-end como APIs e
envios de notificações Push. Esse ecossistema foi então, integrado ao Intel XDK,
uma IDE centralizada que inclui o popular editor Brackets e um Editor WYSIWYG,
criando uma plataforma que hoje é um dos mais completos e consolidados conjunto
de ferramentas para desenvolvimento de aplicativos mobile multi-plataforma

36
existentes. O Intel XDK pode ser baixado gratuitamente em seu site, e possui versão
para todos os sistemas operacionais mais populares.
Diferentemente das outras opções, o Intel XDK não requer nenhuma
dependência para compilar aplicativos para as plataformas que ele suporta.
Utilizando o Apache Cordova por exemplo, para compilar um aplicativo iOS você
necessita do XCode e suas ferramentas, e consequentemente, é necessário que
esteja utilizando o sistema operacional Mac OS X para que seja possível iniciar o
processo de build. Com o Intel XDK isso não é necessário, como sua compilação é
feita na nuvem, graças aos seus serviços integrados, qualquer aplicativo pode ser
compilado para todas as plataformas de dispositivos em qualquer sistema
operacional. O Intel XDK suporta a criação de aplicativos mobile para Android, iOS,
Windows, Firefox OS e Tizen, além de suportar também o desenvolvimento Apps
para Chrome OS, Facebook, Amazon e Nook.
Embora seja gratuito, para iniciar o desenvolvimento com o XDK é necessário
que o desenvolvedor se cadastre na base de usuários da Intel, pois ao abrir a IDE
são requisitadas as credenciais do utilizador, que só quando validadas habilitam o
acesso as ferramentas integradas que ele oferece.
O Intel XDK utiliza o Apache Cordova como base de seus projetos, o que o
possibilita a importação de um projeto feito puramente com Apache Cordova,
transformando-o em um projeto do Intel XDK. A IDE oferece duas maneiras de
desenvolver os aplicativos: uma é utilizando um editor criado para desenvolvimento
web, o Brackets, que possui uma grande base de usuários, plug-ins e é mantido pela
Adobe. A outra maneira é utilizando um editor visual de interfaces onde o
desenvolvedor pode facilmente criar um protótipo por meio de “clique e arraste” de
componentes reutilizáveis. Esses componentes são baseados em frameworks
HTML5 específicos para interfaces mobile. Os frameworks suportados são:
• App Framework (mantido pela própria Intel)
• Ionic
• Twitter Bootstrap 3
• JQuery Mobile

37
• TopCoat
• Ratchet
As ferramentas da IDE são separadas por abas numa sequência lógica, que
tenta seguir os passos existentes no ciclo de desenvolvimento de aplicativos mobile,
as abas seguem a seguinte ordem:
1. Desenvolvimento: Onde fica o código fonte e as ferramentas de edição de
código ou o App Designer (Editor WYSIWYG);
2. Simulação: Usado para simular sua aplicação dentro de um dispositivo alvo,
é baseado no Apache Ripple, que é basicamente uma versão empacotada do
Chrome (Webkit) com suporte à algumas APIs extras;
3. Teste: Utilizado para testar seu aplicativo em um dispositivo real, utilizando o
aplicativo da Intel chamado App Preview que deve estar instalado no
dispositivo alvo;
4. Depuração: Por enquanto disponível somente para Android e iOS, permite a
depuração de aplicativos em tempo real via USB;
Ambiente de desenvolvimento do Intel XDK

38
5. Monitoramento de Performance: Somente disponível para Android até o
momento, permite o monitoramento de performance do aplicativo em tempo
real via USB;
6. Build/Packaging: Utilizado para criar o executável do aplicativo para ser
incluído nas lojas de aplicativos.
A estrutura de arquivos de um projeto criado ou importado pelo Intel XDK é
variável, já que ele oferece várias opções de frameworks, além da opção de criar um
projeto XDK ou Apache Cordova, cujo suas arquiteturas são muito similares. Um
desenvolvedor que tenha alguma experiência em desenvolvimento com Apache
Cordova terá pouquíssima fricção ao migrar para o Intel XDK, embora perca um
pouco da liberdade que o Cordova oferece, as ferramentas agregadas que o XDK
oferece podem ser atrativas dependendo dos requisitos do projeto.

39
Por ser uma ferramenta bastante completa, robusta e ter uma grande
empresa com a Intel por trás, o Intel XDK já é opção primária de algumas empresas,
startups e desenvolvedores autônomos, mas por ser uma ferramenta relativamente
nova a quantidade de aplicativos populares criados com o XDK é bem pequena,
porém existem. A maior parte dos projetos conhecidos desenvolvidos com XDK são
jogos, o que contradiz o fato de não ser possível desenvolver games com
ferramentas hibridas por causa da performance. Alguns dos aplicativos mais
populares são:
• Star Nomad Elite (Game de RPG/RTS)
• Nika Digital (Game de estratégia)
• Hostel HookApp (App para busca de albergue para estudantes)
Simulador integrado do XDK rodando um aplicativo de exemplo que utiliza a biblioteca Javascript d3js

40
• ZonzoFox (App de turismo italiano, que oferece informações de locais
turisticos na Itália)
• DeadShotZ (Game de tiro de zumbis)
Porém o Intel XDK tem algumas desvantagens que podem pesar na hora de
escolher a ferramenta certa para se iniciar um projeto, por exemplo, por ter tantas
ferramentas integradas em um só local, o XDK pode apresentar lentidão em várias
tarefas (pesadas, como rodar o aplicativo no simulador, ou até leves, como arrastar
um componente de um lado para outro no editor visual), e o fato de precisar de um
cadastro para utilizá-lo é algo que pode desestimular desenvolvedores mais
apegados ao open-source. Como dito anteriormente, por ser uma ferramenta
relativamente nova, pode haver dificuldades ao procurar recursos de informação
sobre problemas comuns, já que a comunidade em torno do XDK ainda é
relativamente pequena, porém a área de documentação e treinamento do Intel XDK
e suas ferramentas são excepcionais.
Todas as ferramentas integradas ao Intel XDK oferecem um suporte 360º ao
desenvolvedor/time no ciclo de desenvolvimento de um projeto de aplicativo mobile.
Permite uma rápida prototipação, que possibilita consolidar uma ideia em produto,
em pouquíssimo tempo com baixíssimo custo. É uma ótima opção para startups ou
pequenos desenvolvedores que desejam validar uma ideia com o menor custo
possível.
3.4 SENCHA TOUCH
Sencha Touch é um produto da Sencha, uma empresa conhecida pela
criação do ExtJS (popular framework HTML5). Foi criado com base na combinação
dos já consolidados frameworks HTML5 ExtJS, JQTouch e Raphael. Por ser um
framework concebido com o principal proposito de facilitar o desenvolvimento de
sites mobile, hoje ele suporta a grande maioria de navegadores mobile.
O Touch (como é chamado em alguns círculos) é um framework HTML5
baseado em MVC para criação de aplicativos web mobile, e utiliza de técnicas de

41
aceleração de hardware para prover componentes de interface de usuário de alta
performance em dispositivos móveis. Possui mais de 50 componentes reutilizáveis
disponíveis por padrão, cada um com seu visual e comportamento nativo para cada
plataforma alvo. O Sencha Touch suporta as plataformas iOS, Android, Blackberry e
Windows Phone.
Como já foi dito, o Sencha Touch é somente um framework HTML5 para
criação de interfaces mobile para web, logo, para ser utilizado para criação de um
aplicativo híbrido o Sencha Touch necessita de uma “casca” para abstrair a
comunicação com o dispositivo e dar acesso a suas habilidades nativas. A “casca”
utilizada pelo Touch é o, já abordado aqui, Apache Cordova. Por meio da ferramenta
de CLI do Touch é possível transformar a aplicação mobile web em um aplicativo
hibrido que pode ser incluído nas lojas de aplicativos e instalado em qualquer
dispositivo das plataformas suportadas.
O Touch é um dos frameworks específicos para mobile mais complexos, e
embora a curva de aprendizado possa ser mais íngreme quando comparamos com
as outras opções, ele permite que seja possível criar interfaces de qualquer
complexidade com relativa facilidade e além disso, a sua documentação é uma das
melhores e mais completas quando comparamos com as opções aqui citadas.
Complementando, a comunidade em torno do Sencha Touch é enorme, o que
equivale à uma vasta base de recursos de informação online, assim a tarefa de
iniciar os primeiros passos com o framework se torna bem menos dolorosa.
O Sencha Touch é totalmente integrado com o Apache Cordova, e oferece
abstrações das APIs do dispositivo nativo como câmera, geolozalização, contatos,
acelerômetro e giroscópio. Essas APIs são providas de forma consistente com todo
Mesma interface utilizando os vários temas disponíveis. (Fonte: http://moduscreate.com/5-best-
mobile-web-app-frameworks-sencha-touch/)

42
seus sistema de namespace e classes, tornando todo o ecossistema do framework
homogêneo e bastante elegante.
Para continuar competitiva no mercado a Sencha precisou começar a
oferecer ferramentas facilitadoras do ciclo de desenvolvimento, então criou o Sencha
Architect, uma ferramenta visual que permite criar interfaces de usuário com o
Sencha Touch utilizando interações de “clique e arraste”. Outra forma de iniciar o
desenvolvimento de um aplicativo mobile com o Touch é por meio de sua ferramenta
de interface de linha de comando (CLI), chamada de Sencha CMD, quem tem como
objetivo prover o suporte com o projeto base, processo de desenvolvimento,
gerenciamento de temas, build, simulação e empacotamento do aplicativo (utilizando
o Apache Cordova ou o serviço Sencha Packager, também um serviço de
compilação em nuvem).
O Sencha Architect, embora seja gratuito para testar por 30 dias, a sua
licença anual possui um preço relativamente “salgado” para escopos onde não há
muito recurso financeiro para investir muito em uma ferramenta facilitadora, ainda
mais quando há uma alternativa gratuita, que é o Sencha CMD + qualquer editor
web que o desenvolvedor tenha mais proficiência. O Sencha CMD durante ou
desenvolvimento (por meio de um watcher, que acelera bastante o ciclo de escrever
código e verificar seu impacto no browser) ou empacotamento do aplicativo,
escaneia o código fonte, descobre suas dependências, remove o código não
utilizado, concatena e minifica o código final (tanto Javascript quanto CSS, por meio
do SASS, um pre-compilador CSS), resultando em um aplicativo web mais otimizado
possível para ser rodado eficientemente em um dispositivo mobile.
Para iniciar um projeto com o Sencha Touch utilizando o Sencha CMD é
necessário suprir algumas dependências:
• Baixar e descomprimir em qualquer diretório o SDK do Sencha Touch;
• O JRE (Java Runtime Environment) precisa estar instalado (O Sencha CMD é
escrito em Java);
• Ruby (para compilar o código SASS em CSS);
• Instalar o Sencha CMD;

43
Com todas as dependências supridas criar um projeto é tão simples quanto
executar um comando no console, especificamente “sencha –sdk
/caminho/para/sencha-touch-sdk generate app $NOME_DO_APP $DIRETORIO”, e
pronto, o projeto base está criado e pronto para iniciar o desenvolvimento.
A estrutura de arquivos de um projeto do Sencha Touch é simples de
entender para desenvolvedores que já estão acostumados com o ambiente front-end
da web. A arquitetura é a seguinte:
• app/: Diretório que contém os arquivos de modelos, interfaces, controladoras
e armazéns de dados da aplicação;
• build/: Diretório que contém os arquivos gerados pelo processo de build do
Sencha CMD;
• packages/: Diretório que contém os arquivos binários de cada plataforma
mobile, gerado pelo processo de build do Apache Cordova;
• resources/: Diretório que contém os estilos e imagens utilizadas do aplicativo;
• app.js: Arquivo de entrada principal do aplicativo;
• app.json: Arquivo de configuração do aplicativo;
Projeto base do Sencha Touch

44
• index.html: Arquivo HTML principal do aplicativo;
• packager.json: Arquivo de configuração utilizado pelo Sencha CMD para
gerar os binários nativos de cada plataforma com o Apache Cordova;
Utilizando o comando “sencha app build –run native” o Sencha CMD compila
a aplicação, gera os pacotes nativos de acordo com as configurações e abre o
aplicativo em algum dispositivo conectado em modo de desenvolvimento ou em
algum simulador local disponível.
Segundo a página de clientes da Sencha, eles possuem um grande número
de clientes corporativos, segundo eles mais de 10 mil, incluindo 60% da lista Fortune
100, que lista as 100 melhores empresas para se trabalhar, compilada pela revista
Fortune. Em meio a tantos clientes, não é difícil listar cases de sucesso do Sencha
Touch, mas uma pequena compilação de aplicativos inclui:
• United Heritage Insurance (Aplicativo de uma grande empresa de seguros)
• Open Banking (Aplicativo bancário)
• Smile Brands (Aplicativo para tablets, voltado para a área odontológica)
Mesmo aplicativo sendo simulado no iOS e Android.

45
• Ford Showroon (Aplicativo da Ford para tablets)
• Getorapher (Aplicativo de fotografia)
O Sencha Touch possui algumas desvantagens que podem não ser atraentes
para alguns desenvolvedores, por exemplo: embora seja gratuito, todo o
ecossistema do Sencha, incluindo o suporte, é pago e não possuem um valor
considerado negligenciável. O framework é grande e complexo e pode levar algum
tempo para aprender, além de ter uma performance limitada em plataformas que
não suportam Webkit.
O Sencha Touch é robusto, maduro e amplamente consolidado, o tornando
uma ótima opção para desenvolver aplicativos mobile híbridos. A melhor opção para
uma startup seria seguir o caminho gratuito que o Sencha Touch oferece, assim o
custo é bastante reduzido e os resultados são bem impressionantes. Embora possa
levar algum tempo para dominar o framework, depois que se pega o jeito, se torna
simples, criar um aplicativo relativamente complexo em pouco tempo.
3.5 NATIVESCRIPT
NativeScript é a ferramenta mais nova das opções aqui citadas, sua primeira
versão foi lançada em maio de 2015 e causou bastante alarde na comunidade de
desenvolvedores web por causa da maneira que aborda o desenvolvimento mobile
multi-plataforma. Diferentemente das outras opções de ferramentas abordadas até
agora, que resultavam em interfaces de usuário hibridas por meio de WebViews, o
NativeScript permite a criação de aplicativos mobile multi-plataforma com interfaces
de usuário realmente nativas e 100% de compartilhamento de código-fonte entre
todas as plataformas.
Uma ferramenta que faz algo similar, porém não será abordada neste trabalho
por não utilizar tecnologias web no seu processo de desenvolvimento é o popular
Xamarin, que utiliza o framework .NET da Microsoft e a linguagem C# como base de
seus projetos. Como um evangelista da Telerik (criadora e mantenedora do
NativeScript) explicou, “para a concepção do NativeScript focou-se fortemente no

46
conjunto de habilidades de um desenvolvedor web. O objetivo é que qualquer um
que esteja confortável hoje escrevendo HTML/CSS/Javascript se sinta
instantaneamente à vontade criando aplicativos mobile nativos usando NativeScript”
(ANGLIN, TODD, 2015).
Embora o NativeScript também ofereça “wrappers” ou abstrações de APIs
nativas do dispositivos, diferentemente das outras opções, ele não necessita de
atualização para tirar vantagem de novas capacidades caso uma nova API nativa
seja lançada ou uma API já existente seja modificada. Isso é possível porque o
NativeScript é o único que utiliza reflexão em tempo de compilação para tornar
qualquer API nativa ou biblioteca de terceiros disponível para o proxy Javascript, ou
seja, via Javascript é possível executar comandos com a exata interface da API
nativa e efetivamente chamar aquela funcionalidade equivalente em tempo de
execução. Mas as abstrações oferecidas pelo NativeScript são o meio recomendado
de acessar estas APIs nativas, pois expõem uma interface única, simples e multi-
plataforma. O NativeScript suporta as plataformas Android, iOS e Windows Phone.

47
Para padronizar a criação de UIs (interfaces de usuário) entre todas as
plataformas que o NativeScript suporta, é utilizada uma estrutura XML para definir os
layouts e seus componentes. Essas estruturas XML são separadas em páginas,
cada página representa uma tela do aplicativo, e são estilizadas utilizando CSS
(nem todas as regras são suportadas, somente um subconjunto delas). Para cada
página XML é necessário um arquivo escrito em Javascript ou TypeScript (um
verificador estático de tipos que compila para Javascript) com o mesmo nome da
página, que contém os comportamentos ligados à UI.
O NativeScript possui duas maneiras de iniciar um projeto de aplicativo
mobile, uma é utilizando sua plataforma integrada de desenvolvimento chamada de
AppBuilder, porém esta plataforma não é gratuita. A outra forma é utilizando sua
ferramenta de interface de linhas de comando (CLI), que é gratuita e open-source, e
suporta Windows, Linux e OS X. Utilizando o AppBuilder se torna possível compilar
aplicativos para qualquer plataforma suportada sem nenhuma dependência, por
Representação do mesmo código sendo compartilhado em várias plataformas com o NativeScript.
(Fonte: http://www.telerik.com/nativescript)

48
meio do serviço de compilação em nuvem da Telerik. Utilizar o NativeScript CLI é a
opção de menor custo, porem possui as mesmas dependências que desenvolver
aplicativos nativos, já que serão compiladas no computador do desenvolvedor, por
exemplo: para desenvolver aplicativos para Android são necessários todas as
dependências que o ambiente de build do Android possui, incluindo o JDK (Java
Development Kit), Apache Ant (Ferramenta de build utilizada pelo Android) e o
Android SDK. Além disso é necessário a instalação do NodeJS, pois o CLI é escrito
em Javascript.
Após todas as dependências serem supridas e o NativeScript CLI estiver
instalado, iniciar um projeto é bem simples: o comando “tns create
$NOME_DO_APP” cria um projeto base no diretório $NOME_DO_APP. O comando
“tns platform add $ID_PLATAFORMA”, sendo $ID_PLATAFORMA uma das três
plataformas disponíveis (“ios”, “android” ou “windows”). Finalmente o comando “tns
run $ID_PLATAFORMA” instala e executa o aplicativo em algum dispositivo
conectado em modo de desenvolvimento conectado ao computador ou adicionando
o parâmetro “--emulator” o aplicativo é executado no simulador disponível da
plataforma escolhida.
A arquitetura de arquivos de um projeto NativeScript é bem simples e direto
ao ponto:
Projeto base do NativeScript

49
• app/: Diretório que é o espaço de desenvolvimento do aplicativo;
o app.css: Arquivo principal de estilos do aplicativo;
o app.js: Arquivo Javascript que serve como ponto de entrada principal
do aplicativo;
o bootstrap.js: Arquivo de inicialização de configurações de ambiente do
aplicativo;
o main-page.js: Controladora da página inicial do aplicativo;
o main-page.xml: Página principal do aplicativo;
o App_Resources/: Diretório que contém arquivos de recursos para
cada plataforma, como ícones, imagens, splash-screens e etc..
o tns_modules/: Diretório que contém todos os módulos Javascript de
abstração das APIs nativas que o framework oferece;
• platforms/: Diretorio que contém os projetos nativos de cada plataforma
adicionada ao projeto;
Como o NativeScript é uma ferramenta muito nova, até o desenvolvimento
deste trabalho não há nenhum grande case de aplicativo mobile desenvolvido com
Mesmo aplicativo de exemplo do NativeScript rodando nos simuladores de iOS e android.

50
ele, porém é só uma questão de tempo, já que a abordagem criada pela Telerik
atraiu os olhos de muitos desenvolvedores e empresas, que já adotaram o
NativeScript como ferramenta de desenvolvimento para aplicativos mobile multi-
plataforma, tornando o futuro do NativeScript bem promissor.
Como todas as opções abordadas aqui, o NativeScript também possui suas
fraquezas, por exemplo, por utilizar componentes visuais nativos (e não interfaces
de usuário web como seus concorrentes) ele necessita de compilação sempre que
uma alteração é feita no código e o desenvolvedor queira ver o impacto dela no
aplicativo rodando do dispositivo ou simulador. Por ser muito nova, falta recursos de
informação na web sobre possíveis problemas que os desenvolvedores possam
encontrar durante o ciclo de desenvolvimento. Sua abordagem de criar uma
estrutura XML para criação de UIs adiciona uma camada de complexidade que exige
que o desenvolvedor aprenda como ela funciona, e esse conhecimento não pode ser
reaproveitado fora do escopo do NativeScript.
O fato dos componentes da interface de usuário de aplicativos desenvolvidos
com NativeScript serem totalmente nativos também o torna a opção mais
performática quando comparada com as outras ferramentas abordadas aqui, logo se
a performance é uma preocupação na hora de fazer a escolha entre elas, a resposta
se torna meio óbvia. Além disso o NativeScript é open-source, tem uma
documentação simples e sólida, provê grande compartilhamento de código entre as
plataformas alvo, o que o torna uma ótima opção para desenvolver aplicativos
nativos em múltiplas plataformas em pouco tempo e com baixo custo.
3.6 REACT NATIVE
Embora sua versão publica tenha sido lançada dois meses antes do
NativeScript, os engenheiros do Facebook afirmam estarem usando o React Native
em seus aplicativos mobile há mais de dois anos. Em março de 2015 o Facebook
tornou o React Native open-source e a partir daí as coisas foram acontecendo
extremamente rápido. Vários artigos dos integrantes mais populares da comunidade

51
de desenvolvedores web foram publicados, e rapidamente uma grande massa de
curiosos interessados a trabalhar com a “próxima grande ferramenta” para
desenvolvimento de aplicativos mobile nativos se aglomeraram, uma nova
comunidade se formou, e ainda está em rápido e continuo crescimento.
Parte da popularidade repentina do React Native se deve ao fato de ter sido
desenvolvido pelo Facebook, que contribui consistentemente com a comunidade de
desenvolvedores web e mobile. Outra parte desse rápido ganho de adeptos é
oriundo do fato dessa ferramenta utilizar um dos mais populares frameworks de
interfaces de usuário web hoje, o React, também criado pelo Facebook. O React é
um framework Javascript para criação de aplicações web com interfaces de usuário
dinâmicas. O React antes de ter sido tornado open-source, também já era utilizado
nos produtos do facebook há bastante tempo, e hoje é utilizado em larga escala em
projetos de pequeno, médio e grande porte fora do Facebook, por várias empresas,
startups e desenvolvedores autônomos.
O que diferencia React de outros frameworks de UI para aplicações web é
que ele introduz um conjunto de abordagens muito diferentes dos frameworks
Javascript concorrentes, como AngularJS ou EmberJS. Por exemplo, a sua API de
construção de interfaces é declarativa ao invés de imperativa, significa que ao invés
de chamar métodos para renderizar dados de algum modelo em um componente,
você simplesmente declara por meio de “tags” JSX (baseado em XML, mas é
transformado em Javascript puro).

52
O React Native foge do padrão das outras ferramentas abordadas aqui, no
sentido de que o objetivo dele não é compartilhar o código-fonte entre todas as
plataformas alvo, e sim compartilhar o conhecimento assimilado nele em todas as
plataformas alvo. No artigo de anuncio do lançamento do React Native, o engenheiro
do facebook Tom Occhino explica o porquê da escolha desta abordagem:
“... É importante salientar que nós não estamos perseguindo o
objetivo de tornar o React Native mais um framework ‘escreva uma
vez, rode em qualquer lugar’. Plataformas diferentes possuem
visuais, experiências e capacidades diferentes, logo, devemos
desenvolver aplicativos diferentes para cada plataforma, mas os
mesmos engenheiros devem ser capazes de desenvolver aplicativos
em qualquer plataforma que escolherem sem a necessidade de
aprender um novo conjunto de tecnologias fundamentalmente
diferentes para cada uma delas. Nós chamamos esta abordagem de
‘aprenda uma vez, escreva em qualquer lugar’...”
(OCCHINO, TOM, 2015)
Exemplo de código declarativo do React Native, repare como o XML se mistura com o Javascript.
(Fonte: https://facebook.github.io/react-native/)

53
React Native possui um conjunto de características que realmente empolgam
qualquer desenvolvedor, seja ele oriundo do desenvolvimento web ou já experiente
no mundo mobile. Todos os componentes são totalmente nativos. Toda
comunicação do código Javascript do aplicativo com a plataforma nativa é feita de
forma assíncrona, ou seja, qualquer interpretação pesada como decodificação de
imagens ou escrita/leitura de arquivos são feitas em uma thread diferente, o que não
bloqueia a interface de usuário. Possui um sistema avançado de reconhecimento de
toques que possibilitam o reconhecimento de toques e gestos de maneira simples e
precisa. A estilização dos componente é totalmente baseada em CSS, escrita por
meio de simples objetos Javascript, facilita a criação de layouts com o modelo de
Flexbox do CSS. Oferece abstrações de APIs nativas como conexão HTTP ou
gelocalização por meio de interfaces Javascript descritas pelos padrões W3C. As
mensagens de erros são as mais descritivas já vista em qualquer framework web ou
mobile, o que ajuda bastante ao encontrar e eliminar um erro. Permite fácil criação
de componentes nativos que o React Native não trás por padrão por meio da
ferramenta de exportação oferecida pelo framework. Por ultimo e não menos
importante, não é necessário compilar o aplicativo sempre que uma mudança é feita
no código, é necessário somente que uma atualização seja feita por uma tecla de
atalho no simulador e pronto, a mudança já será exibida.
Até o desenvolvimento deste trabalho o React Native só suporta o iOS, mas
embora não tenha sido divulgada nenhuma data, os engenheiros por trás do React
Native garantem que em breve será adicionado o suporte ao Android e em seguida
Windows Phone. Para iniciar um projeto com o framework é necessário atender à
alguns requisitos:
• Sistema Operacional OS X;
• XCode (IDE do iOS nativo);
• NodeJS (para instalar e utilizar a ferramenta de CLI);
• Watchman (para reload continuo do aplicativo sem necessidade de
recompilação);
• react-native-cli (Ferramenta de interface de linha de comando para dar
suporte na criação e durante o desenvolvimento do projeto);

54
Depois de todas as dependências supridas para iniciar um novo projeto com o
projeto base do React Native é necessário executar o comando “react-native init
$NOME_DO_PROJETO” e será criado um diretório com o nome
$NOME_DO_PROJETO que contem o ambiente de desenvolvimento base do React
Native. Para rodar o projeto, é necessário abri-lo no XCode e compilar o aplicativo
por lá, do mesmo jeito que com um projeto iOS comum.
A estrutura de arquivos de um projeto do React Nativo é extremamente
flexível para o desenvolvedor separar os arquivos da forma que ele desejar, porem
há uma estrutura básica:
• iOS/: Diretório que contem as bibliotecas e recursos nativos do projeto de
iOS;
• $NOME_DO_PROJETO.xcodeproj/: Diretório que contém o projeto nativo de
iOS;
• $NOME_DO_PROJETOTests/: Diretório que contém os teste da aplicação;
Projeto base do React Native

55
• node_modules/: Diretório que contém as dependências Javascript, incluindo,
mas não se limitando ao React Native;
• index.ios.js: Arquivo de ponto de entrada principal do aplicativo;
• package.json: Arquivo que contém configurações de dependências do
projeto;
O React Native ainda tem um longo caminho pela frente, e é discutível se está
pronto para ser utilizado em produção. Existe uma longa lista de problemas que
podem desencorajar quem procura algo mais maduro e robusto para desenvolver
seus aplicativos, além do fato dele só suportar o iOS por enquanto, não
necessariamente diminui os custos de um projeto o bastante para escolhe-lo ao
invés de usar a tecnologia nativa diretamente. Porém o Facebook utiliza-o em vários
de seus produtos há muito tempo e garantem ter tido muito sucesso desenvolvendo
com React Native até agora. A lista de aplicativos do Facebook que utilizam o React
Native inclui o próprio aplicativo do Facebook para iOS, o aplicativo de Facebook
Groups para iOS e o aplicativo Facebook Ads para iOS.
Projeto base rodando no simulador iOS

56
Documentação incompleta, alguns bugs em tempo de execução, baixo
numero de recursos de informação online, sem suporte para outras plataformas e
alguns outros problemas o tornam um risco para quem presa por algo mais
consolidado, mas é uma ótima opção para quem gosta de estar sempre à frente com
as tecnologias mobile, já que apesar o longo caminho que precisa percorrer, o React
Native tem potencial para ser a próxima grande ferramenta para desenvolvimento de
aplicativos mobile nativos multi-plataforma. E no estado atual, já é possível criar um
aplicativo nativo iOS em pouco tempo. Se isso for o bastante para a decisão de
escolha da startup ou desenvolvedor autônomo à procura de opções de frameworks
para desenvolver seu próximo aplicativo, então React Native pode ser uma boa
opção.

57
4 CONCLUSÃO
Cada vez mais rápido os dispositivos mobile vem ganhando espaço no dia a
dia das pessoas. O que durante algum tempo foi pensado como “a segunda tela”,
hoje é a primeira, ultrapassando o computador pessoal e a televisão. Hoje, 50% da
população mundial possuem smartphones, e há estimativas quem até 2020 esse
numero subirá para 80%, o que torna muito claro que a, já altíssima demanda,
continuará crescendo rapidamente.
E junto com a demanda de dispositivos mobile, a demanda de aplicativos para
esses dispositivos também continuará em constante crescimento, e para
acompanhar este rápido crescimento é necessário uma abordagem otimizada que
tenha ambos baixo custo e rapidez no desenvolvimento do produto.
É sabido que muitas vezes grandes ideias, ideias que vão suprir a alta
demanda de usuário, ideias que vão solucionar problemas do cotidiano das pessoas,
ideias que podem mudar o modo como vivemos, essas ideias podem surgir de
pessoas que não possuem muitos recursos para colocá-las em prática. E hoje é
comum essas pessoas receberem esses valiosos recursos de investidores que
acreditam em sua ideia. E é assim nascem as chamadas startups, o tempo todo, em
qualquer lugar do mundo. Porém os recursos disponibilizados para validar aquela
ideia sempre vão ser muito limitados no início, e necessitam que sejam gastos com
bastante eficiência ou então esta grande ideia pode nunca se concretizar.
Foi sugerido aqui que o modo mais eficiente de validar uma ideia de um
aplicativo mobile é utilizando a abordagem multi-plataforma que reaproveita
conhecimentos, código-fonte e ferramentas da web para ser aplicada. Deste modo, é
possível economizar valiosos recursos durante o desenvolvimento do aplicativo e
ainda chegar à uma versão totalmente funcional que valide esta ideia em
pouquíssimo tempo, utilizando os conceitos de Lean Startup.
Foram apresentadas várias ferramentas que implementam esta abordagem,
todas elas com suas diferentes formas de abordar o problema. Foram apontadas
suas vantagens, desvantagens e seus inúmeros casos de sucesso. As informações

58
compiladas neste trabalho deixam claro que as ferramentas web já invadiram o
mundo de desenvolvimento de aplicativos mobile há muito tempo e isso está
fazendo muito bem, tanto para os desenvolvedores que podem reaproveitar suas
habilidades desenvolvendo experiências verdadeiramente mobile, quanto para os
usuários, que são bombardeados com várias opções de aplicativos novos todos os
dias e muitas das vezes nem percebem a diferença de um aplicativo criado com a
abordagem multi-plataforma/hibrida de aplicativos criados com seus SDKs nativos.
Esta abordagem está ganhando cada vez mais adeptos devido as suas
vantagens e todo esse interesse faz com que novas ferramentas sejam criadas o
tempo todo. Logo haverá tantas opções para desenvolver aplicativos mobile com
tecnologias web que será necessário um minucioso estudo de cada uma delas para
saber qual ferramenta se adequa melhor ao aplicativo que será criado.
Este trabalho listou e apresentou informações técnicas sobre as mais
consolidadas ferramentas de desenvolvimento mobile multi-plataforma atualmente,
que utilizam ferramentas web. Ferramentas que são mantidas por empresas grandes
e maduras, o que às tornam as melhores opções a longo prazo.
O presente e o futuro é mobile, e dentro do mundo de desenvolvimento
mobile, o futuro é a eficiência e sustentabilidade. O futuro é a abordagem multi-
plataforma utilizando tecnologias web.

59
REFERÊNCIAS
• PAKA, A. The Rise of Micro Startup Acquisitions. TechCrunch, 2015:
http://techcrunch.com/2015/04/15/rise-of-micro-startup-acquisitions/
• GITAHY, Y. O que significa fazer pivot de uma startup. Exame, 2011:
http://exame.abril.com.br/pme/noticias/o-que-significa-fazer-o-pivot-de-uma-
startup
• GRIFFITH, E. Why startups fail, according to their founders. Fortune, 2014:
http://fortune.com/2014/09/25/why-startups-fail-according-to-their-founders/
• THE LEAN STARTUP. The Lean Startup Methodology. The lean startup,
2011: http://theleanstartup.com/principles
• ABROZIMOVA, K. Native VS Cross-Platform. Yalantis, 2013:
https://yalantis.com/blog/native-vs-cross-platform-app-development-shouldnt-
work-cross-platform/
• GOLDENBERG, A. Pros and Cons of Developing Native vs. Cross-Platform
Web-Based Mobile Aplication. DBBest, 2013:
http://www.dbbest.com/blog/pros-and-cons-of-developing-native-vs-cross-
platform-web-based-mobile-application/
• HOCKING, J. Native vs. Hibrid: developing cross-platform mobile apps. The
App Business, 2014: http://www.theappbusiness.com/native-vs-hybrid-
developing-cross-platform-mobile-apps/
• SITANSHU, J. Native vs Cross Platform for Application Development.
Sitanshu J, 2015: http://blog.zymr.com/native-vs-cross-platform-for-
application-development
• HEIKOTTER, H. HANSCHKE, S. MAJCHRZAK, T. Comparing Cross-Platform
Development Approaches for Mobile Applications. Muenster University,
2012: https://www.wi.uni-
muenster.de/sites/default/files/public/department/pi/publications/heitkoetter/Co
mparing-Cross-Platform-Development-Approaches-for-Mobile-Applications.pdf
• MADAUDO, R. Native versus Cross-Platform frameworks for mobile
application evelopment. Universitá degli Studi de Bergamo, 2013:
http://2013.eclipse-it.org/proceedings/6_Madaudo-Scandurra.pdf

60
• MICHAELS. ROSS. COLE. Native mobile apps: The wrong choice for
business?. MRC Productivity, 2013: http://www.mrc-
productivity.com/research/whitepapers/NativeAppsWrongChoice.pdf
• KOERBEL, A. Qual a equipe necessária e quanto custa um app?. Esauce,
2014: http://www.esauce.com.br/qual-equipe-necessaria-e-quanto-custa-criar-
um-app/
• APACHE CORDOVA. Apache Cordova docs. Apache Cordova:
http://cordova.apache.org/docs/en/5.0.0/guide_cli_index.md.html
• ANDREW. Who uses Phonegap/Cordova? Trice Designs, 2012:
http://www.tricedesigns.com/2012/03/27/who-uses-phonegapapache-cordova/
• PHONEGAP. Apps built with Phonegap. Adobe:
http://phonegap.com/app/feature/
• ADAM, J. Why Titanium App Development is a smart move for startups who
need apps. Tech.co, 2014: http://tech.co/titanum-app-development-get-top-
notch-cross-platform-applications-2014-03
• TITANIUM DOCS. Appcelerator CLI docs. Appcelerator:
https://web.appcelerator.com/product/cli
• APPCELERATOR. Apps Showcase. Appcelerator:
http://www.appcelerator.com/customers/app-showcase/
• INTEL XDK. Intel XDK details. Intel, 2014: https://software.intel.com/pt-
br/intel-xdk/details
• INTEL. Developer success stories. Intel: https://software.intel.com/pt-
br/success-stories
• DAWNSON, R. Getting Started with Intel XDK. Tutsplus, 2014:
http://code.tutsplus.com/articles/getting-started-with-intel-xdk--cms-22205
• KOKO, A. A new cross-platform option, introducing Intel XDK. Sitepoint,
2014: http://www.sitepoint.com/introduction-intel-xdk/
• SENCHA TOUCH. Sencha Touch Overview. Sencha:
http://www.sencha.com/products/touch/#overview
• GRISOGONO, G. 5 Best Mobile Web App Frameworks: Sencha Touch.
Modus Create, 2014: http://moduscreate.com/5-best-mobile-web-app-
frameworks-sencha-touch/

61
• RUDOLPHI, T. Using Sencha Touch as a Strategic Platform – An Evaluation.
Zühlke Blog, 2013: http://blog.zuehlke.com/en/using-sencha-touch-as-a-
strategic-platform-an-evaluation/
• STOYCHEV, V. NativeScript 1.0.0 is now available. NativeScript Blog, 2015:
https://www.nativescript.org/blog/nativescript-1.0.0-is-now-available
• VANTOLL, TJ. How NativeScript Works. Telerik Developer Blog, 2015:
http://developer.telerik.com/featured/nativescript-works/
• WITALEC, S. Getting Started with NativeScript. Telerik Developer Blog,
2015: http://developer.telerik.com/featured/getting-started-nativescript/
• TODD. The difference beetween Xamarin e Telerik`s NativeScript.
StackOverflow, 2015:
http://stackoverflow.com/questions/28829316/difference-between-xamarin-
and-teleriks-native-script
• NATIVESCRIPT. NativeScript Docs. Telerik, 2015:
https://docs.nativescript.org/
• OCCHINO, T. React Native: Bringing modern web techniques to mobile.
Facebook Code, 2015:
https://code.facebook.com/posts/1014532261909640/react-native-bringing-
modern-web-techniques-to-mobile/
• LONG, J. First impressions using React Native. James Long, 2015:
http://jlongster.com/First-Impressions-using-React-Native
• EBERHARDT, C. React Native Tutorial: Building Apps With Javascript. Ray
Wenderlich Blog, 2015: http://www.raywenderlich.com/99473/introducing-
react-native-building-apps-javascript
• MCCORKELL, R. React Native – The Killer Feature that Nobody Talks About.
Red Badger, 2015: http://red-badger.com/blog/2015/03/04/react-native-the-
killer-feature-that-nobody-talks-about/

Comparação de abordagens para desenvolvimento de aplicativos móveis

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (12)

Semelhante a Comparação de abordagens para desenvolvimento de aplicativos móveis

Semelhante a Comparação de abordagens para desenvolvimento de aplicativos móveis (20)

Comparação de abordagens para desenvolvimento de aplicativos móveis