# HaishinKit.swift: RTMP and SRT streaming for Apple platforms

> HaishinKit is a Swift package that gives iOS, macOS, tvOS and visionOS apps camera and microphone publishing plus playback over RTMP, SRT and an alpha WHEP/WHIP path. It fits teams already shipping native Apple apps who want to avoid a separate media stack.

**HaishinKit/HaishinKit.swift** — Camera and Microphone streaming library via RTMP and SRT for iOS, macOS, tvOS and visionOS.

- Repository: https://github.com/HaishinKit/HaishinKit.swift
- Website: https://docs.haishinkit.com/swift/latest/documentation/
- Stars: 3,070 · Forks: 716
- Language: Swift
- License: BSD-3-Clause
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/haishinkit-haishinkit-swift

## What HaishinKit.swift is for

The project describes itself as a camera and microphone streaming library via RTMP and SRT for iOS, macOS, tvOS and visionOS. That sentence defines the audience narrowly: developers writing native Apple apps who need to publish a live camera feed, or play one back, without building their own transport layer. The repository has been developed for ten years according to the README, which notes 2,778 commits and 163 releases since 2015. That history matters less as a quality signal than as an indication that the API has been through several migrations; the project maintains a migration guide in its wiki, which implies breaking changes are a recurring event rather than an exception.

The scope is broader than a single protocol. Separate modules exist for RTMP, SRT and RTC, and the README marks the WHEP/WHIP support as alpha. Alongside transport, the library covers multi-camera access, screen capture through ReplayKit on iOS and ScreenCaptureKit on macOS, video mixing for overlays such as watermarks or time display, and multi-streaming to separate services. Those features are the reason to choose this over a thin RTMP wrapper, but each one also adds surface area you have to understand before shipping.

## How the modules and protocols fit together

The repository layout is the clearest statement of architecture. At the top level sit HaishinKit/, RTMPHaishinKit/, SRTHaishinKit/, RTCHaishinKit/ and MoQTHaishinKit/, each with its own DocC documentation directory. That split means you depend on the protocols you actually use rather than pulling one monolith. The README links separate documentation indexes for RTMP, SRT and WHEP/WHIP, so the transport-specific details live with the transport-specific module.

The platform matrix is where the modular design shows its cost. SRTHaishinKit is listed as not available for Mac Catalyst. If your app targets Mac Catalyst and you need SRT, the module you want is the one you cannot have, and the README does not offer a workaround. Minimum versions are iOS 15.0, tvOS 15.0, Mac Catalyst 15.0, macOS 12.0 and visionOS 1.0, with watchOS marked as not applicable. On the toolchain side, version 2.2.0 and later require Xcode 26.0 and Swift 6.0, while 2.1.0 and later require Xcode 16.4 and Swift 6.0. Swift 6 is the floor across both rows, so this is not a package you can drop into a project still on Swift 5 language mode without checking the concurrency implications. The README states strict concurrency compliance as a feature, which is consistent with that floor.

## Installing HaishinKit.swift and running the examples

The README gives one installation path: Swift Package Manager, with the repository URL as the package location. There is no CocoaPods or Carthage instruction in the README, so if your project depends on one of those, you are on your own.

The fastest way to see the library working is the bundled examples project, which the README describes as a reference implementation app for live streaming publish and playback. Clone the repository and open the Xcode project:

```bash
git clone https://github.com/HaishinKit/HaishinKit.swift.git
cd HaishinKit.swift
open Examples/Examples.xcodeproj
```

To point the examples at your own endpoint, the README says to change the URL in Examples/Preference.swift. That file is the single place where the example app's stream target is configured.

If you are wiring the library into your own app rather than the examples, two prerequisites come before any streaming code. On iOS you must configure and activate an AVAudioSession, and the README supplies this snippet:

```swift
import AVFoundation

let session = AVAudioSession.sharedInstance()
do {
    try session.setCategory(.playAndRecord, mode: .default, options: [.defaultToSpeaker, .allowBluetooth])
    try session.setActive(true)
} catch {
    print(error)
}
```

Second, camera and microphone access require usage descriptions in Info.plist. The README gives the keys NSCameraUsageDescription and NSMicrophoneUsageDescription, each with a string value you supply. Without both, the system will not grant access and the capture path has nothing to read from.

The README also carries an important warning before the examples section: several issues occur when connected to Xcode, and it points to a known-issue document in the repository. Read that document before you conclude the library is broken. A large share of first-run problems appear to be toolchain-related rather than library defects, and the README explicitly suggests checking whether an issue also reproduces in the examples app.

## Where HaishinKit.swift stops being the right tool

The clearest limitation is stated plainly: SRTHaishinKit is not available for Mac Catalyst. If your distribution plan routes macOS through Mac Catalyst and SRT is a requirement, this library does not cover you, and the README does not describe an alternative. You would be looking at a different transport or a different platform strategy.

The second limitation is the alpha status of WHEP/WHIP. The README labels the RTC module's publish and playback support as alpha. Treating an alpha transport as production infrastructure is a decision the project has not made for you, and the documentation does not promise API stability there. If WebRTC-style ingest is central to your product, the alpha label is a reason to wait or to look elsewhere.

