8000 WebRTC package on visionOS · Issue #108 · stasel/WebRTC · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

WebRTC package on visionOS #108

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ChristophM2000 opened this issue Nov 5, 2024 · 7 comments
Open

WebRTC package on visionOS #108

ChristophM2000 opened this issue Nov 5, 2024 · 7 comments

Comments

@ChristophM2000
Copy link

Hi,

Are there any plans to support visionOS with the WebRTC package?

Greetings,
Christoph
@pablott
Copy link
pablott commented Mar 13, 2025

I'm also interested. Meanwhile I will investigate how to build it from sources.
Is there a specific reason to not add this like a technical roadblock?

@kevinmore
Copy link

+1. Please make WebRTC available for all Apple platforms!

@pablott
Copy link
pablott commented Mar 17, 2025

For those who are interested, I am experimenting with this repo: https://github.com/because-why-not/webrtc_visionpro_workspace?tab=readme-ov-file
It seems to me the project is not as mature as stasel's but it seems to work. I was able to compile the frameworks for both simulator and device and the Info.plist seems to be generated correctly.
I was able to use it by manually importing the framework files into my project, import WebRTC and use it (in device). I need to do more testing but at first it seems to work well, WebRTC initializes and there were not crashes.
It is also a concern that right now I can't use it as a package, but I think zipping the framework files and turning it into a Package.swift is possible (this would make it easier to distribute as a SDP package for development). Stasel's package follows this route.

@pablott
Copy link
pablott commented Mar 17, 2025 •
edited
Loading

Another alternative is to use https://github.com/livekit/client-sdk-swift which does support visionOS. The WebRTC code is a patched version of Google's one.
In my testing using LiveKit comes with its own issues. You are tied to their way of signaling. You are not forced to use their servers or pay for it but I want to be able to do a simple bootstrapping by passing a hardcoded SDP (or I wasn't able to find it). Perhaps you can just call the WebRTC part of the API.
I was forced to use an external server to do the signaling, which is in theory doable if you set your own server to do the initial signaling but adds some setup effort.

@pablott
Copy link
pablott commented Mar 24, 2025

update: I no longer have the need to pass a hardcoded SDP (in fact, it is not very practical). Signaling is required, with WebRTC you can set it up with no STUN servers (as long as you can pass the local/remote SDP descriptions between devices in some way), but LiveKit seems to force a particular setup by using a server in between for the signaling (which may or may not be what you want). This is something to consider when choosing a solution.

@nevyn
Copy link
nevyn commented Apr 7, 2025

There's no need to pull in LiveKit's client SDK to use their webrtc port. Just use their webrtc package as a dependency: https://github.com/livekit/webrtc-xcframework

However, all their symbols are prefixed by "LK". Seems to work fine other than that? That said, I'm also commenting to subscribe and show my interest in visionOS support in this package :)

@pablott
Copy link
pablott commented Apr 7, 2025

Correct, I realize after I wrote that that you can pull their WebRTC package using SDP.

@kevinmore kevinmore mentioned this issue Apr 20, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nevyn @pablott @kevinmore @ChristophM2000
0