Apps que ficam no ecrã inicial.
Apps iOS nativas, Android e multiplataforma — offline-first, instrumentadas, e polidas ao nível que faz as pessoas voltar depois da primeira semana.
Os downloads da primeira semana são fáceis. A retenção na semana cinquenta e dois é engenharia.
A maioria das apps são abandonadas em poucos dias — não porque a ideia era má, mas porque a app estava lenta num Android de três anos, perdia dados em zona sem rede, ou importunava com notificações que ninguém queria. A retenção não é um problema de marketing; é um padrão de engenharia.
As nossas apps fazem girar empresas: frigoríficos desbloqueados por leitura às 3 h da manhã, entradas ao serviço picadas por NFC em dezenas de locais, refeições pagas em dois toques. A sincronização offline-first, os pagamentos nativos e a analítica são fundações em cada build — porque é isso que exige a sobrevivência num ecrã inicial.
Entregue nas duas lojas.
Seja qual for a estratégia de plataforma, o padrão é idêntico: rápido, utilizável offline, instrumentado.
iOS nativo
Apps Swift que parecem óbvias na plataforma — widgets, App Clips e o polimento que os utilizadores Apple reparam.
Android nativo
Apps Kotlin afinadas para o verdadeiro espectro de dispositivos — incluindo a gama média que a maior parte do mundo carrega.
Multiplataforma
Flutter e React Native quando um único código serve melhor a atividade — uma escolha de engenharia, não de moda.
Sincronização offline-first
Dados local-first com sincronização sem conflitos, para que a app funcione na cave, no avião e em zona sem rede.
Pagamentos, NFC e push
Compras in-app, wallets, NFC tap-to-act e uma estratégia de notificações que respeita o utilizador o suficiente para se manter ativada.
Lançamento nas lojas e depois
Submissões à prova de review, implementações progressivas, monitorização de crashes e compatibilidade de SO para a vida.
O polimento é um processo, não um sprint final.
Uma qualidade que sobrevive tanto à review da loja como à crítica raivosa de três estrelas.
01Prototipar no dispositivo
Percursos clicáveis em hardware real logo na semana dois — porque uma app julga-se na mão, não no Figma.
02Construir offline-first
Sincronização, cache e estados de falha concebidos de raiz. A conectividade é tratada como um bónus, não como um pressuposto.
03Testar em dispositivos reais
Uma parede de Androids baratos e iPhones velhos — os telefones dos seus utilizadores, não o do seu fundador.
04Lançar e iterar
Implementações progressivas, limiares de taxa sem crashes e iteração guiada pela analítica. A app melhora a cada release.
Já o entregámos.
A app móvel no coração de um comércio conectado avaliado em $10M+ — percorrer, ler, desbloquear, pagar.
FeelEat — Happy Fridge
Percorrer os menus do dia, ler o código para desbloquear um frigorífico inteligente, pagar na app e ver exatamente o que cada prato contém — nutrição, alergénios e origens incluídos.
Escolhidas para o problema, não para o CV.
Nativo onde conta, partilhado onde compensa — cada escolha defendida pelo mérito de engenharia.
Uma só equipa. Zero transições.
As disciplinas mais frequentemente combinadas com as apps móveis — mesma arquitetura, mesmos engenheiros, sem taxa de integração.
Perguntas, respostas.
O que os compradores de apps móveis mais nos perguntam. Para o resto — envie um briefing, um engenheiro sénior responde em um dia útil.
Coloque-o num briefing. Um engenheiro sénior — não um vendedor — responde no prazo de um dia útil.
Q.01Nativo ou multiplataforma — o que escolher?
Depende do que a app faz, e defendê-lo-emos com provas. Integração profunda com a plataforma, câmara ou trabalho em segundo plano favorecem o nativo; as apps de conteúdo-e-comércio saem geralmente mais depressa e mais baratas em Flutter ou React Native, sem compromisso visível para o utilizador.
Q.02Quanto tempo até estarmos na App Store?
Uma v1 focada demora tipicamente 10–16 semanas, incluindo a review da loja. Submetemos cedo, com uma implementação progressiva: o dia do lançamento é um botão a carregar — não uma oração à fila de review.
Q.03Tratam da aprovação na App Store e na Play Store?
De ponta a ponta — fichas, declarações de privacidade, notas de review e a inevitável dança da nova submissão. Lançámos apps suficientes para saber o que os reviewers assinalam antes de o assinalarem.
Q.04O que acontece depois do lançamento?
Suporte vitalício: compatibilidade com as versões do SO, correções de segurança e monitorização de crashes pela equipa que a construiu. As apps apodrecem sem manutenção — as nossas continuam a colher cinco estrelas anos depois.
Q.05Conseguem retomar uma app móvel construída por outra agência?
Com frequência. Começamos por uma auditoria de código de uma semana que produz um roteiro de remediação, e depois assumimos a base de código por fases. Razões comuns para mudar: arquitetura instável, equipa offshore escondida, ou velocidade ao ponto morto.
Q.06React Native ou Flutter, se formos para cross-platform?
React Native se a sua equipa já conhece React/TypeScript e quer partilhar lógica com uma app web — o ecossistema e o leque de recrutamento são mais amplos. Flutter se quer uma UI idêntica ao pixel em todas as plataformas e Dart não o incomoda. Ambos estão prontos para produção; são as suas competências existentes e a partilha de código web que decidem, não a moda.
Q.07Como lidam com as compras integradas e as subscrições?
Usamos o RevenueCat por cima do StoreKit e do Google Play Billing para que a validação de recibos, os direitos de acesso e o estado de subscrição cross-platform sejam geridos num só sítio, em vez de duas integrações nativas frágeis. Ganha também a analítica de subscrições que a Apple e a Google não fornecem, e o restauro de compras — motivo comum de rejeição — torna-se fiável.
Q.08Como enviam atualizações sem passar pelas lojas de cada vez?
As correções da camada JavaScript em React Native podem sair OTA via CodePush/EAS Update, dentro dos limites das regras da Apple e da Google — sem ciclo de review para as alterações elegíveis. O código nativo exige sempre uma release na loja. Construímos também um mecanismo de feature flags remotas e de atualização forçada, para fazer dark launch de funcionalidades e exigir uma subida de versão quando uma rutura de API o impõe.
Uma app que os seus utilizadores
deviam adorar?
Diga-nos o trabalho que a app tem de cumprir, e para quem. Um engenheiro mobile sénior responde em um dia útil com um conselho de plataforma e um âmbito honesto.