Novos aplicativos móveis do Proton Mail: há mais do que os olhos veem

Em setembro do ano passado, lançamos uma grande atualização do Proton Mail para iOS e Android.

Na superfície, os novos aplicativos oferecem um design moderno, melhor desempenho e recursos off-line — mas há muito mais do que os olhos veem. Nos bastidores, os aplicativos são uma reescrita completa do Proton Mail em uma nova pilha de tecnologia, um projeto que atende pelo nome interno de Engineering Transformation. O termo novo é deliberado, porque — até onde sabemos — esta foi a primeira vez que a tecnologia escolhida foi usada no contexto de um aplicativo de produção estabelecido.

Este artigo visa lançar luz sobre a jornada fascinante que nossa equipe percorreu na realização dessa revolução, e responder a algumas das perguntas que nossa comunidade nos fez ao longo do caminho. Antes de mais nada, a justificativa por trás é a necessidade de mudar o status quo.

Como tudo começou

A percepção de que as coisas precisavam mudar surgiu em uma sexta-feira à noite em outubro de 2023. Materializou-se com surpreendente clareza, mas não do nada: foi o culminar de meses passados tentando encontrar um denominador comum para os problemas aparentemente não relacionados que afetavam a experiência de nossos usuários com os produtos móveis Mail e Calendar.

Correndo o risco de simplificar demais, podemos resumir os pontos problemáticos em três áreas:

• Qualidade: Mail iOS e Mail Android, tomados isoladamente, ficaram aquém das expectativas em termos de qualidade e desempenho.
• Lacuna de recursos entre iOS e Android: Alguns recursos estavam disponíveis apenas em uma plataforma, sem clareza sobre quando a outra alcançaria.
• Velocidade de engenharia: Atualizações importantes e recursos há muito esperados não eram entregues em tempo hábil em ambas as plataformas.

Alguns dos problemas estendiam-se além do móvel, e respondê-los exigiria uma digressão do domínio da tecnologia para o fascinante espaço de problemas de escala organizacional, e em particular startups de tecnologia de rápido crescimento. Mas a fragilidade do ecossistema móvel estava muito enraizada na tecnologia e na arquitetura.

Escalando a Engenharia Móvel

Escalar a engenharia móvel vem com um conjunto único de desafios que são significativamente diferentes de escalar equipes de backend e web. Essas diferenças decorrem da fragmentação da plataforma e das realidades operacionais do ecossistema móvel. Equipes móveis normalmente precisam oferecer suporte a múltiplas plataformas em uma variedade de sistemas operacionais e dispositivos (telefones, tablets, às vezes vestíveis). iOS e Android vêm com suas próprias linguagens de programação, frameworks e ferramentas, o que leva a grandes quantidades de esforço duplicado: múltiplas equipes, bases de código duplicadas e constantes compensações entre trabalho específico da plataforma e relacionado ao produto. Manter a oferta de produtos em sincronia requer uma enorme quantidade de coordenação.

O que é um desafio em toda a indústria foi particularmente agudo para a Proton. Aplicativos de funcionalidade como Mail e Calendar são inerentemente mais complexos do que a maioria dos aplicativos móveis no mercado. Quando você adiciona no topo a camada adicional de lógica de cliente necessária para lidar com criptografia de ponta a ponta, você acaba com clientes particularmente “pesados”. Antigamente, a equipe Android estava ocupada reescrevendo o Mail para melhores padrões de qualidade — um investimento que levou a maior parte de 18 meses. O iOS também precisava urgentemente de re-arquitetura, sem mencionar o Calendar. O custo da duplicação estava consumindo todos os nossos recursos de engenharia, e ficou claro que não teríamos sucesso fazendo mais do mesmo.

A melhor coisa sobre reconhecer que você está preso é que isso age como um fator de força para pensar fora das restrições do seu status quo atual. O que faríamos se pudéssemos começar de novo, libertos do fardo das escolhas e compromissos que nos trouxeram até aqui? Quando você olha mais de perto como empresas de sucesso lidaram com esse problema na década anterior, percebe que seguiram apenas uma das duas estratégias possíveis:

1. Elas jogaram dinheiro no problema, construindo equipes cada vez maiores, já que os altos custos operacionais eram compensados por uma combinação de investimentos sem fundo e/ou retornos generosos. Essa não era uma opção para o modelo de negócios livre de VC da Proton: não podemos competir com os gastos de concorrentes baseados em anúncios e apoiados por investidores.
2. Elas reengenharam seus aplicativos para se livrar do desperdício, o que significa construir aplicativos usando (tanto quanto possível) uma base de código compartilhada.

