Cameron Henneke, fundador e desenvolvedor do GQueues, um gerenciador de tarefas online integrado a diversos serviços do Google, migrou a versão em HTML5 de seu aplicativo móvel para iOS e Android. Durante o processo, Henneke registrou todo o esforço de desenvolvimento envolvido em ambas as plataformas e comparou os resultados em seu blog. A seguir é apresentado um resumo dos resultados obtidos e trechos de uma entrevista conduzida pelo InfoQ.com.
Experiência prévia
Embora possua mais de 12 anos de experiência em desenvolvimento de software, Henneke diz que tinha pouca ou nenhuma experiência com desenvolvimento iOS e Android, fato que coloca ambas as plataformas em pé de igualdade sob sua perspectiva:
Eu era absolutamente iniciante em Android quando comecei a desenvolver o aplicativo. Não tinha nem mesmo instalado o SDK em meu computador antes de iniciar o projeto. Da mesma forma, era praticamente um novato em relação ao iOS. Em 2010 havia criado dois jogos básicos para iPhone, mas a complexidade de ambos não chegava nem perto do aplicativo GQueues, além de terem utilizado um conjunto de APIs completamente diferente. Depois disso não me envolvi mais com desenvolvimento para iOS até começar o projeto GQueues.
Desenvolvimento
Android
- Uma semana lendo livros, assistindo tutoriais e criando aplicativos de teste;
- Uma semana para a fase inicial de design do aplicativo;
- Iniciou codificação real do aplicativo que levou cerca de 870 horas.
iOS
- Duas semanas de aprendizado, na maior parte do tempo se acostumando com as APIs Core Data, usando o PersistentStoreCoordinators e ManagedObjectContexts, e desenvolvendo uma "arquitetura escalável para o FetchedResultsControllers";
- Mais duas semanas para "se sentir confortável ao escrever código para iOS".
Como um todo, Henneke disse que gastou o dobro do tempo na curva de aprendizado do iOS comparado ao Android.
A respeito do material de estudo e aprendizado disponível, Henneke considera que a qualidade da documentação do Android é "muito maior" que a do iOS. O fato de o Android ser open source também o ajudou, possibilitando que olhasse exemplos de código e aprendesse a partir deles. Em relação à documentação do iOS, Henneke observa que:
Embora seja crescente a documentação sobre o iOS, a maioria se tornou obsoleta com as mudanças feitas nas versões 5 e 6 do iOS, incluindo a introdução da funcionalidade Automatic Reference Counting (ARC). Muitos exemplos de código (incluindo os oficiais da Apple) e maneiras para tratar problemas tornaram-se problemáticos e devem ser ignorados em prol de novos métodos. Filtrar tudo isso demandou mais tempo ainda.
O desenvolvimento da versão Android envolveu uma reescrita completa do código de sincronização com os servidores de backend que era utilizado com o aplicativo web em HTML5, mas Henneke precisou de 10% a menos de tempo para escrever a mesma aplicação para Android comparado ao iOS. As estatísticas gerais do desenvolvimento estão na tabela a seguir:
Android
iOS
Data de início
21/09/2012
02/03/2013
Versão beta pronta para testes
22/12/2012
10/06/2013
Publicação do aplicativo
31/01/2013
18/07/2013
Tempo total de projeto
4,25 meses
4,5 meses
Tempo de preparação para iniciar
1 semana
2 semanas
Tempo de desenvolvimento
870 horas (aprox.)
960 horas (aprox.)
Testes beta e correções
34 dias
38 dias
Número de testadores beta
92 pessoas
48 pessoas
Linhas de código
26.981 linhas
23.872 linhas
Tamanho do download do aplicativo
1,1 MB
3,5 MB
Ferramentas
Pessoalmente Henneke prefire o editor Vim, mas comentou o seguinte sobre algumas das ferramentas que utilizou no projeto:
- A pesquisa no Eclipse é ridiculamente lenta e pesada;
- A filtragem por log tags no Eclipse (com integração do logcat no plugin Android) é muito útil;
- A interface Builder no Xcode é inútil;
- As ferramentas Xcode Instruments são muito úteis para profilling, medições e depuração;
- Os emuladores de Android são um completo desperdício de tempo (parece uma piada como são lentos). Em meu ciclo de desenvolvimento, sempre implantei o aplicativo em dispositivos Android reais para testes. Era muito mais rápido;
- O iOS Simulator é muito rápido e tornou o ciclo de desenvolvimento muito mais eficiente. Para cada trecho de código novo eu iniciava os testes com o simulador e somente trocava para o dispositivo quando estivesse mais completo;
- Eu tinha dispositivos Android de teste para cada versão do sistema operacional que o aplicativo suportava (exceto o Gingerbread), então confiava fortemente em meus testadores beta para atingir uma cobertura de testes suficiente;
- Para os testes no iOS foram usados os mais velhos e mais novos dispositivos suportados.
Design do aplicativo
Henneke planejou criar o design de seu aplicativo de forma que se adaptasse facilmente a diversos tamanhos de tela, pois descobriu que a plataforma Android possui "componentes maduros para ajudar os desenvolvedores a suportar a variedade de dimensões existente". Ele utilizou o RelativeLayouts, percebendo que "todos os layouts são especificados em XML, o que é uma maneira bastante limpa, simples e eficiente de projetar telas" (uma característica que só foi apreciar totalmente após a criação dos layouts para o iOS).
Nesse contexto, perguntamos a Henneke o que ele pensa a respeito da fragmentação do Android:
Penso que a fragmentação do Android é muito sensacionalista. Isso realmente existe? Certamente isso é um fato. Isso é necessariamente um aspecto ruim do desenvolvimento para Android? Na verdade, não. O Google e a comunidade Android adotaram muitas abordagens para enfrentar esse desafio e isso está funcionando. A biblioteca de suporte oficial é bastante abrangente e continua crescendo. A biblioteca ActionBarSherlock é bastante poderosa para acrescentar novas funcionalidades a dispositivos antigos. Além disso, a introdução recente do Google Play Services tiraram as operadoras para fora da equação da fragmentação. Os usuários não têm mais que confiar em suas operadoras para baixar a última versão do Android e ter acesso às novas funcionalidades. Isso é um passo enorme, tanto para os usuários Android quanto para os desenvolvedores.
Curiosamente, a experiência de Henneke com layouts no iOS não foi tão boa:
O Auto Layout, a ferramenta da Apple análoga ao RelativeLayouts, é bastante nova (introduzida no iOS 6) e sua integração com o Interface Builder (IB) é horrível. Gastei dias lutando contra o Auto Layout no IB - assim como todo desenvolvedor iOS 6 (1, 2, 3), para construir restrições precisas para views e tendo que ver o IB mudar completamente todas as minhas especificações por causa de seu sistema "inteligente" de manter os layouts constantemente não-ambíguos. Aprendi sem sucesso todas as dicas e truques para lidar com essa parte frágil do IB. Finalmente acabei com o sofrimento ao tirar todos os layouts do IB e simplesmente escrevê-los à mão com páginas e páginas de código repetitivo. Se evitar o IB e o estilo artístico de codificar layouts baseado em ASCII, a implementação do Auto Layout é na verdade muito poderosa e simples de usar. Acredito que a Apple melhorou bastante isso no iOS 7, mas ainda preciso testar.
O Auto Layout limitou apenas o desenvolvimento para iOS 6 (iPhone 4 e 5), mas não os mais antigos, como Henneke contou:
O aplicativo GQueues não pode ser de fato instalado ou executado em dispositivos antigos da Apple. Esse é o motivo de eu não ter testado neles. Quando um aplicativo é desenvolvido, um passo inicial é decidir quais versões do sistema operacional serão suportadas. O iOS 6 introduziu uma nova funcionalidade chamada Auto Layout que foi uma grande melhoria sobre as técnicas de layout anteriores. Mas, é claro, essa funcionalidade somente funcionou em dispositivos que rodam a última versão do sistema operacional. Decidi que, em vez de criar layouts usando tanto o antigo método quanto o Auto Layout, iria usar apenas este último, reduzindo drasticamente o tempo de desenvolvimento. Isso significa, é claro, que o aplicativo GQueues somente funciona em dispositivos que rodam o iOS 6, ou seja, em todos os dispositivos da Apple lançados nos últimos dois anos. Imagino que qualquer pessoa com um telefone com mais de dois anos provavelmente irá trocá-lo em breve de qualquer forma. Então, fazendo isso, eu não estava realmente limitando muito o meu mercado.
Outras conclusões sobre design foram:
- "Suportar rotação de dispositivos no Android requer bastante trabalho e é fonte de muitos bugs";
- Quando um dispositivo Android é rotacionado, ele essencialmente finaliza toda a pilha de views e recria cada uma delas quando a rotação se completa. Então, para suportar rotação com o aplicativo GQueues, precisei garantir que o estado atual de todas as coisas pudesse ser armazenado a qualquer momento e restaurado ao retomar";
- "[Para rotação] o iOS requer apenas um pequeno esforço enquanto a plataforma faz o resto";
- "Com iOS, a plataforma gerencia quase todas as preocupações com rotação para você";
- Tanto o Android quanto o iOS precisam de código adicional para simular um Flow Layout.
Em relação aos testes beta e publicação, Henneke faz os seguintes comentários:
- "Testar direto no Android foi tão simples quanto postar um link para um APK (Android Package) que pudesse ser baixado para o dispositivo";
- "O Google tornou ainda mais fácil testar aplicativos com usuários reais ao suportar testes de versões alpha e beta no Developers Console e lançamento gradual (staged rollout)";
- "Os testes beta no iOS foram muito mais difíceis, embora estivesse usando o serviço TestFlight, o qual simplifica bastante o processo. Alinhado ao apetite insaciável da Apple por controle, o UDID de cada dispositivo utilizado para testes deve ser adicionado ao certificado usado para assinar a versão beta do aplicativo. Consequentemente, cada vez que precisava adicionar novos testadores beta, seja uma única pessoa ou um novo grupo, tive que criar e distribuir uma nova compilação do aplicativo. Além disso, a Apple limita a 100 a quantidade de dispositivos de teste registrados por ano. Por esse motivo, tive que alocar cuidadosamente minhas vagas, que é a razão pela qual possuia apenas a metade do número de testadores iOS comparado com Android";
- "Publicar o aplicativo GQueues no Google Play foi uma verdadeira alegria. Fui capaz de lançar o aplicativo assim que decidi que estava pronto. Cliquei no botão e em 30 minutos já estava disponível no Google Play para os clientes de todo o mundo instalarem em seus aparelhos";
- "A publicação de aplicativos na App Store, como quase todos os desenvolvedores de iOS podem atestar, é uma experiência desmoralizante. Depois de meses de intensa e rigorosa codificação, fui forçado a submeter minha criação para a Apple e esperar sete dias para que o revisor (em dois minutos) olhasse para o aplicativo e desse a "quase obrigatória" rejeição inicial. Depois disso, passei um dia fazendo as alterações necessárias, submeti novamente e esperei mais oito dias antes de finalmente obter aprovação".
Henneke também fez uma série de anotações sobre o uso de armazenamento e gerenciamento de dados, busca, expressões regulares, paginação, entrada de voz, compartilhamento e widgets em ambas as plataformas e podem ser encontradas no blog do GQueues.
Como conclusão, Henneke não considera uma plataforma melhor que a outra. Cada uma possui "áreas nas quais são realmente mais fortes e maduras, e outros aspectos que definitivamente precisam de melhorias".
Também perguntamos a Henneke sobre quais funcionalidades ele gostaria de ver no iOS e no Android:
Eu adoraria ver no iOS uma API para SIRI, ou pelo menos reconhecimento de voz. Em relação ao Android, algumas integrações mais profundas com o Google Now seria muito legal.
Por fim, mas não menos importante, perguntamos a Henneke o quê motivou a mudança de HTML5 para aplicação nativa. Em sua experiência, o HTML5 ainda não está maduro o suficiente:
Considerando que fui um defensor público do HTML5, decidi escrever um post explicando minha mudança drástica na estratégia para construir aplicativos nativos. Em suma, o HTML5 ainda tem que fornecer as funcionalidades e velocidade necessárias para torná-lo uma alternativa competitiva para aplicativos nativos. Além disso, para melhor ou pior, as pessoas gostam de baixar aplicativos. O usuários do GQueues estavam exigindo aplicativos nativos, então me propus a atender essa necessidade.
Considerando que este post reflete somente a experiência de apenas uma pessoa desenvolvendo aplicativos para Android e iOS, ele não pode ser generalizado e servir de base para tirar conclusões definitivas sobre o desenvolvimento nas respectivas plataformas, especialmente sobre qual é melhor ou pior. No entanto, muitos dos comentários de Henneke são válidos, expressando algumas das alegrias e tristezas que acompanham o desenvolvimento de aplicativos móveis nas duas plataformas mais populares do mercado.