Swift New Era for Elytra

Oct 1, 2025

Just a few weeks ago, I wrote about a decade of working on Elytra, however, the last epoch per my own writings was way back in 2018.

Every major milestone of Elytra has been noted down by me as an epoch, with the exception of the Mac app launch. There is a minor app update release available today on the App Store, but this post isn’t about that. It’s about Swift, Apple’s premiere programming language for its platforms, but also for servers and server-side work.

Timeline

  • 2015: Around this time, I was very familiar with JavaScript, NodeJS, etc. so that was my obvious choice for writing Elytra’s APIs and Poller process. Just a few years in, and I began to notice how unwieldy the project had gotten, partly due to my inexperience, as well as NodeJS’ single thread limitations. Swift 1.0 had already been available for a year by this time.

  • 2018: Elytra’s APIs and processes had been running stable on a few micro sized servers on AWS, requiring infrequent maintenance from me. I had automated away a bunch of routine tasks using cronjobs, and could focus mostly on the iOS app and soon to come macOS app built using Mac Catalyst.

  • 2020: The global pandemic era was upon us all, and I had more free time than usual, so I decided to finally rewrite Elytra for macOS using AppKit. Elytra’s API didn’t have to change, I didn’t need to write any special endpoints for the Mac app, so once again, I didn’t have to do anything to the API. This is also when I decided to fully migrate Elytra’s apps from Objective-C to Swift 5.5, which had now attained ABI stability a year ago.

  • 2021: This was the pivotal point. Around then, I began tinkering with the idea of UIPredicateEditor, a drop-in class replacement for NSPredicateEditor on iOS. I’d been working with Swift for over a year now, and its type-safety paradigms is what really made it stick with me. After looking around for a bit, Vapor seemed like a great fit for Elytra’s future API endpoints. And that’s what I started to use for writing the relevant API endpoints for supporting the Smart Folders feature.

  • 2023: In just two years, majority of the traffic coming to Elytra’s servers was equally split between the older NodeJS server and the newer Swift server. It was very clear, Swift on server was the future for Elytra’s APIs, however, this also meant I would have to transition all API endpoints currently being used by the apps to the newer system, and there were a lot of them. Elytra’s pollers was also migrated to use Swift around the same time iOS 17 and macOS 14 were released. The new poller was infinitely more faster, stable, and easily debugged.

  • 2024: Around WWDC24, and with the release of iOS 18, and macOS 15, majority of the traffic was being handled by a single server running the Swift binary of Elytra’s APIs. Vapor has matured by now, and Swift 6.0 is upon us bringing improved concurrency not only for the apps, but also to server-side programming. This was huge milestone, for all parties involved, including myself. I can now confidently write new API endpoints, while keeping similar logic structure I wrote for the NodeJS APIs (Promises, async/await was a thing in NodeJS for a while).

  • 2025: I was determined to have one of the last releases of Elytra in 2025 to fully use APIs running on the Swift server. By the time iOS 26 and macOS 26 released, and Elytra’s v2025.9 update, only four API endpoints remained on the older NodeJS server which were still being used: two of these were major, OPML import and export, one of the keystones of any good RSS feed reader app.

Well, determined as I was, in September 2025, I migrated these, and a lot more on the server, to fully use Swift 6.2, and all the interesting concurrency features it brings. Elytra’s latest release v2025.10 is now fully powered by a Swift backend. As of writing this post, Elytra is 99.9% Swift, with the 0.01% Objective-C for a few NSString related magic which Elytra’s text rendering engine still relies on for better performance.

The Choices

From a poorly managed NodeJS project to a hardened, well-documented, and performant server written fully in Swift, this transformation has been nothing short of metamorphosis. Back in May 2025, the amazing folks over at CulturedCloud also announced, Things Cloud now fully runs on Swift.

I echo their choice of Swift, and it just makes sense:

Swift has become Apple’s flagship programming language for building modern apps, and over the years we’ve adopted it for much of the code in Things itself. It is fast, safe, and expressive. So four years ago, when we set out to rebuild Things Cloud, we saw a promising opportunity: to use Swift on the server, too.

But more importantly:

…Apple had shown a strong commitment to server-side Swift, and there was a growing open-source community.

Apple has been sponsoring server-side Swift conferences for a while now, and that injects enthusiasm and confidence like nothing else. In contrast to what CulturedCode was doing, switching from one system to another overnight, Elytra had a different approach. Using date versioned API endpoints, I could write new, faster, sync endpoints for the apps’ new releases, while maintaining compatibility for prior releases. This is important as older releases of Elytra are still being used by customers on their supported devices, and I have no intentions to stop the app from functioning for them. This is a very small percentage of users, so I don’t mind it either.

As the tech stack for Elytra evolves over the next few years, so will its backend services and apps, simultaneously, utilising the improved code-sharing these three platforms can now achieve, thanks to Swift on iOS, macOS, and on the server.

Back