Novas aplicações móveis Proton Mail: há mais do que se vê

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

À superfície, as novas aplicações oferecem um design moderno, melhor desempenho e capacidades offline — mas há muito mais do que se vê. Nos bastidores, as aplicações são uma reescrita completa do Proton Mail numa stack tecnológica inovadora, um projeto que tem o nome interno de Transformação de Engenharia. O termo inovadora é deliberado, porque — tanto quanto sabemos — esta foi a primeira vez que a tecnologia escolhida foi utilizada no contexto de uma aplicação de produção estabelecida.

Este artigo visa lançar luz sobre a fascinante jornada pela qual a nossa equipa passou na realização desta revolução, e responder a algumas das perguntas que a nossa comunidade nos fez ao longo do caminho. Antes de mais, a justificação subjacente é a necessidade de mudar o status quo.

Como tudo começou

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

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

• Qualidade: O Mail iOS e Mail Android, tomados isoladamente, ficaram aquém das expectativas em termos de qualidade e desempenho.
• Lacuna de funcionalidades entre iOS e Android: Algumas funcionalidades estavam disponíveis apenas numa plataforma, sem clareza sobre quando a outra as alcançaria.
• Velocidade de engenharia: Atualizações importantes e funcionalidades muito aguardadas não foram entregues atempadamente em ambas as plataformas.

Alguns dos problemas estendiam-se para além do móvel, e responder a esses exigiria um desvio do domínio tecnológico para o fascinante espaço problemático do escalonamento organizacional, e em particular startups tecnológicas de crescimento rápido. Mas a fragilidade do ecossistema móvel estava muito enraizada na tecnologia e arquitetura.

Escalar a Engenharia Móvel

Escalar a engenharia móvel vem com um conjunto único de desafios que são significativamente diferentes de escalar equipas de backend e web. Estas diferenças resultam da fragmentação da plataforma e das realidades operacionais do ecossistema móvel. As equipas móveis normalmente precisam de suportar múltiplas plataformas numa variedade de sistemas operativos e dispositivos (telemóveis, tablets, por vezes wearables). O iOS e o Android vêm com as suas próprias linguagens de programação, frameworks e ferramentas, o que leva a grandes quantidades de esforço duplicado: múltiplas equipas, bases de código duplicadas e compromissos constantes entre trabalho específico da plataforma e relacionado com o produto. Manter a oferta de produtos sincronizada requer uma enorme quantidade de coordenação.

O que é um desafio em toda a indústria foi particularmente agudo para a Proton. Aplicações de funcionalidade como o Mail e o Calendar são inerentemente mais complexas do que a maioria das aplicações móveis no mercado. Quando se adiciona a camada adicional de lógica de cliente necessária para lidar com a encriptação de ponto a ponto, acaba-se com clientes particularmente «pesados». Na altura, a equipa Android estava ocupada a reescrever o Mail para melhores padrões de qualidade — um investimento que demorou a maior parte de 18 meses. O iOS também necessitava urgentemente de re-arquitetura, para não falar do Calendar. O custo da duplicação estava a consumir todos os nossos recursos de engenharia, e tornou-se claro que não íamos ter sucesso fazendo mais do mesmo.

A melhor parte de reconhecer que se está bloqueado é que isso atua 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 se olha mais de perto para como empresas de sucesso lidaram com este problema na década anterior, percebe-se que seguiram uma de apenas duas estratégias possíveis:

1. Atiraram dinheiro ao problema, construindo equipas cada vez maiores à medida que os elevados custos operacionais eram compensados por uma combinação de investimentos sem fundo e/ou retornos generosos. Esta não era uma opção para o modelo de negócio livre de capital de risco da Proton: não podemos competir com os gastos de concorrentes baseados em anúncios e apoiados por investidores.
2. Reestruturaram as suas aplicações para se livrarem do desperdício, o que significa construir aplicações utilizando (tanto quanto possível) uma base de código partilhada.

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

Um meio para um fim: escolher a stack tecnológica certa

O passo seguinte foi escolher uma stack tecnológica que pudesse realmente fazer o trabalho.