Com a opção 1 sendo inviável, o caminho a seguir estava definido.

Um meio para um fim: escolhendo a pilha de tecnologia certa

O próximo passo foi escolher uma pilha de tecnologia que pudesse realmente fazer o trabalho.

Nos últimos 15 anos, o desenvolvimento móvel multiplataforma foi inundado com soluções “tamanho único”: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform e muitos outros. Cada um chegou com a mesma promessa — substituir o desenvolvimento nativo completamente. Na prática, a maioria falhou completamente ou teve sucesso apenas dentro de espaços de problemas rigidamente restritos. Não existe uma abstração universal que faça as diferenças de plataforma desaparecerem: qualquer um que tenha enviado e mantido grandes aplicativos móveis sabe disso. A única maneira confiável de avançar é trabalhar de trás para frente a partir de requisitos concretos, em vez de seguir as tendências de ferramentas.

Traduzimos esse objetivo final em um conjunto de requisitos inegociáveis (1) que qualquer solução escolhida tinha que satisfazer, e os usamos como nosso quadro orientador durante todo o processo de avaliação:

1. Custos e prazos: A pilha tinha que reduzir materialmente o custo e o tempo necessários para enviar, manter e evoluir o Proton Mail no iOS e Android.
2. Experiência do usuário: Tinha que preservar o desempenho quase nativo e a qualidade de interação — qualquer coisa menos que isso era inviável.
3. Preparação estratégica para o futuro: A solução tinha que ser de longa duração. Fomos intencionais em evitar frameworks de terceiros que tornariam nosso roteiro dependente do suporte contínuo de outro fornecedor.

A tensão entre as duas primeiras restrições é a versão da indústria do santo graal: “Uma solução multiplataforma que oferece o desempenho e a experiência do usuário de aplicativos nativos.”

Fomos céticos desde o início que React Native ou Flutter — os dois frameworks multiplataforma dominantes na época — pudessem atingir essa barreira. Ainda assim, validamos esse ceticismo construindo implementações de prova de conceito da visualização de lista de mensagens do Mail.

O React Native revelou rapidamente suas limitações. Rolar por um grande conjunto de dados tornou o custo de seu modelo de execução interpretado dolorosamente óbvio. O Flutter teve um desempenho melhor, mas a interface do usuário permaneceu visivelmente não nativa, especialmente no iOS. Mais importante, o Flutter é um framework proprietário controlado pelo Google, que tem um histórico(nova janela) de abandonar tecnologias internas e demitiu recentemente uma grande parte da equipe do Flutter. Para um produto com garantias de segurança e confiabilidade a longo prazo, esse nível de dependência externa era inaceitável.

O Kotlin Multiplatform foi o próximo candidato. É uma opção atraente — particularmente para organizações com profunda experiência em Android — mas, em última análise, ficou aquém do nosso caso de uso. A ausência de uma camada de interface do usuário compartilhada, questões sobre maturidade e a sobrecarga adicional introduzida por seu modelo de execução superaram seus benefícios.

Neste ponto, a conclusão era clara e alinhada com nossa intuição inicial: a única arquitetura que consistentemente chega perto do resultado desejado é uma pilha deliberadamente mista. Interface do usuário nativa em cada plataforma – Jetpack Compose no Android, SwiftUI no iOS – apoiada por uma camada de lógica de negócios compartilhada escrita em uma linguagem de baixo nível e alto desempenho. Essa abordagem tem um histórico: o Dropbox usou C++ para compartilhar lógica de negócios entre plataformas móveis antes de abandoná-lo em 2019 devido ao custo operacional e cognitivo da linguagem.

No final de 2023, Rust emergiu claramente como o sucessor na linhagem de linguagens de programação de sistemas.

Rust ocupa o mesmo envelope de desempenho que C++, mas sem muitos de seus passivos históricos. Ele fornece fortes garantias de segurança de memória sem coleta de lixo, impõe concorrência segura para threads em tempo de compilação e é apoiado por um grande e altamente competente ecossistema de código aberto. Tão importante quanto isso, Rust integra-se de forma limpa com linguagens móveis nativas — Swift e SwiftUI no iOS, Kotlin e Jetpack Compose no Android — tornando-o uma escolha pragmática para compartilhar a lógica principal sem comprometer a camada de interface do usuário.

Essa não foi uma decisão isenta de riscos. Na época, havia poucos exemplos de aplicativos móveis voltados para o consumidor em grande escala construídos em uma arquitetura centrada em Rust, e a experiência em Rust dentro da equipe era limitada.

