Cross-platform Vulkan screen sharing with WebRTC

Principal Consultant·2020·4 months·2 min read

Shipped Mac and Windows desktop apps with embedded WebRTC for low-latency remote screen sharing.

Overview

Built C++ desktop applications for Mac and Windows that capture and share screens over WebRTC. The client needed a native renderer (Vulkan) with reliable cross-platform delivery, not an Electron wrapper.

Problem

The product required real-time screen sharing between desktop clients with acceptable latency on both macOS and Windows. A browser-based approach was ruled out; the rendering path needed direct GPU access and tight control over capture and encode pipelines.

Constraints

  • Vulkan 1.0 only — no reliance on platform-specific graphics APIs for the renderer
  • WebRTC stack had to embed in existing C++ codebase, not run as a separate process
  • Mac and Windows feature parity required from a small codebase
  • Session signalling handled by a separate Golang backend

Approach

Implemented a shared C++ core with platform-specific capture and windowing shims. Vulkan handled rendering; WebRTC handled transport. Paired with a Golang backend for session relay and presence.

Key Decisions

Vulkan 1.0 for rendering plus in-process WebRTC, rather than Electron

Reasoning:

Vulkan via MoltenVK on Mac and natively on Windows gave one rendering path instead of two. Embedding WebRTC in-process avoided copying every captured frame across a process boundary. The trade — more C++ complexity upfront — matched a client building a long-lived product rather than a demo.

Alternatives considered:
  • Electron with Chromium's WebRTC — fastest prototype, but a large binary and little GPU control
  • Platform-native graphics (Metal + D3D) — best per-platform performance, two codebases to maintain
  • Separate WebRTC media server process — isolates crashes, but IPC on every frame

Thin platform layer for capture and windowing, shared core for everything else

Reasoning:

Screen capture and window management are the only genuinely platform-divergent parts of the product. Isolating them behind a narrow shim kept the C++ core — rendering, encode, transport, session handling — identical on both targets, so feature parity was the default rather than a per-release effort.

Alternatives considered:
  • Separate Mac and Windows applications sharing only the protocol
  • Cross-platform framework abstracting the whole application layer

Tech Stack

  • C++17
  • Vulkan 1.0
  • WebRTC
  • Golang
  • Redis

Result & Impact

  • macOS + Windows
    Platforms
  • One C++17 core
    Shared codebase

Delivered working Mac and Windows builds with embedded screen sharing. The Golang session backend handled relay and presence. Client could demo the product on both platforms from one codebase.

Learnings

  • MoltenVK is viable for Vulkan-on-Mac but needs early validation of extensions you depend on
  • Screen capture APIs differ enough between Mac and Windows that a thin platform layer pays off quickly
All projects