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.
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.
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.
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.
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”.
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:
