Swift at Apple: Migrating the Password Monitoring Service from Java

Original Article ↗ Hacker News Discussion ↗

Tooling, IDEs, and “meeting devs where they are”

  • Many want better Swift support outside Xcode (VSCode, Neovim, JetBrains), citing Apple’s WWDC promise to “meet backend developers where they are.”
  • SourceKit-LSP and the official VSCode Swift extension are seen as increasingly usable; some report good experiences with VSCode and SwiftPM, others still prefer JetBrains tooling.
  • Cross‑platform Xcode is widely viewed as unrealistic and undesirable; people want a cross‑platform toolchain and good LSP, not Xcode on Windows/Linux.
  • Several commenters note large internal setups (e.g., VSCode-based, Bazel/Buck, remote Mac builders) that avoid Xcode almost entirely.

ARC vs GC, value types, and memory usage

  • The reported 40% performance gain and 90% memory reduction trigger deep debate: is this language-driven (ARC/value types) or mostly better design?
  • Some argue tracing GCs often need 2–3× memory to run optimally; others note modern JVM features (escape analysis, compacting collectors, object layout tricks) can give good locality.
  • Swift’s value types and copy-on-write collections are cited as major advantages over Java’s ubiquitous heap objects and fat headers.
  • Discussion explores tradeoffs of ARC vs moving GC, locality vs fragmentation, predictable RC costs vs GC pauses, and the cost of deep object graphs.

Rewrite vs tuning the JVM

  • Strong skepticism that the Java service was fully optimized: no mention of ZGC/Shenandoah, AppCDS, CRaC, or GraalVM makes some think it’s “Swift marketing.”
  • Others counter that Apple also had strategic reasons: dogfooding Swift server-side and reducing dependence on external runtimes.
  • Several point out the “v2 effect”: any rewrite, even in the same language, often benefits from lessons learned, better architecture, and removal of legacy abstractions.

Language choice, culture, and “enterprise Java”

  • Multiple comments blame typical enterprise Java stacks (Spring, deep indirection, reflection-heavy frameworks) for bloat and poor performance, not the JVM itself.
  • Others emphasize culture over language: any ecosystem can devolve into over‑engineered “enterprise” code; Swift’s weaker reflection and different norms may make some Java‑style messes less common.
  • Rust and Go are discussed as alternatives; consensus is that Rust offers the most headroom but higher adoption cost, while Go’s abstractions and GC limit long‑term optimization potential compared to Swift/Rust.

Infrastructure, architecture, and privacy constraints

  • The service runs on Linux infrastructure; commenters assume x86 Linux, with some discussion of Apple’s broader use of RHEL and Azure.
  • The asynchronous but user‑initiated nature of password checks means server responses must be quick to avoid battery drain and privacy issues; long‑lived cached results are seen as risky unless carefully encrypted.

Swift on the server: enthusiasm and doubts

  • Some are newly interested in server‑side Swift after seeing Apple use it, especially with Vapor, praising Swift’s ergonomics and performance.
  • Others are skeptical Swift will ever matter much off Apple platforms, given stronger ecosystems in Java, C#, Go, and Rust, and Apple’s limited investment in open server frameworks.
  • Package management and observability/profiling on Linux are flagged as current weak spots, though SwiftPM and community sites like Swift Package Index are mentioned positively.