News: 0178058283

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Apple Migrates Its Password Monitoring Service to Swift from Java, Gains 40% Performance Uplift (infoq.com)

(Sunday June 15, 2025 @05:29PM (EditorDavid) from the run-time dept.)


Meta and AWS have used Rust, and Netflix uses Go, [1]reports the programming news site InfoQ . But using another language, Apple recently "migrated its global Password Monitoring service from Java to Swift, achieving a 40% increase in throughput, and significantly reducing memory usage."

This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency."

> [2]In a recent post , Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "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."

>

> Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.

>

> Originally developed as a client-side language for Apple platforms, Swift has since expanded [3]into server-side use cases .... Swift's deterministic memory management, based on [4]reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.

"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."



[1] https://www.infoq.com/news/2025/06/apple-swift-migration/

[2] https://www.swift.org/blog/swift-at-apple-migrating-the-password-monitoring-service-from-java/

[3] https://www.swift.org/documentation/server/

[4] https://docs.swift.org/swift-book/documentation/the-swift-programming-language/automaticreferencecounting/



Uh oh (Score:2)

by ArmoredDragon ( 3450605 )

Now angle of sphere is going to go on a German fueled rant about how memory consumption doesn't matter because Java is awesome and totally isn't needlessly verbose.

Re: (Score:2)

by ArmoredDragon ( 3450605 )

Basically like this:

[1]https://youtu.be/oy2VqDi4sFg?t... [youtu.be]

[1] https://youtu.be/oy2VqDi4sFg?t=53

It's not the language. It's tech debt. (Score:2)

by devslash0 ( 4203435 )

Whenever you rewrite a product in a new stack you pretty much create it from scratch. You do things right and don't bring all the patchwork and tech debt with you. That's what caused this speed-up. No the change of the language.

Re: (Score:2)

by ArmoredDragon ( 3450605 )

More than likely, but Java does have a lot of inherent problems that almost certainly didn't help. It's also quite plausible that garbage collection was biting them pretty hard; example: [1]https://discord.com/blog/why-d... [discord.com]. The whole reason for switching in that case was because of GC, which is inherent to the language's runtime, and you can't do anything about it. And of course: Java IS a memory hog. Java DOES take a long time to spin up, both initially and for new threads.

They probably would have done sligh

[1] https://discord.com/blog/why-discord-is-switching-from-go-to-rust

say what? (Score:2)

by dfghjk ( 711126 )

"...close to 85% reduction in lines of code..."

Extremely unlikely. Worse yet, anyone who would claim this is clearly not a programmer.

Not News (Score:2)

by machineghost ( 622031 )

Apple reports that the language Apple wrote performs well when a bunch of Apple engineers use it to remake a project. Why is this news?

There are hundreds, if not *thousands* of devs on Slashdot who have rewritten something ... even in the same language ... and seen massive performance improvements. The fact that a 2.0 version of something has the potential to be better than the 1.0 is not news, and neither is anything else in this article.

It doesn't even offer a real comparison of Java vs. Swift, because

Having to manually track the satellite.