Swift

ServerSide.swift 2025: Two Days in London That Proved Swift Belongs on the Server

Swift on the server is production-ready. ServerSide.swift 2025 in London showed small teams shipping backends, first-class cloud SDKs, and mature tooling with Swift 6 concurrency guarantees.

Stijn Willems

Stijn Willems

— 10 min read

I spent two days at ServerSide.swift 2025 in London. The message was clear: Swift on the server isn't experimental anymore. Small teams ship production backends. Major cloud providers have first-class Swift SDKs. The tooling has matured.

Here's what matters from the conference.

Type-Safe Redis Commands with Parameter Packs

Adam Fowler (Apple, Hummingbird maintainer) presented valkey-swift, a Redis/Valkey client leveraging Swift's parameter packs (SE-0393) for compile-time type safety.

The problem with most Redis clients: you pass strings and hope the command is valid. Valkey-swift uses parameter packs to verify commands at compile time.

Fowler was direct about the implementation: "Parameter packs were quite problematic to implement. But the result is worth it—you catch type errors before deployment, not in production."

// Type-safe Redis commands with parameter packs
let client = RedisClient()
await client.set("user:123", value: userData)
let result: User? = try await client.get("user:123")

The library handles Redis Cluster topology discovery with automatic failover, MOVED error handling during resharding, and connection pooling per node. Built on SwiftNIO, it integrates cleanly with async/await patterns.

Key insight: Type safety isn't just for application code. Infrastructure clients benefit from Swift's type system too.

Swift 6 Concurrency Solves Real Server Problems

Matt Massicotte (contracted by Apple to write the Swift 6 migration guide) focused his talk on patterns that work for server-side code.

The @Concurrent attribute solves actor isolation mismatches that plague server middleware. When you need to share state between requests, proper isolation patterns prevent data races—caught at compile time by Swift 6's strict concurrency checking.

Four Evolution proposals work together to make this practical:

  • SE-0414 (Region-Based Isolation): Proves data race safety without requiring Sendable conformance by analyzing code flow
  • SE-0430 (Sending Values): Transfer ownership of non-Sendable types across actors
  • SE-0420 (Inheritance of Actor Isolation): Eliminates unnecessary suspensions in middleware chains
  • SE-0417 (Task Executor Preference): Low-level performance tuning for sub-millisecond latency
// Actor isolation for request-scoped state
actor RequestContext {
    private var sessions: [UUID: Session] = [:]
    
    func getSession(_ id: UUID) -> Session? {
        sessions[id]
    }
    
    func addSession(_ session: Session) {
        sessions[session.id] = session
    }
}

Massicotte covered practical patterns for request-scoped state without sacrificing safety. Server applications have different concurrency requirements than client apps—you need patterns that handle thousands of concurrent requests, not dozens of UI updates.

Production validation: Vapor framework achieved zero data race crashes after adopting Sendable conformance. Mikaela Caron deployed her Fruitful app backend with Swift 6 strict concurrency mode catching bugs before production.

Key insight: Swift 6's concurrency model works for high-load server applications. The strict checking prevents entire categories of bugs.

Resources: massicotte.org • ConcurrencyRecipes on GitHub

Vapor vs Hummingbird: Both Work, Pick Based on Needs

Emma Gaubert (iOS Developer at Decathlon) compared Vapor and Hummingbird in a practical, side-by-side analysis.

What's the Same

Both frameworks:

  • Support Fluent ORM
  • Deploy to Docker and AWS Lambda
  • Are open source with active development
  • Built on SwiftNIO foundation

What Differs

Vapor (24k+ GitHub stars):

  • Batteries-included framework with comprehensive middleware
  • Established community (13k+ Discord members)
  • Fluent ORM with PostgreSQL, MySQL, SQLite, MongoDB support
  • Property wrappers (@ID, @Field, @Parent, @Children, @Siblings)
  • JWT authentication via vapor/jwt-kit
  • Redis caching, WebSocket support built-in

Hummingbird (Adam Fowler):

  • Lightweight with only 6 core dependencies
  • Modular extension packages (Router, Fluent, Redis, WebSocket, Lambda, Auth)
  • No Foundation requirement in core
  • Swift 6-first architecture rebuilt in 2024
  • Flexible for microservices and serverless
// Hummingbird 2 route definition
router.get("users/:id") { request, context -> User in
    let userId = try context.parameters.require("id", as: UUID.self)
    return try await database.getUser(userId)
}

The choice isn't about which is "better"—it's about deployment targets and team preferences. Both frameworks are production-ready.

