Exploits, Tools & Data Recovery · Bug Classes & Mitigations · Lesson 4 of 5

Memory-Safe Languages

How Rust and Swift remove whole bug classes, and why the switch takes years.

Rust in Android

Mitigations make bugs harder to use. A memory-safe language goes further: it stops most memory bugs from being written in the first place. The language checks that every write fits in its box and that nobody keeps using a freed locker, either while the code is being built or while it runs.

Android's apps and much of its framework were already written in Java and Kotlin, which are memory-safe. The trouble was the low-level parts, like media, Bluetooth and networking, which need a fast systems language and were written in C and C++. Google's answer was Rust, a systems language that checks memory rules when the code is built, without slowing the program down much.

Here's the timeline from Google's security blog:

• 2021: Google announced Rust support for the Android platform, for Android 12. The stated goal was not to convert old C and C++ code, but to write new code in memory-safe languages.
• December 2022: Android 13 was the first release where most new code was in a memory-safe language. Memory safety bugs had dropped from 76% of Android's vulnerabilities in 2019 to 35% in 2022, and Google said no memory safety vulnerabilities had been found in Android's Rust code so far.
• September 2024: the share was 24%, well below the roughly 70% industry norm.
• November 2025: memory safety bugs fell below 20% of Android's vulnerabilities for the first time. Google estimated Rust's memory safety bug rate at more than 1,000 times lower than its C and C++ code, based on about 5 million lines of Rust and one near-miss bug that was caught and fixed before release.

Rust isn't magic. It has an escape hatch, marked unsafe, for the few places that must talk directly to hardware or older code. Google says about 4% of its Rust is in such blocks, and that they get extra review. Google also reported a bonus it hadn't expected: Rust changes were rolled back about four times less often than similar C++ changes.

Swift, and why it takes years

Apple took a similar path with Swift, the language it introduced in 2014 for building apps. In its 2025 Memory Integrity Enforcement post, Apple described Swift as an easy-to-use, memory-safe language. Many Apple apps and newer system parts use it, but iOS still contains a great deal of older C, C++ and Objective-C code. That's exactly why Apple also built hardware protections: they guard the code that hasn't moved yet.

Why not rewrite everything right away?

• Size. A phone operating system has many millions of lines of code. Rewriting it would take years of work from experts who are also needed to build new features and fix today's bugs.
• New risk. Rewritten code is new code, and new code has new bugs, including logic bugs that no language prevents.
• Old code gets safer. In its 2024 post, Google explained that vulnerabilities in a piece of code become rarer as it ages and gets tested. It described this with a half-life, like a fading radioactive sample. Most bugs live in new or recently changed code, so writing new code safely gives the biggest gain first.

So the change is steady, not sudden. Google is extending Rust into more places, including the Linux kernel, firmware and its own apps. Apple keeps moving more of its code to Swift.

What does this mean for you? Over time, phones should have fewer of the most severe bugs, the kind used in zero-click attacks, and the remaining ones should be more expensive for attackers to use. It doesn't mean phones become bug-free. Logic bugs remain, old code remains, and mitigations still matter. The best thing a user can do is the same as ever: install updates quickly, since every fix, in any language, arrives that way.