Swift OpenAPI Generator is an Apache-2.0 licensed Swift package plugin and command-line tool from Apple that reads an OpenAPI document written in YAML or JSON and generates the type-safe Swift client and server code needed to make HTTP calls or implement HTTP services, and it is aimed at Swift developers building API clients for Apple platforms and at server-side Swift developers implementing HTTP APIs. It is an SSWG incubating project.

What it is

The project lives in the Swift ecosystem and is distributed through Swift Package Manager as a build plugin, with a command-line interface available as well. It is split across several repositories to keep dependencies small and the design extensible: apple/swift-openapi-generator provides the plugin and CLI, apple/swift-openapi-runtime provides the runtime library that the generated code depends on, and separate transport packages supply the concrete HTTP plumbing. apple/swift-openapi-urlsession provides a ClientTransport built on URLSession, swift-server/swift-openapi-async-http-client provides one built on AsyncHTTPClient, and frameo-net/swift-okhttp provides one built on OkHttp.

The concrete problem it solves is the hand-written ceremony code that every HTTP integration otherwise requires: request construction, response decoding, and the model types that mirror an API's schema. That code drifts from the specification as soon as the specification changes. Because the generator runs at build time, its output is always in sync with the OpenAPI document and does not need to be committed to the source repository, so the document remains the single source of truth and the generated networking layer replaces the manually maintained one.

Key capabilities

• Generates Swift code at build time from an OpenAPI document, so the generated output stays in sync with the specification and is not committed to the repository.
• Supports OpenAPI Specification versions 3.0 and 3.1, with preliminary support for version 3.2.
• Handles streaming request and response bodies, enabling use cases such as JSON event streams and large payloads without buffering.
• Supports JSON, multipart, URL-encoded form, base64, plain text, and raw bytes, represented as value types with type-safe properties.
• Provides client, server, and middleware abstractions that decouple the generated code from the HTTP client library and the web framework through the ClientTransport and ServerTransport protocols.
• Exposes a generated Client type with one method per HTTP operation, usable with any transport, as in Client(serverURL:transport:) paired with URLSessionTransport().
• Lets a server implement the generated APIProtocol, with each operation returning a typed output such as Operations.GetGreeting.Output, and register handlers on a transport such as VaporTransport.

Who uses it and how

• Apple-platform teams, reflected in the ios-swift topic, generate a client from a backend's OpenAPI document instead of hand-maintaining request and model code.
• Server-side Swift teams, reflected in the server-side-swift topic, implement the generated APIProtocol and register handlers with a web framework such as Vapor through VaporTransport.
• Teams that build with SwiftPM add the generator as a package plugin so generation happens as part of an ordinary build.
• Middleware authors rely on the middleware abstraction to insert cross-cutting behaviour without touching the generated code.
• Services that need event streams or large payloads use the streaming body support rather than buffering whole messages.

Getting started

Add the swift-openapi-generator Swift package plugin to a SwiftPM project, or use its command-line interface, and depend on swift-openapi-runtime alongside a transport such as swift-openapi-urlsession. Step-by-step tutorials and the full documentation are hosted on the Swift Package Index page.

How it compares

No comparable or competing tools are named in the facts provided for this project, and no list of paid products it replaces is given. It therefore stands alone in this registry on the evidence available.

When to use it — and when not to

Because it is a build-time tool, a self-hoster operates no database, object storage, or mail service; the work instead lies in wiring a transport, a web framework, and the runtime library together correctly. Teams outside the Swift ecosystem should not pick it, and teams unwilling to split their dependency graph across the generator, runtime, and transport repositories may find the arrangement adds moving parts. Weaker signals worth noting are the 132 open issues, the merely preliminary support for OpenAPI 3.2, and a README excerpt that documents features and examples more thoroughly than it documents installation specifics.

import OpenAPIURLSession
import Foundation

let client = Client(
    serverURL: URL(string: "http://localhost:8080/api")!,
    transport: URLSessionTransport()
)
let response = try await client.getGreeting()
print(try response.ok.body.json.message)

import OpenAPIRuntime
import OpenAPIVapor
import Vapor

struct Handler: APIProtocol {
    func getGreeting(_ input: Operations.GetGreeting.Input) async throws -> Operations.GetGreeting.Output {
        let name = input.query.name ?? "Stranger"
        return .ok(.init(body: .json(.init(message: "Hello, \(name)!"))))
    }
}

@main struct HelloWorldVaporServer {
    static func main() async throws {
        let app = try await Application.make()
        let transport = VaporTransport(routesBuilder: app)
        let handler = Handler()
        try handler.registerHandlers(on: transport, serverURL: URL(string: "/api")!)
        try await app.execute()
    }
}

```yaml
openapi: '3.1.0'
info:
  title: GreetingService
  version: 1.0.0
servers:
  - url: https://example.com/api
    description: Example service deployment.
paths:
  /greet:
    get:
      operationId: getGreeting
      parameters:
        - name: name
          required: false
          in: query
          description: The name used in the returned greeting.
          schema:
            type: string
      responses:
        '200':
          description: A success response with a greeting.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Greeting'
components:
  schemas:
    Greeting:
      type: object
      description: A value with the greeting contents.
      properties:
        message:
          type: string
          description: The string representation of the greeting.
      required:
        - message
```
</details>