// mobile.lumi

Mobile

Apps mobile que usuários escolhem usar todos os dias — performance nativa, experiência consistente.

Mobile não é uma versão menor da web — é uma plataforma com suas próprias restrições de conectividade, bateria, memória e convenções de interação que determinam se o usuário volta ou desinstala na primeira semana. Desenvolvemos aplicações mobile com arquitetura que respeita as Human Interface Guidelines da Apple e o Material Design do Google, porque consistência com o ecossistema de plataforma é o que diferencia apps que parecem nativos daqueles que parecem portuagens. A escolha entre nativo, cross-platform ou Flutter depende do produto, do time e dos requisitos de performance — e cada uma tem contextos onde é a resposta certa.

Avaliar meu stack →Ver serviços Lumi
// o que é

Desenvolvimento mobile abrange a criação de aplicações para dispositivos portáteis — smartphones e tablets — nas plataformas iOS (Swift/Objective-C) e Android (Kotlin/Java), com alternativas cross-platform que compartilham código entre plataformas via React Native (JavaScript), Flutter (Dart) ou tecnologias web encapsuladas. A fragmentação de hardware e OS na plataforma Android, com centenas de dispositivos com diferentes densidades de tela, versões de API e capacidades de hardware, contrasta com o ecossistema controlado do iOS, onde a cobertura de versões recentes é muito mais alta — uma assimetria que afeta estratégias de teste e compatibilidade. Biørn-Hansen et al. (2017) categorizaram abordagens de desenvolvimento mobile em nativo, web-based, hybrid e cross-platform compilado, documentando as trocas entre performance, reuso de código e acesso a APIs nativas. O ciclo de release de apps mobile — com review da App Store levando de 1-3 dias e políticas restritivas de Apple — exige uma disciplina de release engineering diferente do ciclo de deploy web, onde mudanças em produção podem ser feitas em minutos.

// tecnologias

O que compõe a stack de Mobile

Cross-Platform FrameworkReact Native

Framework cross-platform da Meta que compila JavaScript para componentes nativos iOS e Android, compartilhando lógica de negócio entre plataformas com UI verdadeiramente nativa.

iOS NativoSwift

Linguagem nativa da Apple para iOS, macOS, watchOS e tvOS, com type safety, performance e integração total com APIs do sistema que garantem a experiência iOS mais fluida possível.

Android NativoKotlin

Linguagem oficial da Google para Android nativo, com null safety, coroutines para programação assíncrona e Jetpack Compose para UI declarativa moderna.

Cross-Platform FrameworkFlutter

Framework da Google que renderiza UI com seu próprio engine (Skia/Impeller) independente dos widgets nativos de plataforma, oferecendo consistência visual pixel-perfect e performance próxima ao nativo.

// arquitetura

Padrões e abordagens para Mobile

01

Offline-First Architecture

Projeta o app para funcionar completamente sem conexão de internet, sincronizando dados em background quando a conectividade é restaurada, usando local storage como fonte de verdade primária. Esse padrão é especialmente crítico em mercados emergentes com conectividade instável e em contextos de uso como apps de campo, logística e saúde onde a ausência de internet não pode interromper o fluxo de trabalho.

Ideal paraApps de produtividade, logística e saúde usados em contextos com conectividade variável ou em mercados com infraestrutura de rede limitada
02

Clean Architecture com MVVM / MVI

Aplica separação de camadas ao mobile: ViewModel expõe estado observável para a View, casos de uso encapsulam lógica de negócio e repositórios abstraem fontes de dados locais e remotas. No Android moderno com Jetpack Compose e no iOS com SwiftUI, o padrão MVI (Model-View-Intent) com fluxo unidirecional de dados se tornou a abordagem dominante por facilitar testes e previsibilidade de estado.

Ideal paraApps com lógica de negócio complexa e estado não-trivial que precisam de alta cobertura de testes e evolução segura ao longo do tempo
03

Feature Flags e Release Gradual

Publica novas features desativadas por padrão, ativando-as gradualmente para subconjuntos de usuários via remote config (Firebase Remote Config, LaunchDarkly), permitindo rollback imediato sem nova submissão à App Store. Resolve a assimetria de release mobile — onde reverter um release ruim exige nova review — ao desacoplar o deploy do código do lançamento da feature.

Ideal paraTimes mobile que precisam de velocidade de iteração sem a penalidade do ciclo de review para cada mudança de comportamento
04

Deep Linking e App Universal Links

Conecta URLs web a telas específicas do app nativo, permitindo que links de e-mail, push notifications e compartilhamentos abram diretamente o contexto correto dentro do app. Universal Links no iOS e App Links no Android fornecem fallback para a web quando o app não está instalado, criando uma experiência de navegação contínua entre web e mobile.

Ideal paraApps com conteúdo compartilhável, campanhas de marketing deep linked e fluxos de onboarding que começam na web e continuam no app
// como escolher

Escolher uma ou combinar?

A decisão entre nativo (Swift/Kotlin) e cross-platform (React Native/Flutter) deve ser guiada pelo produto, não pela preferência de linguagem: apps que dependem fortemente de APIs de hardware, performance de animação de 120fps e integração profunda com o SO beneficiam-se do nativo, enquanto apps de conteúdo e produtividade com UI relativamente padrão podem aproveitar o reuso de código do cross-platform sem penalidade perceptível. O tamanho do time e a necessidade de manter uma ou duas bases de código é frequentemente o fator determinante.

Se o time tem expertise em JavaScript/TypeScript e o app não usa APIs de hardware complexas

