Rewriting Apple’s Password Monitoring Service in Swift
Ricky Mondello et al. (2025, Mastodon, Hacker News):
The migration from Java to Swift was motivated by a need to scale the Password Monitoring service in a performant way. The layered encryption module used by Password Monitoring requires a significant amount of computation for each request, yet the overall service needs to respond quickly even when under high load.
[…]
Prior to seeking a replacement language, we sought ways of tuning the JVM to achieve the performance required. Java’s G1 Garbage Collector (GC) mitigated some limitations of earlier collectors by introducing features like predictable pause times, region-based collection, and concurrent processing. However, even with these advancements, managing garbage collection at scale remains a challenge due to issues like prolonged GC pauses under high loads, increased performance overhead, and the complexity of fine-tuning for diverse workloads.
[…]
Overall, our experience with Swift has been overwhelmingly positive and we were able to finish the rewrite much faster than initially estimated. Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency.
[…]
Not only were our initial results heartening, but after a few iterations of performance improvements, we had close to 40% throughput gain with latencies under 1 ms for 99.9% of requests on our current production hardware. Additionally, the new service had a much smaller memory footprint per instance — in the 100s of megabytes — an order of magnitude smaller compared to the 10s of gigabytes our Java implementation needed under peak load to sustain the same throughput and latencies.
The call out of G1GC as being “new” is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11? And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal?
The only mention they have is the garbage collector, which is simply just one aspect of the JVM. And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. There’s pretty large performance wins going from 11->17 and 17->21.
I’m sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.
Another near-certain factor in this decision was that Apple has an extreme, trauma-born abhorrence of critical external dependencies. With “premier” support for 11 LTS having ended last fall, it makes me wonder if a primary lever for this choice was the question of whether it was better to (1) spend time evaluating whether one of Oracle’s subsequent Java LTS releases would solve their performance issues, or instead (2) use that time to dogfood server-side Swift (a homegrown, “more open” language that they understand better than anyone in the world) by applying it to a real-world problem at Apple scale, with the goal of eventually replacing all of their Java-based back-ends.
Previously:
- Swift Server Powers Things Cloud
- Server-side Swift: Making Canopy
- The Opportunity of Swift on the Server
- Server Side Swift vs. The Other Guys