Key insight: Framework selection depends on your database needs and architectural preferences, not technical capability.

Resources: vapor.codes • hummingbird.codes • Hummingbird on GitHub

SongShift Runs Production Backend on Swift Lambda

Ben Rosen (Founder, SongShift) shared their production architecture running entirely on Swift Lambda functions. SongShift transfers playlists between streaming services across iOS, iPadOS, macOS, and visionOS.

Their Evolution

  • 2016: Client-only app with local storage
  • 2018: Node.js + Docker + MongoDB (unsustainable for small team)
  • 2020: Swift on AWS Lambda (current)

Technical Stack

  • Swift AWS Lambda Runtime (Swift Server Work Group)
  • Soto (Swift SDK for all 200+ AWS services, SSWG Graduated)
  • AWS Step Functions for workflow orchestration
  • DynamoDB for state, S3 for unstructured data
  • Terraform for infrastructure as code
// Shared model between iOS app and Lambda functions
public struct Playlist: Codable, Sendable {
    public let id: UUID
    public let name: String
    public let tracks: [Track]
    public let sourceService: StreamingService
    
    public func validate() throws {
        guard !name.isEmpty else {
            throw ValidationError.emptyPlaylistName
        }
    }
}

The win: They share Swift Package Manager packages between their iOS app and Lambda functions. Same data models, same validation logic, same type safety across client and server.

For a small team without dedicated backend engineers, serverless Swift eliminated server management overhead. Lambda handles scaling automatically. They pay per execution. Step Functions orchestrate long-running transfers across multiple Lambdas, handling the 15-minute Lambda timeout constraint.

