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.
Conteúdo revisado:
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 com crachá NFC nos locais da FeelEat, refeições pagas com saldo pré-pago. 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 e monitorização de crashes, com atualizações do SO num plano de suporte opcional.
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.
O seu produto pode ser o próximo caso nesta página.
Comece com um workshop gratuito de 4 horasJá o entregámos.
A app móvel no coração do comércio conectado da FeelEat — 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.
Nativo 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.
Quanto 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.
Tratam 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.
O que acontece depois do lançamento?
30 dias de correções gratuitas e depois um plano de suporte opcional: 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, por isso continuamos a entregar atualizações do SO e correções de segurança.
Conseguem 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.
React 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.
Como 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.
Como 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.