Nos últimos 15 anos, o desenvolvimento móvel multiplataforma foi inundado com soluções de «tamanho único»: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform e muitas outras. Cada uma chegou com a mesma promessa — substituir o desenvolvimento nativo por completo. Na prática, a maioria falhou completamente ou teve sucesso apenas dentro de espaços problemáticos estritamente limitados. Não existe uma abstração universal que faça desaparecer as diferenças de plataforma: qualquer pessoa que tenha lançado e mantido grandes aplicações móveis sabe disso. A única forma fiável de avançar é trabalhar de trás para a frente a partir de requisitos concretos, em vez de para a frente a partir de tendências de ferramentas.

Traduzimos esse objetivo final num conjunto de requisitos não negociáveis (1) que qualquer solução escolhida tinha de satisfazer, e utilizámo-los como a nossa estrutura orientadora ao longo do processo de avaliação:

1. Custos e prazos: A stack tinha de reduzir materialmente o custo e o tempo necessários para lançar, manter e evoluir o Proton Mail no iOS e Android.
2. Experiência do utilizador: Tinha de preservar o desempenho e a qualidade de interação quase nativos — qualquer coisa menos do que isso era inviável.
3. Preparação estratégica para o futuro: A solução tinha de ser duradoura. Fomos intencionais em evitar frameworks de terceiros que tornariam o 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 utilizador de aplicações nativas.»

Fomos céticos desde o início de que o React Native ou o Flutter — as duas frameworks multiplataforma dominantes na altura — pudessem atingir este nível. Ainda assim, validámos esse ceticismo construindo implementações de prova de conceito da vista de lista de mensagens do Mail.

O React Native revelou rapidamente as suas limitações. Percorrer um grande conjunto de dados tornou o custo do seu modelo de execução interpretado dolorosamente óbvio. O Flutter teve melhor desempenho, mas a interface do utilizador permaneceu visivelmente não nativa, especialmente no iOS. Mais importante ainda, o Flutter é uma framework proprietária controlada pela Google, que tem um historial(nova janela) de abandonar tecnologias internas e tinha despedido recentemente uma grande parte da equipa Flutter. Para um produto com garantias de segurança e fiabilidade a longo prazo, esse nível de dependência externa era inaceitável.

O Kotlin Multiplatform foi o candidato seguinte. É uma opção atraente — particularmente para organizações com profunda experiência em Android — mas acabou por ficar aquém para o nosso caso de utilização. A ausência de uma camada de interface do utilizador partilhada, questões sobre a maturidade e a sobrecarga adicional introduzida pelo seu modelo de execução superaram os seus benefícios.

Neste ponto, a conclusão era clara e alinhada com a nossa intuição inicial: a única arquitetura que se aproxima consistentemente do resultado desejado é uma stack deliberadamente mista. Interface nativa em cada plataforma — Jetpack Compose no Android, SwiftUI no iOS — apoiada por uma camada de lógica de negócio partilhada escrita numa linguagem de baixo nível de alto desempenho. Esta abordagem tem um historial: a Dropbox utilizou famosamente C++ para partilhar lógica de negócio entre plataformas móveis antes de o abandonar em 2019 devido ao custo operacional e cognitivo da linguagem.

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

O Rust ocupa o mesmo envelope de desempenho que o C++, mas sem muitas das suas desvantagens históricas. Fornece fortes garantias de segurança de memória sem garbage collection, impõe concorrência thread-safe em tempo de compilação e é apoiado por um grande e altamente competente ecossistema de código aberto. Igualmente importante, o 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 partilhar lógica central sem comprometer a camada de interface do utilizador.

Esta não foi uma decisão isenta de riscos. Na altura, existiam poucos exemplos de aplicações móveis de grande escala voltadas para o consumidor construídas numa arquitetura centrada em Rust, e a experiência em Rust dentro da equipa era limitada.

Mas a inovação significativa raramente acontece em território de baixo risco. O verdadeiro desafio não era 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: resultados e aprendizagens

Avancemos para hoje e vejamos como a aposta correu.

