Mobile Apps — Desmistificando Apps Nativas
Importância da escolha da tecnologia
Embora possa parecer uma questão secundária quando uma empresa decide avançar para a criação de uma aplicação móvel, a escolha da tecnologia em que esta vai ser desenvolvida é particularmente importante no futuro estratégico da mesma.
Enquanto que ao construir um website, todas as tecnologias permitem desenvolver tudo o que se pretenda com maior ou menor dificuldade, no mundo das aplicações móveis, desenvolver uma aplicação em linguagens nativas ou não nativas tem grandes diferenças pelo meio.
Já aqui escrevemos há alguns meses quais as principais diferenças entre as duas abordagens, mas neste artigo vamos aprofundar as vantagens de desenvolver aplicações em linguagens nativas, entenda-se, Swift (iOS) e Kotlin (Android).
1. O que é o desenvolvimento em linguagem nativa?
Entende-se por desenvolvimento em linguagem nativa quando são utilizadas linguagens criadas justamente para “falar” diretamente com o sistema operativo do dispositivo móvel onde as aplicações estão a correr e que hoje em dia são essencialmente dois: Android (da Google) e iOS (da Apple).
Quando dizemos que as linguagens “falam” diretamente com o sistema operativo significa que não existem intermediários pelo meio a traduzir aquilo que é codificado para ser percebido pelo sistema operativo, algo que acontece em todas as linguagens não-nativas, sejam elas Hibridas ou Cross Platform.
Atenção que muitas vezes estas plataformas anunciam que produzem aplicações nativas o que é verdade apenas na medida do package final que é gerado, uma vez que as stores da Google e Apple apenas aceitam packages de uma determinada característica. No entanto, o que vai dentro deste package é completamente diferente se for desenvolvido em linguagens nativas e não-nativas mas é justamente o conteúdo desses packages que faz toda a diferença, porque é isso que será interpretado pelo sistema operativo de cada dispositivo móvel.
2. Virtudes das aplicações nativas
- Rapidez
Por definição, não sendo necessário ter intermediários seja no que for, a comunicação passa a ser mais rápida, clara e sem obstáculos. Assim, as aplicações implementadas em linguagens nativas serão sempre mais rápidas traduzindo-se numa melhor experiência para quem as utiliza.
- Sem limites
Adicionalmente, não existem limites técnicos naquilo que se pode fazer, a não ser os físicos colocados pelo próprio hardware. Uma vez que a linguagem de programação fala diretamente com o sistema operativo, todas as capacidades do mesmo podem ser utilizadas em benefício do que se pretende que a app faça, ao contrário do que acontece nas outras linguagens em que só se pode implementar o que a framework da linguagem permite.
- Recursos humanos
As linguagens nativas já existem desde a origem das próprias plataformas, pelo que não faltam também developers com muita experiência nestas linguagens. Pelo que, seja do ponto de vista do fornecedor de outsourcing, quer do ponto de vista da empresa que queira ter este conhecimento in-house, a existência de recursos humanos competentes nunca será um problema.
Para aplicações relativamente simples, que possam ser totalmente feitas em linguagens de base Web, é exequível ter uma equipa que perceba só de tecnologias não nativas, normalmente Web, ainda que mesmo assim há que ter o know-how mínimo para gerar os packages finais, publicação e gestão das stores.
No entanto para aplicações mais complexas que requerem acesso às funcionalidades dos equipamentos, é normalmente necessário ter uma equipa de developers que conheça nativo, pois estas funcionalidades não são fornecidas Out of the Box nas soluções não nativas.
- Documentação
Seja por via da bastante detalhada documentação das empresa criadoras das linguagens, Google e Apple, seja por via das inúmeras comunidades espalhadas pela web, não falta documentação e até mesmo código já pré-feito e pronto a ser reutilizado e customizado, desenvolvido em linguagens nativas.
- Bibliotecas de terceiros
Devido à vasta comunidade e à facilidade de desenvolvimento nestas linguagens, existem inúmeras bibliotecas desenvolvidas e mantidas pela comunidade que permitem acelerar o desenvolvimento e implementar funcionalidades, layouts e animações que de outra forma implicariam um esforço bastante superior. Acima de tudo, a vasta comunidade que apoia o desenvolvimento nativo permite que a grande maioria destas bibliotecas se mantenham activas com o passar dos anos.
- Operating system seamless
As aplicações desenvolvidas em linguagens nativas são mais resistentes às mudanças provocadas pelo upgrade de sistemas operativos. Mesmo havendo alterações que quebrem o funcionamento das aplicações, o que não costuma acontecer, estas mudanças são sempre mais fáceis de corrigir quanto mais perto do código nativo se desenvolver. Esta evidência vem do facto que sempre que existe um upgrade no sistema operativo, as frameworks que permitem o desenvolvimento não nativo também têm de se actualizar, o que pode demorar algum tempo ou até acrescentar novos bugs latentes.
3. Desmistificando o desenvolvimento em linguagens nativas
A imagem que marca mais a perceção das tecnologias nativas nas pessoas que conhecem tecnologias não-nativas é de que o esforço e custo do projeto é o dobro comparativamente a ser desenvolvido numa tecnologia não-nativa.
Embora o esforço e custo do desenvolvimento nativo seja superior ao de uma tecnologia não-nativa, a diferença está longe de ser o dobro. Um projeto é composto por diversas fases e muitas delas são comuns e decorrem da mesma forma seja qual for a tecnologia usada no projeto. A definição, especificação e design são exemplos de fases que têm um custo e esforço igual seja a app nativa ou não-nativa.
Na fase de testes também não há ganhos em se usar uma tecnologia não-nativa. A utilização de uma tecnologia de código único para ambas as plataformas não implica que a app só tenha que ser testada numa das plataformas. Cada sistema operativo tem as suas próprias especificidades e por vezes um layout ou funcionalidade que está OK num dos sistemas operativos pode não estar a funcionar no outro sistema.
Mesmo na fase de desenvolvimento, nem todo o desenvolvimento acontece a dobrar em tecnologias nativas. Nas linguagens não-nativas, existem várias funcionalidades que têm que ser desenvolvidas nativamente em específico para cada sistema independentemente da tecnologia usada. Alguns exemplos dessas funcionalidades são as que usam recursos de hardware específicos para cada sistema (como GPS, smartwatches, sensores, pagamentos, autenticações biométricas, etc.). Essas também são as funcionalidades que mais risco correm de sofrer alterações quando existe uma nova versão de cada sistema operativo. Adicionalmente, estas funcionalidades são geralmente mais fáceis e rápidas de implementar em nativo, tendo em conta a quantidade superior de bibliotecas desenvolvidas por terceiros e todo o apoio da comunidade. Mas não é apenas a integração destas capacidades mais complexas que obriga a utilização de módulos desenvolvidos em linguagens nativas. Muitas vezes uma qualquer funcionalidade mais simples como uma lista, uma grelha, um formulário, etc… que pela especificidade dos requisitos ou quantidade de dados envolvida, ou até pelo desejo de ter uma interactividade bastante avançada pode ser suficiente para se ter de optar pelo desenvolvimento desse módulo em nativo para cada sistema operativo.
No que toca a recursos de hardware para desenvolvimento, continua a ser um requisito ter um Macbook ou iMac para que seja possível testar e gerar versões de iOS. A Apple tem um ecossistema fechado e não permite que aplicações iOS sejam compiladas ou simuladas em Windows.
Da mesma forma, a publicação é sempre feita em separado, em cada uma das stores, seja qual for a tecnologia. O tempo e esforço envolvido nesse processo não difere entre uma abordagem nativa ou não nativa. Cada store tem as suas próprias especificidades e regras o que faz com que os recursos envolvidos no desenvolvimento tenham de ter conhecimentos e experiência em ambos.
4. Desmistificação do tempo/calendário de um projeto nativo
Outra das questões que marca a percepção das pessoas quanto às tecnologias nativas é que, devido ao desenvolvimento ter de ser feito em duplicado, isso signifique que em calendário será necessário também o dobro do tempo. Isso não tem de ser necessariamente assim conquanto haja recursos para isso.
O facto de uma app nativa ter que ser desenvolvida em separado para iOS e Android não implica que o tempo de calendário seja superior ao de uma app não nativa. São vários os motivos pelos quais conseguimos garantir um calendário equivalente, ou até mesmo inferior ao de uma app não nativa:
- Fases do projecto partilhadas
Como falámos na secção anterior, existem várias fases durante a concepção de uma app que são independentes da tecnologia. O tempo usado na especificação, design e testes é igual independentemente da tecnologia escolhida.
- Paralelismo entre Android e iOS
Tendo recursos especializados em cada plataforma, é normal que o desenvolvimento de Android e iOS decorra em paralelo o que implica que ambas as aplicações possam estar terminadas ao mesmo tempo. Até a própria sinergia de termos duas pessoas a desenvolver a mesma coisa ao mesmo tempo significa termos duas pessoas a pensar o mesmo módulo e resultar na escolha da abordagem mais eficiente, apenas desenvolvida em linguagens diferentes e por alguém especializado em cada uma delas que só tem de se preocupar com o correto funcionamento num sistema operativo e não em dois.
- Não necessidade de desenvolvimento de componentes genéricos
De forma a que seja possível realizar a visão de uma app através de uma tecnologia não nativa, é muito normal surgir a necessidade de desenvolvimento de componentes genéricos (não providenciados pela tecnologia) em várias fases do projeto. Estes componentes são tipicamente desenvolvidos em dois momentos — na tecnologia não nativa e de seguida por código nativo de cada plataforma suportada. Estes desenvolvimentos extra são difíceis de paralelizar o que implica um impacto direto em calendário.
Quando a app é desenvolvida em nativo de raiz, estes componentes são mais fáceis de desenvolver e paralelizar pois já estamos a trabalhar diretamente na camada nativa.
- Mais bibliotecas externas
Devido à vasta comunidade à volta das tecnologias nativas, é muito comum existirem bibliotecas externas que facilitam e encurtam a implementação de diversas funcionalidades numa app nativa o que tem um impacto positivo no calendário.
Em tecnologias não-nativas, estas bibliotecas são mais difíceis de encontrar (em especial, bibliotecas estáveis com um bom suporte de manutenção e evolução). Mesmo quando existem, é muitas vezes necessário adaptá-las para que funcionem corretamente com a tecnologia não nativa. Essa adaptação também tem um custo negativo no calendário.
5. Desmistificação dos recursos necessários (humanos e técnicos)
Outra pré-conceito criado em relação ao desenvolvimento de aplicações nativas quando comparado com o desenvolvimento em tecnologias hibridas é que precisa do dobro dos recursos humanos pois existem dois códigos para manter, um para Android e outro para iOS e a necessidade de hardware Apple. As tecnologias hibridas fornecem mais liberdade de desenvolvimento, permitindo a pessoa escolher o sistema operativo onde quer desenvolver. Isto parecer verdade à primeira vista, mas vejamos:
- Aplicações hibridas com código nativo
Como já vimos, apesar do propósito das tecnologias híbridas ser uniformizar o código desenvolvido num aplicação, ainda existem diversas circunstâncias onde pode ser preferível, ou até mesmo necessário adicionar funcionalidades com código nativo. Logo, terá de existir esse conhecimento das equipas e normalmente um conhecimento já aprofundado, porque estas necessidades surgem habitualmente em funcionalidades complexas;
- Comprar um Mac
Um custo que se torna indispensável é a compra de um Mac. Apesar de algumas plataformas hibridas fornecerem um IDE que permite o desenvolvimento em Windows, é sempre necessário ter um Mac para compilar código de aplicações iOS. Esta regra serve para reforçar o uso do ecossistema Apple quando se desenvolve em nativo e previsivelmente não deverá ser alterado.
Outro fator importante para a compra de um Mac é referente à geração dos certificados. Estes ficheiros, usados para garantir a autenticidade da aplicação na altura do desenvolvimento e da distribuição do mesmo nas lojas, podem ser gerados automaticamente pelo IDE XCode, que só existe no sistema operativo MacOS, ou podem ser gerados manualmente usando a keychain do MacOS. Existem duas formas de fazer o upload do binário da aplicação iOS para a Apple Store: através da aplicação Transporter ou através do IDE XCode. Ambas as soluções são exclusivas do ambiente MacOS;
- Publicação nas lojas
No final do desenvolvimento de uma aplicação, caso não se esteja simplesmente a vender o código de uma aplicação, é necessário fazer a distribuição da mesma. Para tal também será necessário ter conhecimentos das lojas de ambos os sistemas operativos. Conhecimento este que é mais fácil encontrar em developers nativos. Não se trata apenas de fazer o upload do ficheiro. Há certificados para gerir, configurações de base na aplicação que têm de ser respeitadas, até mesmo saber responder a reprovações no processo de validação da store entre outras atividades.
Em suma, desenvolver em linguagens não-nativas não retira a necessidade de ter pelo menos algum conhecimento e condições típicos de quem desenvolve em nativo.
6. O que é que apenas pode ser feito em nativo?
Independentemente da aplicação utilizar uma tecnologia nativa ou não nativa, existem algumas funcionalidades que apenas podem ser desenvolvidas em código nativo. As tecnologias não-nativas são limitadas pelo quantidade de frameworks e layouts que conseguem abstrair em ambas as plataformas, ou seja, o mínimo denominador comum entre Android e iOS que não tem dependência das capacidades de hardware do dispositivo.
Existem no entanto formas de contornar a limitação dado que a grande parte das tecnologias não nativas suportam a integração de plugins (desenvolvidos em código nativo) que permitem colmatar falhas no suporte deste tipo de funcionalidades. No entanto, a implementação destes plugins implica conhecimento e experiência de desenvolvimento nativo em ambas as plataformas. De igual forma, é necessário que o desenvolvimento seja feito em paralelo, tanto em Android como em iOS, o que tem um impacto direto em projetos que dependem demasiado neste tipo de funcionalidades.
- Performance
Uma boa performance é um dos principais pilares que apenas é possível atingir em desenvolvimento nativo. Este ponto é especialmente verdadeiro quando estamos a falar de ecrãs complexos, que necessitam carregar e renderizar grandes quantidades de informação em pouco tempo e de uma forma seamless para o utilizador. Alguns exemplos de ecrãs ou funcionalidades são: Guias de TV (com uma grelha completa de canais de TV e programação dos mesmos para um grande espaço de tempo), scanner para cartões de cidadão e passaportes, video players customizados, editores de imagens, etc.
Embora alguns dos exemplos dados acima sejam possíveis de desenvolver em tecnologias não-nativas, o que não é possível atingir é uma performance satisfatória, fluida, livre de loadings e que não traga frustração ao utilizador.
- Animações
É também nas animações que há grandes ganhos na utilização das tecnologias nativas. São estes pequenos detalhes que fazem a diferença e trazem um factor “wow” à aplicação. Em código não nativo, não é possível programar animações de uma forma tão complexa e rica como em código nativo. É também apenas em código nativo que conseguimos fazer com que as animações tenham uma performance aceitável e não se transformem num factor deteriorante da experiência do utilizador.
- Frameworks de Maps e Location Tracking
Implementações complexas de mapas também só podem ser garantidas em código nativo. As tecnologias não-nativas limitam-se a abstrair o mínimo denominador comum entre as interfaces de mapas da Apple e da Google. Quando é preciso ir mais além do básico (quer para o uso de clustering, desenho em cima dos mapas, carregamento de muitos pontos, etc.) é necessário que sejam feitos desenvolvimentos em específico para cada plataforma.
É também na utilização das frameworks de location tracking que precisamos recorrer ao desenvolvimento nativo. Cada sistema faz a sua própria gestão destes recursos e tem também as suas próprias regras de permissões, frequência (com que são recebidos os pontos) e comportamentos diferentes com a app ligada e desligada. É então necessário que esta integração seja feita em código nativo para garantir que a mesma fica implementada da forma correcta e com o comportamento espectável.
- Wearables
Cada plataforma tem o seu set de SmartWatches, cada um com a sua própria interface e especificidades. A abstracção do desenvolvimento para smartwatches simplesmente não é possível dadas todas as diferenças entre os sistemas. Como tal, para a implementação de apps para smartwatches é sempre necessário desenvolvimento nativo.
Mesmo para wearables que não sejam Android ou Apple, a integração tem que ser feita através dos SDK’s providenciados pelas respectivas marcas. Muitas dessas marcas apenas têm SDK’s nativos o que dificulta imenso a integração com apps não nativas. Para que seja possível integrar um SDK’s nativos com tecnologias não nativas, é necessário que seja desenvolvida uma camada de abstracção, que terá depois de ser mantida pela própria equipa de desenvolvimento cada vez que existir uma alteração ao SDK.
- In-App Purchases
As In-App Purchases são outro exemplo de funcionalidades que apenas podem ser desenvolvidas nativamente. Cada sistema tem a sua própria versão das In-App Purchases que passam por uma integração com as respectivas stores, onde são configuradas as listas de in-app purchases que ficarão disponíveis na app. A implementação desta funcionalidade implica não só código nativo como um bom conhecimento de cada uma das stores.
- Augmented Reality
A implementação de funcionalidades de realidade aumentada apenas podem ser desenvolvidas em código nativo. Cada plataforma tem as suas próprias especificidades o que implica que as tecnologias não nativas não conseguem abstrair esta funcionalidade.
7. Como podemos ter uma app nativa mais barata?
Já se percebeu pelos capítulos anteriores que a definição de “barata” tem de ser compreendida olhando para todo o ciclo de vida de uma aplicação. Uma aplicação que custe menos dinheiro na sua primeira fase de concepção e publicação na store não significa que mais tarde para mantê-la e evoluí-la não se vá gastar muito dinheiro. Nestes cenários, é também o tempo efectivo de desenvolvimento que poderá ser excessivo em tarefas que na verdade contribuem pouco para aquilo que é a experiência dos utilizadores (actualização de plugins ou bibliotecas externas pouco adaptativas aos constantes updates dos sistemas operativos e das próprias bibliotecas). Podem também existir custos acrescidos, por exemplo, em encontrar recursos competentes nas linguagens menos utilizadas em que a aplicação está feita.
Aplicações desenvolvidas em linguagens nativas não têm estes problemas mas carecem que a app seja desenvolvida em dois sistemas operativos pelo que não há volta a dar, vai haver um esforço de desenvolvimento superior em relação a outras linguagens. Assim, se quisermos reduzir o custo nesta primeira fase de desenvolvimento, ou contratamos empresas com mão-de-obra barata (o que é um risco para a qualidade final da aplicação), ou então, diminuimos o tempo de implementação. E isto consegue-se de duas formas: ou por via ou da simplificação das funcionalidades ou pelo desenvolvimento de menos funcionalidades mas que essas sejam verdadeiramente uma mais valia para quem utiliza a app.
Quem recorre a apps não quer perder muito tempo a clicar em muitos menus e botões, nem quer ler muita coisa, nem preencher formulários muito grandes. Uma aplicação não precisa de ter toda a arquitetura de informação dos sites associados. Hoje em dia, esses sites já são tipicamente responsive o que faz com que seja mais eficiente remeter os utilizadores para o site onde esse conteúdo já está disponível. Adicionalmente, há que aproveitar as capacidades únicas de um dispositivo móvel. Desde logo o facto de ser móvel significa que está acessível em qualquer momento e em qualquer lugar, o que é uma vantagem. Os sites responsive podiam ser uma alternativa mas nunca estão ao alcance de um touch, não são rápidos e a usabilidade, por mais cuidada que seja, nunca será tão boa como o de uma boa app, principalmente nativa. E depois há as outras features como a geolocalização, utilização da camara para fotografia, AR, leitura QR Codes, o modo offline, etc… que podem e devem ser o fator diferenciador da experiência numa aplicação móvel. Como também já vimos, são ferramentas que só podem ser exploradas na sua totalidade e com poucos limites pelas linguagens nativas.
Finalmente, uma estratégia valida para qualquer software que se desenvolva, é ir adicionando funcionalidades de forma gradual, diluindo o investimento no tempo.
Conclusão
Não pretendemos com este artigo diabolizar as linguagens não-nativas.
A perceção de que as aplicações móveis são uma mais valia para as organizações é indiscutivel e, dependendo do contexto, há espaço para se utilizarem linguagens de programação diversas.
O que pretendemos sim é contribuir para que essa decisão seja o mais informada possível e livre de preconceitos, muitas vezes erróneos.
“The future of mobile is the future of online. It is how people access online content now.”
– David Murphy, Founder and Editor of Mobile Marketing Daily
Mobile Business Unit
INNOVAGENCY
Living the digital world
www.innovagency.com
Head Mobile Business Unit
Daniel Pereira
dpereira@innovagency.com
LinkedIn: http://www.linkedin.com/in/djvpereira/