Mas a inovação significativa raramente acontece em território de baixo risco. O verdadeiro desafio não foi o Rust em si, mas a inércia organizacional — mudar de abordagens comprovadas e conservadoras para a experimentação deliberada, guiada por restrições claras e julgamento de engenharia.

O novo Proton Mail: resultado e aprendizados

Vamos avançar para hoje e ver como a aposta se desenrolou.

O diagrama abaixo representa a arquitetura do Mail móvel. O núcleo Rust é responsável por toda a lógica de negócios do aplicativo. Empurramos o uso de Rust além de suas aplicações usuais (rede, armazenamento, computação algorítmica) até o manuseio de lógica de navegação complexa. Um exemplo é a lógica que rege a rolagem infinita da lista de mensagens. Embora não ortodoxo, isso provou ser fundamental para atingir nosso objetivo de maximizar a reutilização de código. Como resultado, quase 80% da base de código agora é compartilhada entre iOS e Android.

Isso se traduziu em um tempo de lançamento no mercado mais rápido e de maior qualidade? Embora ainda seja muito cedo para um veredito final, os primeiros sinais foram muito encorajadores:

• Nos dois meses seguintes ao lançamento, a equipe conseguiu manter uma cadência semanal de atualizações de recursos em ambas as plataformas (um total de 12 lançamentos de recursos).
• Fechamos as lacunas de recursos entre as plataformas, trazendo recursos há muito esperados para o Android, como soneca, RSVP de calendário e deslizar para a próxima mensagem.
• Mesmo neste estágio inicial, a nova base de código provou ser mais estável do que as gerações anteriores em ambas as plataformas: a taxa de falhas no iOS é de 0,05% (queda de 0,12%), enquanto a do Android voltou a uma linha de base histórica (0,19%). Este é um forte endosso da estabilidade de tempo de execução do Rust.

O suporte também escala de forma mais eficaz sob essa abordagem. Muitas vezes é mais rápido identificar e resolver uma causa raiz única e compartilhada do que perseguir problemas superficialmente semelhantes decorrentes de falhas lógicas ligeiramente diferentes espalhadas por duas bases de código independentes. Encontramos confirmação empírica do que anteriormente era uma hipótese de trabalho ao corrigir uma classe de problemas de sincronização de categoria afetando a lógica que sustenta os recursos off-line do aplicativo: uma causa raiz, uma solução — representada no diagrama acima pelo módulo Rebasing enviado com a versão 7.6.2.

O outro lado da moeda?

• Bugs e regressões provavelmente terão um impacto mais amplo e afetarão usuários em ambas as plataformas. Você não pode realmente ter tudo — mas pode definitivamente mitigar o risco superindexando em testes de ponta a ponta (E2E).
• Como em qualquer fatiamento de uma solução voltada para o usuário ao longo de uma divisão tecnológica horizontal, existe o risco de criar silos de conhecimento e perder algum foco de engenharia nas experiências do usuário de ponta a ponta. Você precisa estar ciente disso e mitigar intencionalmente o risco. Entre as medidas mais eficazes:
  • Alinhe subequipes para entregar recursos em vez de camadas de tecnologia.
  • Treine engenheiros móveis para se tornarem “full stack”, ou seja, capazes de depurar, dar suporte e projetar tanto na base de código Rust quanto nas plataformas nativas.

O que vem a seguir para a Transformação de Engenharia

Desde o início deste projeto, ficou claro que as apostas se estendiam muito além do Proton Mail sozinho. Aplicar com sucesso essa pilha de tecnologia ao aplicativo principal da Proton sempre foi planejado como o primeiro passo em uma jornada mais longa — uma que veria essa abordagem implementada em todo o resto do nosso ecossistema móvel.

Esse cenário agora está se desenrolando. Enquanto escrevo este artigo, nossos SDKs de Conta e Pagamento, bem como a próxima geração de aplicativos móveis Proton Calendar, estão sendo reescritos de acordo com essa nova direção técnica.

Isso marca o início de uma segunda onda de transformação de engenharia — uma evolução que expande o plano tecnológico com uma estrutura arquitetônica projetada para facilitar a reutilização de componentes, não apenas entre plataformas, mas também entre produtos. Embora essa transição não aconteça da noite para o dia, é fundamental para construir o ecossistema perfeitamente integrado e focado na privacidade que nossos clientes esperam que a Proton seja.

(1): Simon Lewis,“Uma estratégia para implementação de aplicativos em múltiplas plataformas”, 2023.