Archive for February 26, 2026

Thursday, February 26, 2026

Why Not Objective-C

Brent Simmons:

I led the effort to port our remaining Objective-C to Swift. When I started that project, Objective-C was about 25% of the code; when I retired it was in the low single digits (and has gone even lower since, I’ve heard).

[…]

Objective-C code was where a lot of our crashing bugs and future crashing bugs (and bugs of all kinds) lived.

[…]

A second thing we knew was that having to interoperate between Swift and Objective-C is a huge pain.

[…]

And a third thing we knew was that very few of our engineers had a background writing Objective-C. Maintaining that code — fixing bugs, adding features — was more expensive than it was for Swift code.

I prefer Swift for new code, but I don’t really want to rewrite working code. I haven’t found my old Objective-C to be a source of bugs. However, I always seem to end up rewriting more than I initially planned because the interop is such a pain. I like using Swift for the main data types in my app, but of course those get used everywhere, including from Objective-C code. I’m also convinced that Objective-C interop is a source of some of the weird compiler behavior I see with crashes and dependency tracking. The part I don’t like rewriting in Swift is stuff that calls plain C APIs. The Swift version often feels less readable, and I’m less sure that it’s correct—both the opposite of my normal experience with the language.

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.

cogman10:

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.

CharlesW:

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

Vojtěch Rylko and Werner Jainek (2025):

The robustness of this work is ensured by a rigorous theoretical foundation, inspired by operational transformations and Git’s internals. After twelve years in production, Things Cloud has earned our users’ trust in its reliability. But despite the enduring strength of the architecture itself, the technology stack lagged behind.

[…]

Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.

A full rewrite is usually a last resort, but in our case, it was the only viable path for Things Cloud. We explored various programming languages including Java, Python 3, Go, and even C++. However, Swift – which was already a core part of our client apps – stood out for its potential and unique benefits. Swift promised excellent performance, predictable memory management through ARC, an expressive type system for reliability and maintainability, and seamless interoperability with C and C++.

[…]

Our Swift server codebase has around 30,000 lines of code. It produces a binary of 60 MB, and builds in ten minutes.

[…]

Compared to the legacy system, this setup has led to a more than threefold reduction in compute costs, while response times have shortened dramatically.

In contrast, OmniFocus puts all the logic in the client and can sync using any WebDAV server.

Werner Jainek (MacRumors):

The new cloud is already up and running – and you didn’t notice a thing. That was by design. From the outside, everything appears the same. But under the hood, everything changed: the infrastructure, the architecture, and the language it’s written in.

This post takes you behind the scenes: why we rebuilt Things Cloud, why we chose to write it in Swift, and how we transitioned without skipping a beat.

[…]

To ensure a smooth transition, we ran the new cloud in parallel with the old one. While the old Things Cloud continued syncing everyone’s to-dos, the new cloud quietly processed the same data using its own logic and infrastructure. Every edge case and every corner of the sync model was tested under real-world conditions – without anyone ever noticing.

Justin Bengtson:

What have been some of the pain points in using Swift on Server? What does the community think it needs to be improved to be more widely adopted in the industry? Any specific issues with deploying on Mac or Linux would be nice to know as well.

taylorswift:

yes, in general, i have found Swift’s “crash early and crash violently” philosophy to be problematic for server-side use cases, where availability is paramount and downtime is fatal.

to this day, Swift doesn’t have a good way to recover from precondition failures, so a single logic error in a many hundreds of thousands of lines codebase, triggered by a single unlucky visitor (or robot) has a nuclear-sized blast radius that takes down the service for everyone.

Simon Leeb:

I’ll take a crashing service any day of the week, if the alternative is a runtime with “let’s soldier on, it’ll be fine YOLO” vibes. I can image the post-mortem forum post would then be “I accidentally updated half a million user data records with unrecoverable garbage” instead of “things were patchy for a while”.

Konstantin:

Build times, compute and memory footprint during build are astronomical. Swift components are costing us 3x more than JVM/Kotlin components and 10x more than Rust/Go components to build. It’s really quite expensive to run Swift on the server.

[…]

Developing for the server on macOS is a huge pain in two main areas: 1) the overlapping types with iOS/macOS frameworks (e.g. Crypto) makes it impossible to know if what builds on macOS will build and even run on some Linux environment. Others have already mentioned the pain of FoundationEssentials, networking etc. 2) As a result of the previous, the ecosystem of Swift packages is full of libraries which although claiming support for server/linux targets, do not actually (correctly) support that.

[…]

DX around tooling has many papercuts (we see this when onboarding devs coming from more established server language ecosystems). One very prominent point is, well, IDE - Xcode is great for apps but positively hostile for server apps.

Previously:

Copyright © 2000–2026 Michael Tsai.