The Problem
MirageKit solves the problem of streaming macOS screen content to Apple's non-macOS platforms (iPadOS, visionOS) without relying on third-party services or cloud relay infrastructure. Screen sharing between Apple devices typically requires either AirPlay (limited to mirroring), a commercial product like Splashtop, or building a custom WebRTC stack. MirageKit provides a native Swift framework for peer-to-peer, low-latency window and desktop streaming using Apple's own networking and media frameworks.
What This Does
MirageKit is a Swift Package Manager library with a clear host/client architecture. The host side (Sources/MirageKit/Public/Host/) captures windows or virtual displays using ScreenCaptureKit and encodes video with HEVC (Sources/MirageKit/Internal/Encoding/HEVCEncoder.swift). The client side (Sources/MirageKit/Public/Client/) discovers hosts via Bonjour, receives UDP video streams, decodes them (Sources/MirageKit/Internal/Decoding/HEVCDecoder.swift), and renders through Metal (Sources/MirageKit/Internal/Rendering/MetalRenderer.swift).
The transport layer is split: TCP for control messages (Sources/MirageKit/Internal/Protocol/MirageProtocol.swift) and UDP for video payloads. The framework also handles input forwarding (MirageHostInputController.swift), virtual display creation (CGVirtualDisplayBridge.swift), and session state management for remote unlock flows. SwiftUI views for streaming are included in Sources/MirageKit/Public/Views/, working on macOS, iOS, and visionOS.
How To Use It
Setup: Add the package dependency to your Package.swift:
.package(url: "https://github.com/EthanLipnik/MirageKit.git", from: "0.0.1"),
Configuration: No environment variables are required. The host requires macOS 26+ and ScreenCaptureKit permissions (handled by MirageAccessibilityPermissionManager.swift). Clients need iOS 26+ or visionOS 26+. Swift 6.2+ is required.
Running it: Implement MirageHostDelegate or MirageClientDelegate and start the corresponding service. The README's Quick Start examples show the minimal setup: hostService.start() for the host, clientService.connect(to:) for the client. No CLI exists; this is a library you integrate into an app.
Real-World Use
A practical scenario: an iPad user needs to access a specific macOS application (e.g., a design tool) while away from their desk. The macOS host runs a MirageKit-based app that advertises itself via Bonjour. The iPad client discovers the host, requests the window list, and the user selects the design app. The host captures just that window, encodes it with HEVC, and streams over AWDL (Apple Wireless Direct Link) for peer-to-peer latency. The user interacts with the app through the iPad's touch input, which gets forwarded as mouse events back to the host.
Code Health & Issues
High - No CI/CD pipeline - No .github/ directory or CI config detected. There's no automated build or test gate, which is risky for a framework with 76 Swift files. Med - Minimal test coverage - Only 1 test file (Tests/MirageKitTests/MirageKitTests.swift) for a codebase this size. The networking, encoding, and capture paths are effectively untested. Med - Platform-specific fragility - The framework requires macOS 26+, which is a future/developer-preview OS. The CGVirtualDisplayBridge.swift and SCKWrappers.swift files suggest direct use of private or unstable APIs that could break with OS updates. Low - No license file - The repo contains a LICENSE file, but the README doesn't state the license type. Verify before commercial use. Low - Single maintainer risk - Forked from a 613-star project; the current repo has 0 stars, suggesting this is a personal fork. Bus factor and maintenance continuity are concerns.
The Bottom Line
MirageKit is a technically ambitious framework that fills a real gap in Apple's ecosystem. The architecture is sound, with clean separation between host/client/transport concerns. However, it targets unreleased OS versions, has minimal test coverage, and no CI pipeline. This is best suited for developers building a specific product on the latest Apple betas who are willing to contribute fixes upstream. It's not yet production-ready for general use.