In September last year, we launched a major update of Proton Mail for iOS and Android.

On the surface, the new apps deliver a modern design, better performance, and offline capabilities—but there is a lot more than meets the eye. Behind the scenes, the apps are a complete rewrite of Proton Mail on a novel technology stack, a project that goes by the internal name of Engineering Transformation. The term novel is deliberate, because — to the best of our knowledge — this has been the first time the chosen technology has been used in the context of an established production application.

This article aims to shed light on the fascinating journey our team has been through in the making of this revolution, and to answer some of the questions our community has asked us along the way. First and foremost, the rationale behind is the need to change the status quo.

How it all started

The realization that things needed to change hit on a Friday evening in October 2023. It materialized with surprising clarity, but not out of the blue: it was the culmination of months spent trying to find a common denominator for the seemingly unrelated problems affecting our users’ experience with Mail and Calendar mobile products.

At the risk of oversimplifying, we can summarize the pain points in three areas:

• Quality: Mail iOS and Mail Android, taken in isolation, fell short of expectations in terms of quality and performance.
• Feature gap between iOS and Android: Some features were only available on one platform, with no clarity on when the other would catch up.
• Engineering velocity: Key updates and long-awaited features were not delivered in a timely manner across both platforms.

Some of the issues extended beyond mobile, and answering those would require a digression from the technology domain into the fascinating problem space of organizational scaling, and in particular fast-growing tech startups. But the fragility of the mobile ecosystem was very much rooted in technology and architecture.

Scaling Mobile Engineering

Scaling mobile engineering comes with a unique set of challenges that are meaningfully different from scaling backend and web teams. These differences stem from platform fragmentation and the operational realities of the mobile ecosystem. Mobile teams typically need to support multiple platforms across a variety of operating systems and devices (phones, tablets, sometimes wearables). iOS and Android come with their own programming languages, frameworks, and tooling, which leads to large amounts of duplicated effort: multiple teams, duplicated codebases, and constant trade-offs between platform-specific and product-related work. Keeping the product offering in sync requires an enormous amount of coordination.

What is an industry-wide challenge was particularly acute for Proton. Functionality apps such as Mail and Calendar are inherently more complex than most mobile applications on the market. When you add on top the additional layer of client logic required to handle end-to-end encryption, you end up with particularly “thick” clients. Back in the day, the Android team was busy rewriting Mail to better quality standards—an investment that took the better part of 18 months. iOS was also in dire need of re-architecting, not to mention Calendar. The cost of duplication was eating into all of our engineering resources, and it became clear we were not going to succeed by doing more of the same.

The best thing about recognizing you are stuck is that it acts as a forcing factor to think outside the constraints of your current status quo. What would we do if we could start anew, freed from the burden of the choices and commitments that led us here? When you take a closer look at how successful companies dealt with this issue in the previous decade, you realize they followed one of only two possible strategies:

1. They threw money at the problem, building ever bigger teams as high operational costs were offset by a combination of bottomless investments and/or lavish returns. This was not an option for Proton’s VC-free business model: we can’t compete with the spending of ad-based, investor-backed competitors.
2. They re-engineered their apps to get rid of the waste, meaning building apps using (as much as possible) a shared codebase.

With option 1 being a non-starter, the path ahead was set.

A means to an end: choosing the right tech stack

The next step was to choose a tech stack that could actually do the job.

Over the past 15 years, cross-platform mobile development has been flooded with “one-size-fits-all” solutions: HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform, and many others. Each arrived with the same promise—to replace native development outright. In practice, most either failed outright or succeeded only within tightly constrained problem spaces. There is no universal abstraction that makes platform differences disappear: anyone who has shipped and maintained large mobile applications knows this. The only reliable way forward is to work backwards from concrete requirements rather than forward from tooling trends.

We translated that end goal into a set of non-negotiable requirements (1) that any chosen solution had to satisfy, and used them as our guiding framework throughout the evaluation process:

1. Costs and timescales: The stack had to materially reduce the cost and time required to ship, maintain, and evolve Proton Mail across iOS and Android.
2. User experience: It had to preserve near-native performance and interaction quality—anything less was a non-starter.
3. Strategic future-proofing: The solution had to be long-lived. We were intentional about avoiding third-party frameworks that would make our roadmap dependent on another vendor’s continued support.

The tension between the first two constraints is the industry’s version of the holy grail:

A cross-platform solution that delivers the performance and user experience of native applications.”

We were skeptical from the start that React Native or Flutter—the two dominant cross-platform frameworks at the time—could meet this bar. Still, we validated that skepticism by building proof-of-concept implementations of Mail’s message list view.

