Add Swift SDK for Apache Iggy

Description

Build and maintain an official Swift SDK for Apache Iggy, providing an idiomatic Swift API for producing and consuming messages and managing Iggy resources.

The SDK should follow the capabilities and conventions of the existing Iggy SDKs while embracing modern Swift features such as structured concurrency, async/await, strong typing, and Swift Package Manager.

The implementation should include the SDK itself, automated tests, examples, CI integration, package distribution, and complete documentation on the Apache Iggy website.

Motivation

Apache Iggy aims to provide a strong developer experience across programming languages and application environments.

Today, Iggy provides SDKs for Rust, Python, Java, Go, Node.js, C#, C++, and PHP. Adding Swift would expand Iggy’s ecosystem into an important developer community that is currently underserved by streaming infrastructure libraries.

Swift has also evolved beyond application development into a general-purpose language increasingly suitable for:

server-side applications and services;
distributed systems;
high-performance networking;
systems programming;
edge applications;
real-time applications;
applications spanning clients, edge infrastructure, and backend services.

A native Swift SDK would allow Swift developers to interact directly with Iggy without introducing Java, JVM, or other language/runtime dependencies into their applications.

There is also a particularly natural architectural fit between Swift and Iggy. Both ecosystems emphasize performance, memory safety, predictable resource usage, concurrency, and modern developer ergonomics.

The SDK could make Iggy especially useful for Swift applications that need durable, real-time event streams between devices, services, and backend infrastructure.

Examples include:

application telemetry and event ingestion;
real-time application state and event synchronization;
backend services written in Swift;
edge-to-cloud streaming;
observability pipelines;
AI/ML event and inference pipelines;
durable event streams for agents and other asynchronous applications.

Most importantly, Swift support strengthens Iggy’s goal of making high-performance streaming infrastructure accessible through the language and development environment that developers already use.

Affected area / component

No response

Proposed solution

Developer experience

The Swift SDK should follow established Swift conventions wherever possible.

In particular:

Swift Package Manager should be the primary package mechanism;
public APIs should use idiomatic Swift naming;
asynchronous network operations should use async/await;
APIs should be strongly typed rather than relying heavily on strings;
errors should map into meaningful Swift error types;
resource ownership and connection lifecycle should be explicit;
documentation should work well with Swift tooling;
the SDK should minimize external runtime dependencies.

Transport

The first implementation should prioritize a reliable native transport and clean architecture over supporting every Iggy transport immediately.

Phase 1

Implement:

TCP
TLS

using the Iggy binary protocol.

The transport abstraction should be designed so additional transports can be introduced without changing the public client API.

Future

Evaluate support for:

QUIC
HTTP
WebSocket

The long-term goal should be alignment with Iggy’s multi-protocol developer experience.

Alternatives considered

No response

Contribution

I'm willing to submit a pull request to implement this feature

Good first issue

I think this could be a good first issue for a new contributor

The same package can be contributed to https://github.com/swift-server/ similar to https://github.com/swift-server/swift-kafka-client
At the least, we can contribute to the swift-server documentation pointing to Iggy's native Swift SDK like many others.

to be decided: bindings approach (like PHP, python and C++) or swift-native implementation.

Hi, I'd like to take this issue up.

@RustToMetal

TBH regarding approach bindings vs swift-native i'm leaning swift-native, bindings only as a
bootstrap if we want something usable sooner.

reason: once #3470 / #3948 (deferred poll) lands, an idle consumer is just one blocked
socket read. native swift expresses that as an await on SwiftNIO / Network.framework
with zero extra threads, so the OS can suspend the process. a rust binding drags its own
reactor + timer wheel into the app and you have to drive it across lifecycle
transitions. on end-user devices that is a real energy difference.

fair point for the other side: bindings give protocol parity for free, which is why
python/php/cpp went that way. and swift-kafka-client is itself a wrapper - but over
librdkafka, plain C, no async runtime attached.

@RustToMetal i think we could split it cleanly:
(1) binary protocol codec + TCP/TLS transport
(2) client API surface, tests/examples/CI shared. under foreign/swift/.

but i'm not set in stone, maybe free feature parity with bindings approach is the play here...

My vote is for Swift native SDK instead of bindings, it's more resource efficient. With our growing community I'm confident that we will be able to maintain the parity with Rust SDK.

feat(swift): add Swift SDK with TCP and TLS transport