Exploring a more AI-native and Concurrency-first direction for server-side Swift

Server
1

Over the past few years, I built and maintained a full production e-commerce backend on Vapor 4.

The experience taught me a lot about server-side Swift — both its strengths and its pain points.

Swift itself has evolved dramatically since the early Vapor era:

  • async/await

  • actors

  • Sendable

  • structured concurrency

  • increasingly AI-assisted workflows

But many server-side patterns still feel shaped by the EventLoop/Future-based generation of Swift.

After enough production experience, I started experimenting with a different direction:

  • Concurrency-first runtime design

  • Runtime truth over macro magic

  • Explicit architecture contracts

  • AI-discoverable project structures

  • Product-oriented DX instead of framework-oriented DX

That exploration gradually became a new experimental framework project called Daylily:

Daylily GitHub

This is not intended as a “Vapor replacement post” or framework war.

Vapor solved extremely important problems for the Swift ecosystem and made server-side Swift viable in the first place.

But I do think the Swift Concurrency era opens the door for a different style of server framework architecture.

Especially with AI becoming part of real development workflows.

Right now I’m mainly exploring questions like:

  • What should an AI-native Swift backend framework look like?

  • How should runtime metadata be exposed?

  • How can Swift backend architecture become easier for AI agents to understand safely?

  • What does modern DX for server-side Swift actually mean?

  • Can server-side Swift become more product-oriented instead of infrastructure-oriented?

I’d genuinely love feedback from people working on server-side Swift, especially those who have operated real production systems.

Even if you disagree with the direction, I’d still love to hear your thoughts.

2 Likes