Aplicações Móveis

Aplicações móveis que as pessoas mantêm no telemóvel

Multiplataforma por defeito, nativo quando se justifica — e, antes disso, uma resposta honesta sobre se precisa mesmo de uma app.

Comece por perceber se precisa de uma app

A coisa mais útil que podemos fazer no início de um projeto móvel é questioná-lo. Uma app é um segundo produto para desenhar, publicar, submeter a revisão, atualizar e suportar, em duas plataformas, para sempre. Esse custo compensa quando a app o justifica — e desperdiça-se quando um bom site móvel fazia o mesmo trabalho.

Uma app justifica-se quando as pessoas voltam com frequência, quando é preciso o telemóvel em si — notificações, câmara, localização, leitura de códigos, uso real sem rede — ou quando a app é o produto e não a montra dele. Se o objetivo é ser encontrado, explicar o que faz e receber contactos, um site é o melhor investimento e dizemos isso.

Quando a app faz sentido, a pergunta seguinte é como construí-la. Para a maioria das apps de empresa a resposta é multiplataforma: um código para iOS e Android, tipicamente um terço a metade mais barato do que construir duas vezes. O nativo compensa em casos específicos, e dizemos-lhe quando o seu é um deles.

Como construímos

Apps multiplataforma (React Native e Flutter)

Um código, as duas plataformas. Para a larguíssima maioria das apps de empresa, a diferença de desempenho face ao nativo é pequena ao ponto de os utilizadores nunca darem por ela, enquanto a poupança na construção e na manutenção é substancial e permanente.

Usamos React Native por defeito, porque partilha competências e muitas vezes código com uma stack React na web — o que pesa mais ao fim de cinco anos do que qualquer teste de desempenho. O Flutter é a melhor escolha quando a interface é o produto: muita animação, um sistema de design igual ao pixel nas duas plataformas.

  • Um código para iOS e Android
  • React Native por defeito, Flutter quando a interface é o produto
  • Competências partilhadas com a stack web
  • Uma atualização chega às duas plataformas

Nativo iOS e Android

Swift e Kotlin, construído por plataforma. Custa mais a fazer e cerca do dobro a manter, por isso precisa de uma razão que não seja preferência.

Razões existem: interfaces com gráficos pesados ou 3D, realidade aumentada ou visão computacional no dispositivo, precisar de uma API da plataforma no dia em que sai, ou produtos em que a latência é o ponto — ferramentas profissionais de câmara e áudio. Se estiver num desses casos, dizemos.

  • Swift para iOS, Kotlin para Android
  • Acesso total às APIs da plataforma desde o primeiro dia
  • A escolha certa para gráficos, RA e latência crítica
  • Assumimos com clareza o custo maior de construir e manter

Quando uma aplicação web é a melhor resposta

O nativo já não é o ponto de partida. Uma aplicação web progressiva é encontrada em pesquisa, abre a partir de um link, não exige instalação, evita a comissão das lojas e atualiza no momento em que publica.

Cede algum terreno: acesso profundo ao hardware, trabalho em segundo plano, e as notificações no iOS continuam mais fracas do que no Android. Uma boa resposta frequente é ter ambos — uma aplicação web para alcance e uma app nativa pequena para quem a usa todos os dias.

  • Encontrável em pesquisa, sem instalação
  • Sem comissão nem espera por revisão
  • Atualiza no momento em que publica
  • Combina bem com uma app nativa focada

Funcionamento offline e tempo real

Os telemóveis perdem rede. Uma app que assume ligação falha exatamente onde as equipas no terreno trabalham — caves, armazéns, zonas rurais, em deslocação. Offline-first significa que a app continua utilizável e reconcilia quando a ligação volta.

A parte difícil é a reconciliação, não guardar os dados: decidir o que acontece quando duas pessoas alteraram o mesmo registo sem rede. Definimos essa regra consigo, em vez de deixar que a última gravação vença em silêncio.

  • Utilizável sem ligação
  • Regras de sincronização e conflito definidas à partida
  • Atualizações em tempo real onde são precisas
  • Notificações que respeitam a atenção das pessoas

Lançamento nas lojas e o que vem depois

Entrar na App Store e na Play Store é um processo com regras próprias: linhas de orientação de revisão, declarações de privacidade, formulários de segurança de dados, classificação etária, versões de teste para a sua equipa.

E depois continua. A Apple e a Google lançam versões do sistema todos os anos e sobem periodicamente os requisitos mínimos, por isso uma app deixada como está acaba por deixar de ser aceite. A manutenção não é opcional, e dizemos quanto custa antes de avançar.

  • Submissão à App Store e Play Store
  • Declarações de privacidade e segurança de dados
  • Versões de teste para a equipa antes de publicar
  • Atualizações de sistema e SDK depois do lançamento

A sua empresa precisa mesmo de uma app?

A versão honesta. Muitas empresas que nos pedem uma app ficam melhor servidas com outra coisa, e sai mais barato descobrir isso agora.