The third is the toolchain floor. Swift 6.0 and Xcode 26.0 for the 2.2.x line are recent requirements. Teams pinned to older Xcode versions cannot use the latest releases, and the README's support table only goes back to 2.1.0 with Xcode 16.4. Older combinations are not documented, so you cannot tell from the README how far back compatibility extends.

Finally, the support model is worth reading carefully. The README states that technical support on Issues and Discussions is provided only to contributors and academic researchers, and that a $50 per month sponsorship buys technical support with priority response. This is not a project where you can file an issue and expect an answer by default. If your team depends on upstream responsiveness, that dependency has a price attached.

## How it compares with a WebRTC-first approach

The obvious alternative for real-time Apple streaming is to build on WebRTC directly, using a client library and a WHIP or WHEP endpoint. The difference in approach is not cosmetic. WebRTC is designed around sub-second latency and congestion control, and it assumes an interactive session between peers or between a client and an SFU. HaishinKit's primary transports, RTMP and SRT, are contribution protocols aimed at delivering a feed to a media server for distribution. RTMP is the long-standing ingest format for platforms that then repackage the stream; SRT is built for reliable delivery over lossy networks. Neither is trying to be a conferencing protocol.

That distinction drives the choice. If you are publishing a one-to-many broadcast to a service that expects RTMP or SRT ingest, HaishinKit matches the job and gives you Apple-native capture, mixing and multi-streaming on top. If you are building a two-way call or a low-latency interactive session, the RTMP and SRT modules are the wrong shape, and the RTC module that would fit is still alpha. Choosing HaishinKit for interactivity means betting on the least mature part of the package.

The second comparison is against writing the transport yourself on top of AVFoundation. That is viable for a single protocol and a fixed pipeline, but you would be reimplementing capture session management, audio session handling, screen capture via ReplayKit or ScreenCaptureKit, and video mixing. The library's value is the accumulation of those pieces, not any single one of them.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the most recent push recorded is 2026-09-20. The latest release listed is 2.2.5 from 2026-03-28, described as supporting Xcode 26.4, with 2.2.4 in January 2026 and 2.2.3 in December 2025. Releases are not frequent, and the gap between the last release and the last push suggests ongoing work between tagged versions. The project has a fastlane directory, a Dangerfile and a SwiftLint configuration at the top level, which indicates automated release and linting steps are part of the workflow rather than manual tagging.

The upgrade cost is the part to weigh. A migration guide exists in the wiki, and its existence tells you that major versions have moved APIs. Combined with the Swift 6 and Xcode requirements, upgrading means coordinating a toolchain bump, a language-mode change and an API migration in the same window. For an app with a single streaming screen that is manageable; for a large codebase with custom pipeline code, budget for it.

Licensing is BSD-3-Clause, the same license as the related HaishinKit projects for Android and Flutter listed in the README. BSD-3-Clause permits use in closed-source products and requires retaining the copyright notice and license text. This is a description of the license identifier, not legal advice; confirm the obligations against the LICENSE.md file in the repository and with your own counsel if your distribution model is unusual.

## Conclusion

Adopt HaishinKit if you are building a native Apple app that must publish or play RTMP or SRT and you are willing to read the DocC documentation and the examples app. Avoid it if you need a cross-platform core, Mac Catalyst support for SRT, or a stable WHEP/WHIP path today. Before you commit, verify the Xcode and Swift versions against the support table, confirm that SRTHaishinKit is acceptable to exclude from Mac Catalyst, and check whether the known-issue document covers a problem you are already seeing.

## FAQ

### Which platforms does HaishinKit.swift support?

The README lists iOS 15.0+, tvOS 15.0+, Mac Catalyst 15.0+, macOS 12.0+ and visionOS 1.0+, with watchOS marked as not applicable. SRTHaishinKit is not available for Mac Catalyst.

### How do I install HaishinKit.swift?

The README gives one path: Swift Package Manager, using the repository URL https://github.com/HaishinKit/HaishinKit.swift as the package location. No CocoaPods or Carthage instructions appear in the README.

### What Xcode and Swift versions does HaishinKit.swift require?

Version 2.2.0 and later require Xcode 26.0 and Swift 6.0, while 2.1.0 and later require Xcode 16.4 and Swift 6.0. Swift 6.0 is the floor for both documented rows.

### Is WHEP and WHIP support in HaishinKit.swift production ready?

The README marks the WHEP/WHIP publish and playback feature in RTCHaishinKit as alpha. The documentation does not present it as stable, so treat it as an evaluation path rather than a production transport.

## Sources

- [HaishinKit/HaishinKit.swift on GitHub](https://github.com/HaishinKit/HaishinKit.swift)
- [License: BSD-3-Clause](https://github.com/HaishinKit/HaishinKit.swift/blob/main/LICENSE)
- [Project website](https://docs.haishinkit.com/swift/latest/documentation/)
- [README](https://github.com/HaishinKit/HaishinKit.swift/blob/main/README.md)
- [Releases](https://github.com/HaishinKit/HaishinKit.swift/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haishinkit-haishinkit-swift