VCam v2.1.1 Fails to Connect on Apple Silicon (M4 Pro) Due to x64 Architecture Mismatch in Pixel Streaming Plugin** **Product & Version:** Unreal Engine 5.3.2 (also observed in 5.4, 5.5, 5.6) **Platform:** macOS on Apple Silicon

Development Platform & Builds
,
1

Bug Report: VCam v2.1.1 Fails to Connect on Apple Silicon (M4 Pro) Due to x64 Architecture Mismatch in Pixel Streaming Plugin

Product & Version: Unreal Engine 5.3.2 (also observed in 5.4, 5.5, 5.6)
Platform: macOS on Apple Silicon

Summary:
The Unreal VCam iOS app (v2.1.1) consistently fails to connect to Unreal Engine 5.3.2 running on a Mac with an M4 Pro processor and macOS 15.5. The investigation has revealed that this is not a configuration issue but a critical software bug in the Pixel Streaming plugin, which the VCam app now depends on for its connection handshake. The root cause is a setup script that downloads an incompatible x64 (Intel) version of Node.js for the arm64 (Apple Silicon) architecture, leading to a cascade of failures.

Crucially, Epic’s Live Link Face app connects to the same editor instance instantly and perfectly, proving that the user’s network, firewall, and the core Live Link messaging system are all functioning correctly.

Hardware & Software Environment:

  • Computer: Apple MacBook Pro with M4 Pro CPU

  • Operating System: macOS 15.5

  • Unreal Engine Version: 5.3.2 (clean install from Epic Games Launcher)

  • iOS Device: iPhone & iPad

  • iOS App: Unreal VCam v2.1.1 (from the App Store)

Steps to Reproduce:

  1. On an Apple Silicon Mac (M4 Pro tested), create a new, empty project in Unreal Engine 5.3.2.

  2. Enable the Virtual Camera and Pixel Streaming plugins and restart the editor.

  3. Add a VCam Actor to the default scene.

  4. On an iOS device on the same local network, open the VCam app and attempt to connect to the Mac’s IP address.

Expected Result:
The VCam app should connect successfully, and a new VCam source should appear in the Live Link window, driving the VCam Actor in the scene.

Actual Result:
The VCam app fails to connect after 10 attempts. The Live Link window in Unreal Engine shows no new sources. The system fails consistently across all tests.

Detailed Root Cause Analysis (Our Diagnostic Journey):

Our investigation has pinpointed the root cause to a cascade failure originating from a single flawed script.

1. Initial Isolation (Live Link Face Success):
The key discovery was that Live Link Face connects perfectly to the editor. This immediately proved that the network, router, firewall, UDP messaging, and the core Live Link plugin are all working correctly. This isolated the fault to the VCam-specific software pipeline.

2. The VCam App’s Two-Stage Failure (from iOS Logs):
Analysis of the VCam app’s own logs revealed a two-stage connection process, both of which fail:

  • Stage 1: Beacon Failure: The app’s primary connection method—a UDP multicast beacon—fails with a SocketException: No route to host error, even with cellular data disabled. This is a networking bug in the VCam app itself, as Live Link Face uses the same method successfully.

  • Stage 2: Pixel Streaming Fallback Failure: The app then falls back to its secondary method: attempting to establish a WebSocket connection to a Pixel Streaming server it expects to be running on the Mac’s Port 80 . This also fails, with the app log showing WebSocketException: Connection … was not upgraded to websocket.

3. The “Zombie” Plugin State (from UE Logs & Editor Behavior):
The investigation then focused on why the Pixel Streaming server wasn’t responding. We discovered the plugin was in a non-functional “zombie” state on the M4 Mac:

  • The console command PixelStreaming.Start is recognized but fails silently with no log output.

  • The Pixel Streaming settings menu is completely missing from the Project Settings UI.

  • The editor consistently crashes on quit , with the crash report pointing to the Slate UI and Property Editor systems trying to clean up the broken, uninitialized UI components of the faulty plugin.

4. The Smoking Gun (The Setup Script’s Architectural Flaw):
The final breakthrough came from locating the setup script that the Pixel Streaming plugin runs in the background. The script, found at …/PixelStreaming/Resources/WebServers/platform_scripts/bash/, contains a hardcoded architectural flaw:

Generated sh

NodeVersion=v16.17.0
DownloadedNodeFolder=node-${NodeVersion}-${NodeOS}-x64

Use code with caution.Sh

This script is responsible for downloading a required Node.js executable. It correctly identifies the OS as darwin (macOS) but incorrectly hardcodes the CPU architecture as x64 (Intel). It does not check for arm64 (Apple Silicon).

This causes the script to download a version of Node.js that is incompatible with the M4 Pro processor, leading to a silent failure when the editor attempts to launch the Pixel Streaming web server. This single failure is the root cause of the “zombie” plugin state and the entire cascade of subsequent errors.

Suggested Fix:

The bug can be patched by editing the aforementioned setup script to detect the CPU architecture and download the correct binary.

Proposed Change:
Modify the script to include a check for the machine architecture:

Generated sh

# Check machine architecture to see if we are on Apple Silicon
Arch="x64"
if [ "$(uname -m)" = "arm64" ]; then
  Arch="arm64"
fi

NodeVersion=v16.17.0
DownloadedNodeFolder=node-${NodeVersion}-${NodeOS}-${Arch} # Use the detected Arch
NodeName=${DownloadedNodeFolder}.tar.gz

Use code with caution.Sh

(Note: Our attempts to apply this fix were unsuccessful, indicating the C++ code that launches this script may be failing even before the script is executed, pointing to a deeper incompatibility.)