Uma app justifica-se quando

  • As pessoas usam com frequência — todas as semanas ou todos os dias
  • É preciso o telemóvel: notificações, câmara, localização, leitura de códigos, sensores
  • Tem de funcionar sem rede e sincronizar depois
  • A app é o produto, e não uma montra dele
  • Precisa de estar no ecrã inicial para manter o hábito

Um site é o melhor investimento quando

  • O objetivo é ser encontrado, explicar e receber contactos
  • As pessoas usariam uma ou duas vezes por ano
  • O conteúdo muda constantemente e a pesquisa importa
  • Não há orçamento para manutenção depois do lançamento
  • A principal razão é a concorrência ter uma

Como trabalhamos

Ciclos mais curtos do que na web, porque a revisão das lojas fica entre si e os seus utilizadores.

  1. 01

    Âmbito

    Definimos para que serve a app, quem a usa e o que a primeira versão tem mesmo de fazer. O que pode esperar, espera — uma primeira versão menor chega mais cedo a utilizadores reais.

  2. 02

    Design

    Ecrãs e fluxos validados em protótipo navegável, respeitando as convenções de cada plataforma em vez de forçar o mesmo desenho nas duas.

  3. 03

    Construção e testes

    Versões de teste regulares nos vossos próprios dispositivos, não apenas em simulador, para usar a app no telemóvel que traz consigo.

  4. 04

    Lançamento e manutenção

    Tratamos da submissão e da revisão, e mantemos a app atualizada à medida que o iOS e o Android evoluem por baixo dela.

Tecnologia

Escolhemos a tecnologia em função da app, e não o contrário, mantendo-nos em ferramentas amplamente adotadas para que a app continue a poder ser mantida por qualquer equipa competente.

Multiplataforma

React NativeFlutterTypeScript

Nativo

SwiftKotlin

Backend

FirebaseAWS AmplifyAPIs RESTNotificações push

Onde uma app costuma justificar-se

Situações em que o telemóvel acrescenta algo que um site não consegue. São exemplos ilustrativos do tipo de trabalho que fazemos.

Equipas no terreno

Técnicos a registar intervenções, fotografias e assinaturas no local, a trabalhar sem rede e a sincronizar quando voltam a ter cobertura.

App de acompanhamento para clientes

Uma app para clientes existentes seguirem encomendas, marcações ou entregas, em que a notificação substitui uma sequência de e-mails.

Marcações e fidelização

Negócios a que as pessoas voltam com frequência, onde um ícone no ecrã inicial e um lembrete valem mais do que mais um separador no browser.

Leitura de códigos e inventário

Stock, ativos ou bilhetes verificados com a câmara do telemóvel, quando a alternativa é equipamento dedicado ou papel.

Perguntas frequentes

Quanto custa desenvolver uma aplicação móvel?

Depende do âmbito e não da plataforma: número de ecrãs, quanto backend, quantas integrações. O multiplataforma fica tipicamente bastante abaixo de construir a mesma app duas vezes em nativo, e é essa a principal razão para ser o nosso ponto de partida. Definimos o âmbito e apresentamos um valor concreto, em vez de estimar antes de perceber a app.

Multiplataforma ou nativo?

Multiplataforma para a maioria das apps de empresa — os utilizadores não notam a diferença e reduz para metade a manutenção a longo prazo. Nativo quando a app tem gráficos pesados, assenta em realidade aumentada ou visão no dispositivo, precisa de APIs acabadas de sair, ou quando a latência é o produto. Dizemos com franqueza de que lado cai o seu caso.

Precisamos de uma app ou basta um site?

Muitas vezes basta um site. Se as pessoas visitassem uma ou duas vezes por ano, ou se o objetivo é ser encontrado e explicar o que faz, um bom site móvel é melhor investimento. Uma app justifica-se por uso repetido, necessidade do hardware do telemóvel, uso real sem rede, ou por a app ser o próprio produto.

Quanto tempo demora?

Uma primeira versão focada demora tipicamente alguns meses, mais a revisão das lojas. Mantemos deliberadamente pequena a primeira versão, porque utilizadores reais em telemóveis reais dizem mais sobre o que construir a seguir do que mais um mês de planeamento.

De quem é a app e o código?

Vossos. O código, os dados e as fichas nas lojas pertencem à vossa empresa. Publicamos sob as vossas contas de programador e não sob as nossas, para que nunca fiquem sem acesso à vossa própria app.

Quanto custa manter depois do lançamento?

O móvel tem um custo de base que a web não tem: iOS e Android saem todos os anos e sobem periodicamente os requisitos mínimos, por isso uma app deixada como está acaba por deixar de ser aceite. Combinamos o modelo de manutenção antes do lançamento, para ser um custo conhecido e não uma surpresa.

Áreas relacionadas

Serviços que costumam fazer parte do mesmo projeto.

Artigos relacionados

O que escrevemos sobre desenvolvimento de apps.

Está a pensar numa app?

Diga-nos o que faria e quem a usaria. Respondemos com uma leitura honesta sobre se a app é o passo certo e o que seria preciso para a construir.