use React Native — o reuso de código de lógica de negócio entre web e mobile é um multiplicador significativo de produtividade para times com stack JS

Se consistência visual pixel-perfect entre iOS e Android é crítica e o time aceita aprender Dart

use Flutter — o engine próprio de renderização elimina diferenças visuais entre plataformas e oferece performance de animação consistente sem depender dos widgets nativos

Se o app requer integração profunda com hardware (ARKit/ARCore, CoreML, Health APIs, NFC)

desenvolva nativamente em Swift e Kotlin — as APIs de baixo nível têm melhor suporte, documentação mais rica e menos overhead de bridge cross-platform

Se o produto já tem uma web app React e quer expandir para mobile rapidamente

adote React Native para reuso de lógica de negócio, hooks e bibliotecas de estado já existentes, investindo apenas em componentes de UI específicos de mobile

Se o time é apenas iOS ou apenas Android e há orçamento para dois apps separados

desenvolva nativamente — Swift com SwiftUI e Kotlin com Jetpack Compose oferecem as melhores ferramentas, documentação e integração com os recursos mais recentes de cada plataforma

React Native e Flutter não são mutuamente exclusivos com nativo — é possível usar um app nativo como shell e embutir telas Flutter ou React Native para features específicas via técnica de "brownfield integration". Times maduros frequentemente têm um core nativo com módulos cross-platform para features de menor criticidade de performance, equilibrando experiência nativa onde importa com reuso de código onde é aceitável. Swift e Kotlin são linguagens complementares, não concorrentes — teams que mantêm dois apps nativos frequentemente partilham arquitetura, padrões de dados e serviços backend, diferindo apenas na implementação de UI.

// como a Lumi atua

Desenvolvemos apps mobile que respeitam as convenções de plataforma porque usuários percebem imediatamente quando algo não "parece certo" — e a percepção de qualidade afeta a retenção mais do que qualquer feature. Nossa abordagem integra testes automatizados em dispositivos reais via CI/CD, monitoramento de crash com Sentry e análise de performance de startup time antes de qualquer lançamento.

Princípios que aplicamos

  • Implementar testes automatizados de UI com XCUITest (iOS) e Espresso (Android) ou Detox (React Native) para fluxos críticos antes de qualquer submissão à App Store
  • Monitorar crash-free sessions em produção com target de 99,5%+ e alertas automáticos para qualquer degradação acima de 0,5% no dia seguinte ao release
  • Seguir Human Interface Guidelines e Material Design 3 como especificação de UI, não como sugestão — desvios deliberados precisam de justificativa documentada
  • Medir e controlar startup time cold e warm antes de releases, com budget definido por plataforma e feature-flagging de funcionalidades que impactem TTI
  • Implementar offline-first em todos os fluxos críticos do app, definindo explicitamente quais operações requerem conectividade e comunicando isso ao usuário de forma proativa

Armadilhas que evitamos

  • Usar WebView para features principais do app com a justificativa de "reuso de código web", entregando uma experiência que usuários identificam imediatamente como não-nativa e afetando retenção
  • Ignorar as diferenças de UX entre iOS e Android e usar os mesmos componentes e padrões de navegação em ambas as plataformas, criando inconsistência com o SO que confunde usuários
  • Não implementar feature flags em releases mobile, ficando refém do ciclo de review da App Store para corrigir problemas em produção quando um rollback de código seria a solução mais rápida
  • Solicitar permissões de câmera, localização e notificações na abertura do app sem contexto explicativo, gerando recusas do usuário que não podem ser solicitadas novamente sem ação explícita nas configurações
// fundamentos

Referências acadêmicas e da indústria

Apple. (2023). Human Interface Guidelines. Apple Developer Documentation.

Define os princípios de design iOS — clareza, deferência e profundidade — e os padrões de interação que determinam se um app "parece iOS" ou parece estrangeiro na plataforma.

Google. (2023). Material Design 3: Design system for adaptive and accessible apps. m3.material.io.

Estabelece o sistema de design para Android e apps cross-platform com tokens adaptativos, componentes acessíveis e diretrizes de movimento para ecossistema Android.

Biørn-Hansen, A., Majchrzak, T. A., & Grønli, T. M. (2017). Progressive Web Apps vs. Native Applications: An Empirical Comparison. IEEE International Conference on Web Information Systems and Technologies.

Comparação empírica entre abordagens nativa, web e híbrida documentando tradeoffs de performance, acesso a hardware e custo de desenvolvimento em contexto real.

Charland, A., & Leroux, B. (2011). Mobile Application Development: Web vs. Native. ACM Queue, 9(4).

Estabelece o debate fundamental entre apps nativos (performance, acesso a hardware) versus apps web (reuso, custo) que ainda guia decisões de plataforma mobile.

Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.

Padrões de arquitetura de aplicações como Repository, Unit of Work e Service Layer aplicáveis a apps mobile com lógica de negócio e persistência local complexas.

Google. (2023). Android Jetpack Compose: Modern Android UI toolkit. developer.android.com.

Documentação do framework UI declarativo do Android moderno com padrões de State Hoisting e Unidirectional Data Flow que definem a arquitetura de apps Android contemporâneos.

// próximo passo

Apps que usuários escolhem usar

Definimos a estratégia de plataforma ideal para o seu produto, construímos com as melhores práticas de cada ecossistema e entregamos apps com métricas de retenção e performance mensuráveis desde o lançamento.

Avaliar meu stack →Ver todas as stacks