Webrtc in Safari was and still is the most popular post on my site. Lots of hits coming directly from search engines. I get a lot of e-mails and questions regarding the current status. I thought it would be a good time to do a follow up.
Thanks to the push by the webrtc-in-webkit project, most of the webrtc implementation in webkit is now done. Using the linux GTK+ port as the browser on top of webkit, Adam from Ericsson R&D achieved interoperability with chrome.
Now two things are currently happening.
Since june 2015 last year, Apple has been dedicating resources to bring GetUserMedia and the underlying MediaStreams object in the mac and iOS ports (this code is only used in safari, illustrating beyond doubt that apple is not just working on webkit, but on safari). They published a job opening, and activity in webkit is obvious.
Since december, webrtc-in-webkit has been porting the PeerConnection bits upstream to the main webkit repository, as explained by their blog post. Since january 2016, and the help of a few sponsors, the webrtc in webkit project has enrolled the help of webkit experts Igalia to fasten the upstreaming process, to have more chance to see both GUM and PeerConnection in the next version of Safari. [On a side note, more sponsors are needed for Q2]. Here again, the activity in webkit is obvious.
Now, there are a lots of rumors going around, one way or the other, about Apple’s webrtc involvement, and wether or not we will see webrtc in safari, ever. I do not like rumors. The best way to know, is to test. Fortunately for me, there is an easy way to test if a given API is about to go in next safari version: webkit nightly builds. Nightly builds of webkit are made available for everybody to test against. It uses your installed safari front-end, and dynamically replace the internals by a nightly build.
You will need to have at least 10.10 for it to work. It’s also recommended to have the latest safari (9.0.3). webkit nightly will appear with the same logo as safari but different color, and the user agent string. More importantly, nightly will have latest Apis and improvement. In our case, even though the implementation is not testable as it because of the lack of permission prompt, you can verify that both old and new GetUserMedia APIs are here and that the later support promises. MediaTracksConstraints and other objects can also be found. Finally, even if RTCPeerConnection is not yet available, many other objects like IceCandidates, RtpSender, RtpReceivers are, showing the base of an implementation of the latest specifications.
Happy Testing.
[UPDATE] – Details on how to tests and preliminary results have been posted there.
This work by Dr. Alexandre Gouaillard is licensed under a Creative Commons Attribution 4.0 International License.
This blog is not about any commercial product or company, even if some might be mentioned or be the object of a post in the context of their usage of the technology. Most of the opinions expressed here are those of the author, and not of any corporate or organizational affiliation.
>> iOS ports (safari exclusive)
What doe you mean by “safari exclusive”? Does it mean *only* Safari (i.e., “Safari, exclusively”) or does it mean everything *except* Safari (i.e., “excluding Safari”)? Thanks.
Good catch.
Some Apple employees are also webkit maintainers. Their activity in webkit can be separated from their activity at apple. Since the mac and iOS ports of webkit are only used in Safari, one can be sure that activity on this two ports code is indeed for safari. I updated the text to reflect this.
I tried using Safari Technology Preview but navigator.getUserMedia didn’t work. I didn’t even get an error. It was just seemingly ignored.
Do you know when it will be supported in Safari? Right now I can only get it working in Frefox on my desktop.
you need to catch the returned promise and process it. You should see an UserDeniedError.