React Native quickly revealed its limitations. Scrolling through a large dataset made the cost of its JVM-based execution model painfully obvious. Flutter performed better, but the UI remained visibly non-native, especially on iOS. More importantly, Flutter is a proprietary framework controlled by Google, which has a history(new window) of abandoning in-house technologies and had recently laid off a large portion of the Flutter team. For a product with long-term security and reliability guarantees, that level of external dependency was unacceptable.

Kotlin Multiplatform was the next candidate. It is a compelling option—particularly for organizations with deep Android expertise—but it ultimately fell short for our use case. The absence of a shared UI layer, questions around maturity, and the additional overhead introduced by its execution model outweighed its benefits.

At this point, the conclusion was clear and aligned with our initial intuition: the only architecture that consistently gets close to the desired outcome is a deliberately mixed stack. Native UI on each platform – Jetpack Compose on Android, SwiftUI on iOS – backed by a shared business-logic layer written in a high-performance, low-level language. This approach has a track record: Dropbox famously used C++ to share business logic across mobile platforms before abandoning it in 2019 due to the operational and cognitive cost of the language.

By the end of 2023, Rust had clearly emerged as the successor in the lineage of systems programming languages.

Rust occupies the same performance envelope as C++, but without many of its historical liabilities. It provides strong memory safety guarantees without garbage collection, enforces thread-safe concurrency at compile time, and is supported by a large, highly competent open-source ecosystem. Just as importantly, Rust integrates cleanly with native mobile languages—Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android—making it a pragmatic choice for sharing core logic without compromising the UI layer.

This was not a risk-free decision. At the time, there were few examples of large-scale, consumer-facing mobile applications built on a Rust-centric architecture, and Rust experience within the team was limited.

But meaningful innovation rarely happens in low-risk territory. The real challenge was not Rust itself, but organizational inertia—shifting from proven, conservative approaches toward deliberate experimentation, guided by clear constraints and engineering judgment.

The new Proton Mail: outcome and learnings

Let’s fast-forward to today and see how the gamble played out.

The diagram below represents Mail mobile’s architecture. The Rust core is responsible for the entirety of the application’s business logic. We pushed the use of Rust beyond its usual applications (networking, storage, algorithmic computation) all the way into the handling of complex navigation logic. A case in point is the logic governing the infinite scrolling of the message list. While unorthodox, this proved key to achieving our objective of maximizing code reuse. As a result, almost 80% of the codebase is now shared across iOS and Android.

Did this translate into faster, higher-quality time-to-market? While it’s still too early for a final verdict, the early signs have been very encouraging:

• In the two months following the release, the team managed to maintain a weekly cadence of feature updates across both platforms (a total of 12 feature releases).
• We closed the feature gaps between platforms, bringing long-awaited features to Android such as snooze, calendar RSVP, and swipe-to-next-message.
• Even at this early stage, the new codebase has proven more stable than prior generations on both platforms: the iOS crash rate is 0.05% (down from 0.12%), while Android’s is 0.19% (down from 0.38%). This is a strong endorsement of Rust’s runtime stability.

Support also scales more effectively under this approach. It is often faster to identify and resolve a single, shared root cause than to chase down superficially similar issues arising from slightly different logic flaws spread across two independent codebases. We found empirical confirmation of what had previously been a working hypothesis while fixing a class of category synchronization issues affecting the logic that underpins the app’s offline capabilities: one root cause, one solution—represented in the diagram above by the Rebasing module shipped with version 7.6.2.

The other side of the coin?

• Bugs and regressions are likely to have a wider impact and affect users on both platforms. You can’t really have it all—but you can definitely mitigate the risk by over-indexing on end-to-end (E2E) testing.

• As with any slicing of a user-facing solution along a horizontal technology divide, there is a risk of creating knowledge silos and losing some engineering focus on end-to-end user experiences. You need to be aware of this and intentionally mitigate the risk. Among the most effective measures:

• Align sub-teams to deliver features rather than technology layers.

• Train mobile engineers to become “full stack”, i.e. able to debug, support, and engineer across both the Rust codebase and the native platforms**.**

What’s next for Engineering Transformation

From the very outset of this project, it was clear that the stakes extended well beyond Proton Mail alone. Successfully applying this technology stack to Proton’s flagship application was always intended as the first step in a longer journey—one that would ultimately see this approach rolled out across the rest of our mobile ecosystem.

That scenario is now unfolding. As I write this article, our Account and Payment SDKs, as well as the next generation of Proton Calendar mobile apps, are being rewritten in line with this new technical direction.

This marks the beginning of a second wave of engineering transformation—an evolution that expands the technology blueprint with an architectural framework designed to make component reuse easier, not only across platforms but also across products. While this transition will not happen overnight, it is fundamental to building the seamlessly integrated, privacy-first ecosystem our customers expect Proton to be.

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