Performance: Swift Lambda achieves 190-219ms cold starts (faster than C# .NET at 224ms, Java at 358ms) and 1.19ms warm execution matching Node.js and Python.

Key insight: Small teams can ship production backends with Swift without hiring specialized backend engineers.

Resources: Swift AWS Lambda Runtime on GitHub • Soto SDK

Idiomatic AWS Integration with Swift Bedrock Library

Mona Dierickx built Swift wrapper patterns during her AWS internship and contributed the first Swift examples to AWS Bedrock Runtime documentation.

The problem: Auto-generated AWS SDKs require 20+ lines of boilerplate for simple operations. The code isn't Swift-idiomatic.

// Idiomatic Swift wrapper around AWS Bedrock
let bedrock = BedrockClient()

let image = try await bedrock.generateImage(
    prompt: "A Swift server in a data center",
    model: .nova_canvas
)

// Returns PNG data directly, not base64 strings
let pngData: Data = image.imageData

Five lines instead of twenty. Type-safe model selection (.nova_canvas instead of string literals). Direct typed responses—PNG data, not base64 strings. Native async/await throughout.

The AWS SDK for Swift provides official Bedrock support through AWSBedrock, AWSBedrockRuntime, AWSBedrockAgent, and AWSBedrockAgentRuntime modules. The Converse API offers unified streaming chat across Amazon Nova, Anthropic Claude, Meta Llama, and other models.

Key insight: Swift needs idiomatic wrappers around auto-generated SDKs. Reduce boilerplate while preserving type safety.

Resources: AWS SDK for Swift on GitHub • Mona's GitHub

Zero-Copy Networking with Span

Joannis Orlandos (MongoKitten creator, Vapor core team) covered networking libraries using Swift's Span feature for zero-copy operations.

Span reduces memory allocations in hot paths. MongoKitten uses these patterns for efficient BSON parsing. Hummingbird benefits from reduced allocations. EdgeOS (IoT systems) needs memory-efficient networking for constrained environments.

// Zero-copy buffer access with Span
func parseMessage(_ buffer: Span) throws -> Message {
    // Direct buffer access without copying
    let header = buffer[0..<16]
    let payload = buffer[16...]
    return Message(header: header, payload: payload)
}

The trade-off: complexity vs performance. Orlandos was clear—"Span is great for zero-copy networking, but you need to weigh the complexity trade-offs."

For high-throughput message parsing or embedded systems, Span provides real benefits. For typical web applications, standard patterns work fine.

Key insight: Optimization tools exist when you need them. Use them when performance requirements justify the complexity.

Resources: MongoKitten on GitHub • swiftonserver.com

Building Real Applications: Fruitful Backend

Mikaela Caron (Independent iOS Engineer, Swift Ecosystem Workgroup member) presented her journey building a conference networking app backend using Vapor.

Technical Stack

  • Vapor 4 framework
  • PostgreSQL with Fluent ORM
  • AWS S3 with presigned URLs for direct uploads
  • Redis for caching attendee lists
  • JWT authentication with refresh token rotation
  • Docker containers on Linux VMs
  • Swift 6.0 strict concurrency mode

Architecture Decisions That Worked

File Uploads: AWS SDK for Swift generates presigned URLs. Clients upload directly to S3. No file data through the Vapor server. The repository pattern keeps S3 logic separated from route handlers—testable without AWS infrastructure.

// Repository pattern for testable S3 integration
protocol ImageRepository: Sendable {
    func generateUploadURL(for key: String) async throws -> URL
}

final class S3ImageRepository: ImageRepository {
    func generateUploadURL(for key: String) async throws -> URL {
        try await s3.presignedURL(bucket: bucket, key: key)
    }
}

Caching: Redis for conference attendee lists. Protocol-based cache abstraction means you can swap between in-memory and Redis without code changes.

Concurrency: Swift 6 strict concurrency catches data races at compile time. The compiler prevents entire categories of bugs before deployment.

Learning Resources Used

Key insight: Learning server-side Swift means building real projects that solve actual problems and deploying to Linux.

Resources: Fruitful App • Mikaela on GitHub

gRPC Swift 2: Modern Distributed Systems

George Barnett (Apple Cloud Services, SwiftNIO contributor) announced gRPC Swift 2 as a complete rewrite leveraging modern Swift concurrency.

Announced at gRPConf 2024 with the keynote "Building a New gRPC Library in Swift," the modular ecosystem includes:

  • grpc-swift - Core runtime with async/await
  • grpc-swift-nio-transport - HTTP/2 via SwiftNIO
  • grpc-swift-protobuf - Protocol Buffers integration with code generator
  • grpc-swift-extras - Health service, reflection, OpenTelemetry, Swift Service Lifecycle
// gRPC Swift 2 with async/await
struct GreeterService: Greeter {
    func sayHello(
        request: HelloRequest,
        context: ServerContext
    ) async throws -> HelloResponse {
        HelloResponse(message: "Hello, \(request.name)!")
    }
}

Protocol Buffers provide binary serialization with smaller messages than JSON, faster processing, and efficient encoding. The four RPC types (unary, server streaming, client streaming, bidirectional streaming) cover all communication patterns.

Production-ready features include automatic retry mechanisms, client-side load balancing, keepalive configuration, and standard gRPC status codes with RPCErrorConvertible for custom error types.

Key insight: Apple's investment in gRPC Swift demonstrates commitment to server-side distributed systems at internet scale.

Resources: gRPC Swift 2 on GitHub • Swift.org announcement • George on GitHub

Swift Containerization: VM-per-Container Isolation

Eric Ernst (Apple Engineering Leader) announced Swift containerization at WWDC 2025, providing OCI-compliant Linux containers on macOS.

The unique architecture runs each container in its own lightweight VM using macOS Virtualization.framework for hardware-level isolation. Sub-second boot times result from an optimized Linux kernel (6.12+), minimal root filesystem, and vminitd init system written in Swift.

Core components:

  • ContainerizationEXT4: Formats EXT4 filesystems programmatically
  • ContainerizationNetlink: Configures dedicated IP addresses per container (no port forwarding)
  • ContainerizationOCI: Manages OCI images with full Docker Hub compatibility
// Swift containerization API
let container = try await Container.create(
    image: "swift:6.0-slim",
    command: ["swift", "run"]
)

try await container.start()
let output = try await container.logs()

The system achieves security through VM isolation while maintaining container-like performance, offering an open-source alternative to Docker Desktop optimized for Apple Silicon.

Key insight: Apple is investing in Swift-based infrastructure tooling for modern cloud-native development.

Resources: github.com/apple/containerization • github.com/apple/container

Production MongoDB with Native Swift Driver

Joannis Orlandos maintains MongoKitten (v7.9.0+, SSWG Incubating), a pure Swift MongoDB driver with native BSON parsing and no C dependencies except SSL.

The companion BSON library implements BSON specification v1.1 with on-demand parsing and delayed data copies for performance. Unlike JSON, BSON stores binary data directly, supports additional types like ObjectId and Date natively, and maintains type information JSON cannot preserve.

// MongoKitten with type-safe queries
struct User: Codable {
    let _id: ObjectId
    let email: String
    let createdAt: Date
}

let users = try await db["users"].find(
    "email" == "user@example.com"
).decode(User.self).allResults()

Built on SwiftNIO with async/await patterns, MongoKitten supports MongoDB 3.6+ with GridFS for large files, change streams for real-time monitoring, ACID transactions (MongoDB 4.0+ replica sets), and aggregation pipelines. The Meow ORM layer adds type-safe query building with @Field property wrappers.

Key insight: Native Swift database drivers provide better performance and developer experience than C bindings.

Resources: MongoKitten on GitHub • BSON Library on GitHub

Apple's Swift Server Commitment

The conference featured seven members of Apple's Swift Server team, demonstrating Apple's serious investment in server-side Swift:

  • Franz Busch - SwiftNIO, networking protocols
  • George Barnett - gRPC Swift implementation
  • Honza Dvorsky - Swift Server Ecosystem, Swift Package Manager
  • Ben Cohen - Swift Core Team Manager, language design
  • Si Beaumont - Server infrastructure, systems programming
  • Eric Ernst - Engineering Leadership, containerization
  • Agam Dua - Swift Server Ecosystem & Education lead

Their presence signals that server-side Swift is a priority for Apple, not a community-only effort.

Key Technical Themes

1. Swift 6 Concurrency Everywhere

Multiple talks emphasized strict concurrency checking and proper isolation patterns. Server applications have different concurrency requirements than client apps. Swift 6's model handles both with compile-time guarantees.

2. Type Safety Across the Stack

  • Parameter packs for Redis commands (compile-time verification)
  • Typed model selection in AWS Bedrock (no string literals)
  • Shared SPM packages between client and server (zero duplication)

Type safety prevents production bugs across the entire stack.

3. Cloud-Native Patterns

  • Serverless with Lambda (sub-200ms cold starts)
  • Managed services (DynamoDB, S3, Redis)
  • Infrastructure as Code (Terraform, Swift Cloud)
  • First-class AWS SDK support (Soto, AWS SDK for Swift)

Server-side Swift integrates cleanly with modern cloud platforms.

4. Production-Ready Tooling

Mature frameworks (Vapor, Hummingbird). Battle-tested libraries (SwiftNIO, Soto, MongoKitten). The ecosystem has stabilized with real production deployments running at scale.

5. Developer Experience

  • Reducing boilerplate through idiomatic wrappers
  • Leveraging Swift features (async/await, parameter packs, actors)
  • Clear documentation and real examples
  • Active community support

What This Means for Server-Side Swift

For Small Teams

You can ship backends without dedicated backend engineers. Serverless patterns reduce operational overhead. Shared packages between client and server eliminate duplication.

Example: SongShift runs production serverless architecture maintained by iOS team.

For Production Systems

Swift 6 strict concurrency prevents data races at compile time. Multiple framework options based on needs. Mature ecosystem with battle-tested libraries (SwiftNIO, Soto, MongoKitten).

Validation: Apple's Password Monitoring Service migration from Java to Swift achieved 40% throughput increase, 50% hardware reduction, and 90% memory decrease.

For Integration

  • Swift interops with C++ and Java ecosystems
  • Cloud providers have first-class Swift SDKs
  • Distributed system tools (gRPC, Temporal) support Swift
  • Standard Docker and Kubernetes deployment

For Learning

Strong community resources and documentation. Real production case studies validate approaches. Active open source development with responsive maintainers.

What's Next

Based on conference discussions:

  • Continued concurrency improvements - Swift 6 adoption and refinement
  • Cloud platform integration - More first-class AWS, Azure, GCP support
  • Distributed systems tooling - Temporal SDK expansion, gRPC enhancements
  • Performance optimization - Zero-copy networking, memory efficiency improvements
  • Developer experience - Better tooling, clearer patterns, more examples

The Verdict

Server-side Swift is production-ready. The talks weren't about proof-of-concepts—they covered production systems handling real load with real users.

Small teams ship backends without specialized infrastructure engineers. Type safety prevents bugs across the entire stack. Cloud integration is first-class. The tooling has matured.

If you've been waiting for server-side Swift to be "ready," it is.

Resources

Frameworks

Libraries

Learning Resources

Community

Official Resources

Call to Action

The conference organizers encouraged attendees to submit talks for next year. Your experience matters to the community. Production deployments. Failed experiments. Architecture decisions. All of it helps others.

If you're building with server-side Swift, share what you're learning.

Conference: ServerSide.swift 2025
Location: London, UK
Dates: October 2-3, 2025
Website: serversideswift.info
Hashtags: #swiftlang #serversideSwift2025

Social: Bluesky • Mastodon • Twitter • LinkedIn • GitHub

Huge thanks to organizer Tim Condon (Bluesky) and to all the organizers and volunteers who made this conference possible.

Read more