Today, I published a new Swift library called TaskUtilities, containing code that was originally in my WebSocketActors library. This library serves two purposes:

Understanding task structure

In complex asynchronous code, it is sometimes difficult to know what task is currently running and where it originated. TaskPath lets you name a task and then retrieve the current task name from an arbitrary point in your code.

Task.detached {
    TaskPath.with(name: "Fetch image") {
        ...
        TaskPath.with(name: "Constructing request") {
            ...
        }
    }
}

// In other code called from the inner task:
print(TaskPath.current) // Prints "{Task Fetch image > Constructing request}"

Making synchronous code async-safe

If synchronous code like a class has mutable state, it is not safe to call that code from asynchronous tasks. The preferred way to solve this problem is to change the class into an actor, but there are situations where that may not be possible because the code must be called from a synchronous context.

In these situations, RecursiveTaskLock and LockedValue provide a way to ensure that the mutable state is only accessed from one task at a time.

TaskUtilities

If these features sound helpful, please give my TaskUtilities project a try. I look forward to your feedback!

At WWDC 2022, Apple introduced a new technology in Swift that I don’t think got enough attention: distributed actors. I’ve been working with this system in my iOS app Proper Course™, and it has many benefits for the solo programmer working on an iOS app that requires a server component.

The traditional way

The traditional way of creating a client-server application is to build a REST-ful API server using Swagger/OpenAPI, and then build your client app on top of that API. This makes sense if your server will have multiple clients written in different languages, and there are some really great technologies like Vapor and Swift OpenAPI Generator that make this job easier. These are great tools to build on if you need a public API for your server.

But if you are an independent developer focused on creating an iOS app, the OpenAPI approach adds a lot of overhead and indirection that can really slow down development. Developing and maintaining the OpenAPI interface becomes a project of its own, and requires learning tools and workflows that don’t really add value to your iOS application.

Is there something better?

Distributed actors to the rescue

What if you could write entirely in Swift, make Swift function calls between your client and your server, develop them both in the same Xcode workspace, and have the compiler alert you immediately to any problems?

This is exactly what distributed actors do, and it’s pretty glorious.

Getting started

Before you start using distributed actors, you need to be comfortable with Swift concurrency in general and actors in particular. If you’re already using actors in your code, adding distributed actors is pretty easy.

To use distributed actors, you need a Swift library that provides an actor system with the communications infrastructure for your distributed actors. Apple has a peer-to-peer cluster actor system library, but this is designed for scaling distributed servers. For a client-server application, you need a library that is designed for that purpose.

Apple provides a sample project called TicTacFish that includes a client-server actor system based on WebSockets, but this sample code is missing some features that you will probably need in a real application. To support my own application, I’ve taken that code and created an open-source library that enhances Apple’s sample code with:

• Simultaneous connections to multiple servers & clients
• Automatic reconnection after network failures
• Server calls to client actors (server push)
• Logging with Swift Logging

If you would like to use distributed actors in your own Swift project, I encourage you to try my WebSocketActors library on GitHub. The library is very new, but the main features are in place, and I’d love to get feedback and answer questions.