O diagrama abaixo representa a arquitetura do Mail móvel. O núcleo Rust é responsável pela totalidade da lógica de negócio da aplicação. Empurrámos a utilização do Rust para além das suas aplicações habituais (redes, armazenamento, computação algorítmica) até ao tratamento da lógica de navegação complexa. Um exemplo disto é a lógica que governa o deslocamento infinito da lista de mensagens. Embora pouco ortodoxo, isto provou ser fundamental para alcançar o nosso objetivo de maximizar a reutilização de código. Como resultado, quase 80% da base de código é agora partilhada entre iOS e Android.

Isto traduziu-se num tempo de colocação no mercado mais rápido e de maior qualidade? Embora ainda seja demasiado cedo para um veredito final, os primeiros sinais têm sido muito encorajadores:

• Nos dois meses seguintes ao lançamento, a equipa conseguiu manter uma cadência semanal de atualizações de funcionalidades em ambas as plataformas (um total de 12 lançamentos de funcionalidades).
• Fechámos as lacunas de funcionalidades entre plataformas, trazendo funcionalidades há muito aguardadas para o Android, como adiar, RSVP de calendário e deslizar para a mensagem seguinte.
• Mesmo nesta fase 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% (abaixo de 0,12%), enquanto a do Android voltou a uma linha de base histórica (0,19%). Este é um forte endosso da estabilidade de execução do Rust.

O suporte também escala mais eficazmente sob esta abordagem. É frequentemente mais rápido identificar e resolver uma única causa raiz partilhada do que perseguir problemas superficialmente semelhantes decorrentes de falhas de lógica ligeiramente diferentes espalhadas por duas bases de código independentes. Encontrámos confirmação empírica do que tinha sido anteriormente uma hipótese de trabalho ao corrigir uma classe de problemas de sincronização de categorias que afetavam a lógica que sustenta as capacidades offline da aplicação: uma causa raiz, uma solução — representada no diagrama acima pelo módulo Rebasing lançado com a versão 7.6.2.

O outro lado da moeda?

• Erros e regressões são suscetíveis de ter um impacto mais amplo e afetar utilizadores em ambas as plataformas. Não se pode realmente ter tudo — mas pode-se definitivamente mitigar o risco apostando excessivamente em testes de ponto a ponto (E2E).
• Tal como com qualquer divisão de uma solução virada para o utilizador ao longo de uma divisão tecnológica horizontal, existe um risco de criar silos de conhecimento e perder algum foco de engenharia nas experiências de utilizador de ponto a ponto. É necessário estar ciente disto e mitigar intencionalmente o risco. Entre as medidas mais eficazes:
  • Alinhar sub-equipas para entregar funcionalidades em vez de camadas tecnológicas.
  • Treinar engenheiros móveis para se tornarem «full stack», ou seja, capazes de depurar, suportar e desenvolver tanto na base de código Rust como nas plataformas nativas.

O que se segue para a Transformação de Engenharia

Desde o início deste projeto, ficou claro que os riscos se estendiam muito para além do Proton Mail sozinho. Aplicar com sucesso esta stack tecnológica à aplicação principal da Proton foi sempre pretendido como o primeiro passo numa jornada mais longa — uma que veria esta abordagem implementada em todo o resto do nosso ecossistema móvel.

Esse cenário está agora a desenrolar-se. Enquanto escrevo este artigo, os nossos SDKs de Conta e Pagamento, bem como a próxima geração de aplicações móveis do Proton Calendar, estão a ser reescritos em linha com esta nova direção técnica.

Isto marca o início de uma segunda vaga de transformação de engenharia — uma evolução que expande o esquema tecnológico com uma estrutura arquitetónica concebida para tornar a reutilização de componentes mais fácil, não só entre plataformas, mas também entre produtos. Embora esta transição não aconteça de um dia para o outro, é fundamental para construir o ecossistema perfeitamente integrado e focado na privacidade que os nossos clientes esperam que a Proton seja.

(1): Simon Lewis,«A strategy for application implementation on multiple platforms», 2023.