Soto icon


Soto Version 7 Alpha

An alpha for Soto version 7.0 has just been released. This version has some API improvements and considerable internal changes. Below is listed some of the more major changes and how they affect the library and its users.

Swift Concurrency

The library is now completely written using Swift concurrency. The EventLoopFuture based internals are gone along with the EventLoopFuture APIs. This allows us to make full use of all the features of Swift concurrency and also use the new Swift concurrency based APIs from AsyncHTTPClient which have better support for streamed response payloads.

Streamed Payloads

Operations that returned streamed responses, instead of returning the payload by repeated calling a closure now return the streamed payload as an AWSHTTPBody which conforms to a AsyncSequence of ByteBuffers. You can extract the payload using the pattern below or alternatively use the function AWSHTTPBody.collect(upTo:) to collate the stream of buffers into one.

let result = try await S3.getObject(.init(bucket: "MyBucket", key: "name"))
for try await buffer in result.body {

Event streams

Event stream APIs have previous been difficult to implement. S3.SelectObjectContent had a custom implementation, but other operations that received an event stream did not work. The move to AsyncSequence based payloads has simplified implementing these and now there is a generic solution for them all. This solution has been tested on S3.SelectObjectContent and Lambda.InvokeWithResponseStream. The stream of events are accessed from an AWSEventStream which conforms to AsyncSequence. At this point in time there is no support for sending event streams.

Request encoding/Response decoding

The solution for encoding of request header, query values etc and decoding of response header values has always been unsatisfactory. When encoding a request's headers Soto would use Mirror to extract the values out of the input shape. When decoding response headers the header values were added to the input to the Codable decoders, which meant the input had to be in a form the values could be added. JSON reponses had to be decoded to a dictionary before header values were added to the dictionary.

Both of these have been improved by passing a container to the encode/decode functions (via userInfo) which holds the request/response details. The encode functions use their request container to update the request headers, query parameters. The decode functions use their response container to extract header values.

These changes give us performance improvements at both the encoding and decoding stages. We aren't using Mirror while encoding, instead we are writing the values directly to the headers/query arrays during the encode(to:) functions. Decoding of JSON files doesn't require us use our custom DictionaryDecoder. Instead we can use the most up to date JSONDecoder which is considerably faster.


Previously Soto middleware provided you with a chance to edit the request before it was sent or the response just after receiving it. This has changed structure to allow more flexibility. You are provided with the request, and a closure to call the next middleware and are expected to return either the response from the closure or an edited version of it. Below is an example middleware.

struct MyMiddleware: AWSMiddlewareProtocol {
    func handle(_ request: AWSHTTPRequest, context: AWSMiddlewareContext, next: AWSMiddlewareNextHandler) async throws -> AWSHTTPResponse {
        let request = processRequest(request)
        let response = try await next(request, context)
        return processResponse(response)

This middleware is only editing requests and responses but there is nothing stopping you doing something more complex. In actual fact the middleware is flexible enough now that every part of the Soto request/response processing (signing, error handling, retries, endpoint discovery) is now done with middleware.

Middleware Stack

We also use a result builder to build the middleware stack. When you provide middleware to AWSClient or your service it can be either as an individual middleware or a stack of middleware.

let client = AWSClient(
    middleware: AWSMiddlewareStack {

SotoCrypto removed

The library now has platform requirements of macOS v10.15 and iOS v13. Because of this we can now use the swift-crypto package on all platforms and can get rid of the platform check in the Package.swift. This will fix the issues when cross compiling for Linux on macOS where it would not include swift-crypto. Also it means there is one less package to maintain.