From what I've been told, they are looking to hire 1 engineer. I guess that is better than nothing, but it doesn't look like webrtc is going to be any sort of priority for them. Also, it may not be super valuable in Safari, which has a small market-share. Where it is needed is mobile safari. From what I understand having it in Safari does not mean it gets built into mobile Safari.
Also, note the date of the posting. 4 months ago and still there...
From what I’ve read, Ericsson and other Scandinavian companies have already had a few engineers working on WebRTC in WebKit for several months now. Apple only has to connect that implementation to their OS endpoints (or something like that). One engineer should be enough.
If you look at the WebRTC in Webkit bug report (https://bugs.webkit.org/show_bug.cgi?id=143211), they have been steadily working on it since March 2015 and it looks like they are making good progress.
iOS Safari has a large marketshare. WebRTC is more than video conferencing.
It's also peer to peer networking which is a huge win for certain kinds of apps
I would be surprised to see any web standard that makes iOS Safari better for "appy web apps" (web apps that are more like native apps rather than documents and forms) implemented, as that eventually just makes Safari an alternative AppStore without reviews.
Of course I would love it because as a developer this is the dream but I am very skeptical that Apple will do it.
> I would be surprised to see any web standard that makes iOS Safari better for "appy web apps" (web apps that are more like native apps rather than documents and forms) implemented, as that eventually just makes Safari an alternative AppStore without reviews.
Which is pretty much what Apple has been pushing since before there was an appstore? To this day it takes just 2 taps (share > add to home screen) to add a webapp to the phone as a "standard application" (with a homescreen icon and everything)
There's plenty of serious crap[0] in the apple web ecosystem, but it doesn't really seem related to "webapps as appstore replacement"[1][2][3].
But that "app" doesn't have any real capabilities so what's the point other than bookmarking websites?
There's no background sync, proper offline, no notifications, no (usable) indexeddb, no rtc, no file system, no media sinks, no media sessions ... these are from the top of my head.
You have a point that long time ago Apple was the one pushing the browser as application platform but today is not the same as the long gone past.
Edit: The can-i-use about "web audio" is misleading about Safari. The web audio is prefixed there with "webkit" is not the same as the standard API.
Edit2: Noticed it's not about "web audio" at all but html5 audio. That's an API from 2010 that doesn't really do anything for apps such as games or audio editors. The newer Web Audio API is used for this and that's what I am referring to.
>There's no background sync, proper offline, no notifications, no (usable) indexeddb, no rtc, no file system, no media sinks, no media sessions ... these are from the top of my head.
So, more or less just like with the desktop web.
What you describe is not web apps, it's some proprietary hybrid mix allowed inside Safari with hooks to the whole OS.
* background sync is not a web standard, it's experimental chrome tech (though it's been submitted to the WICG)
* I can only assume "proper offline" refers to service workers which is a WD with partial support (in the browsers in which it's implemented, which exclude Edge and webkit), webkit has it listed as "under consideration" and the last spec revision landed around the time of the last major safari update (mid-2015)
* notifications is fair, note that desktop Safari supports and that there's almost no mobile support at this point (also not supported yet in Edge)
* indexeddb is fair wrt current standards, but does not support "apple hates webapps" considering safari supports websql
* rtc is fair, and in development
* filesystem is proprietary chrome tech, dropped from standard track
* media sinks is fair, a WD with incomplete support on chrome
* media session is in development everywhere except edge
All in all, as far as conspiracy theories your comments mostly support you being a chrome shill.
There are probably hundreds of new APIs that have come after 2012 or whatever the year was when the ball was dropped. Those were just "from the top of my head" not something to be nit picked.
I didn't also literally mean that they are currently implemented by all of those browsers today. My point is that I expect them to be implemented browsers other than Safari sooner or later as they have strongly signaled. Safari has not signaled anything about them. Or if they have, provide evidence of it and I will apologize.
> filesystem is proprietary chrome tech, dropped from standard track
>I didn't also literally mean that they are currently implemented by all of those browsers today. My point is that I expect them to be implemented browsers other than Safari sooner or later as they have strongly signaled. Safari has not signaled anything about them. Or if they have, provide evidence of it and I will apologize.
Has Android's mobile Chrome browser signalled anything more?
Because for years it has been even MORE behind Mobil Safari regarding speed and capabilities.
(And let's not even get started on the crap-fest that was Android's default browser).
>I would be surprised to see any web standard that makes iOS Safari better for "appy web apps" (web apps that are more like native apps rather than documents and forms) implemented, as that eventually just makes Safari an alternative AppStore without reviews.
This conspiracy thinking has been played again and again.
Few users cares for logging into some website from mobile Safari just to get a subpar experience over a native app (or a hybrid app), and that's not because Safari presents any kind of worse web experience than the desktop.
In fact Safari has often been the best mobile browser, but it still doesn't compete with the AppStore that much, as the most important things -- more than half a billion of credit cards on store, easy monetization, in-app purchases and full access to native APIs are missing from the web-app story.
> In fact Safari has often been the best mobile browser
There are no other browsers on iOS. When you are using Chrome it is using UIWebView (in other words, it is forced to be a crippled Safari due to anti-competitive policy). Although recent Chrome will be using WKWebView which means at least it's same as Safari. The UI around the browser is not the browser.
> Few users cares for logging into some website from mobile Safari just to get a subpar experience over a native app (or a hybrid app),
Few users could tell any difference between native app and web app running in a browser that has modern appy capabilities, provided there is same quality of implementation. The only thing that can make the experience subpar is precisely the lack of capabilities.
>In fact Safari has often been the best mobile browser
I know. I meant across platforms. It's obviously the best on in iOS.
>Few users could tell any difference between native app and web app running in a browser that has modern appy capabilities, provided there is same quality of implementation. The only thing that can make the experience subpar is precisely the lack of capabilities.
For one, a web app adds the extra burden of a JS VM and DOM over native code. This rules out all kinds of graphic and CPU intensive apps. Actually, for any app that's not just a glorified content screen / database view, there's not even a comparison between a web and a native implementation.
Even for basically text-based content consumptions apps, like Flipboard, they had to jump through all kinds of hoops to get smooth 60 fps scrolling within a web view.
And of course there's the battery life, that's a real killer with web apps.
A future based on web apps for mobile is a regression over even 2005's state of the art in the desktop. And it's an experience similar to cross-platform apps -- that is, a "lowest common denominator" across mobile platforms.
I'm currently integrating the WebRTC interface into a browser-like project by directly calling into their C++ code (when Java is the preferred interface). Most of the process so far has been trial-and-error (especially with hooking up their JNI calls back to Android from C++ land in order to access Android audio device info and state that can't be reached from C++). The code base is quite large and so gaining familiarity with it has been challenging.
I can see how a single engineer's time is necessary for this project, as I've already sunk over a week of work into my own integration, and I've only gotten the peering to work so far (audio is just about there).
Supposedly many years ago, there used to be an example inside the code base of what I am currently trying to pull off, but nevermore.
It is quite challenging to just integrate WebRTC -- one does not simply integrate WebRTC.
> especially with hooking up their JNI calls back to Android from C++ land in order to access Android audio device info and state that can't be reached from C++
Good luck with that part.
<rant mode="on">
I have been using C++ for hobby coding between Android and WP, and the "friendliness" of the NDK has made be look for solutions that can target Java and .NET instead.
Some of those APIs that one needs JNI wrappers, are actually written in C++, just not exposed to the NDK.
Currently working through that now, the issue du jour is that the class loader apparently does not find classes in the APK unless it is called from JNI_OnLoad from the application thread so I am going to have to cache references to the three or so WebRTC Java audio classes that it needs.
It's interesting to note the unprecedented success Apple has achieved at keeping millions of its users at the very leading edge of Apple OS technologies along with its "difficulties" keeping up with new Web technologies.
And it's amazing how rapidly they are able to invent a whole new programming language, compiler, toolchain, overhaul the OS APIs, add new OS features, and innovate Apple-only "native" technologies on Macs, iPhones, iPads, and even watches, while porting some features from open-source browsers into Safari is so darned "challenging". (I'll bet Apple could get some help from organizations with more resources like, say, Mozilla or Opera, if they just asked.)
I might suspect that they were intentionally impeding the progress of the Web, sabotaging all of us while putting on a great show, if it weren't for the fact that they allow other browsers, such as Chrome, on the iPhone. No, if they wanted to slow the progress of the Web platform, they would slow the development of their own browser as much as they dared and simultaneously cut off all detours around it except the one that goes through their own native apps.
But no, they aren't doing anything like that, because there's Chrome right there in the App Store. As long as it's not some sort of trick, some sort of imposter, there's no reason for suspicion....
I don't think you realize this, but Chrome on the App Store is actually just a shell with the Chrome UI around the embedded Safari browser, rather than the actual Chrome browser, due to Apple restrictions.
Chrome does not run on the iPhone - instead it's a Safari UIWKView (until two weeks ago UIWebView) - the only "Chrome" there is the UI on top of it.
Apple does not actually allow running Chrome on iOS so Google worked around it by giving you a handicapped version of Safari with Chrome UI that lets you share tabs between the computer and the box.
edit: just saw someone else posted a similar comment - so upvoted his - not deleting this since it has some additional info.
> I might suspect that they were intentionally impeding the progress of the Web, sabotaging all of us while putting on a great show
You think they aren't capable of that? Isn't it the same thing they are doing now with not supporting Vulkan and sabotaging open graphics API by pushing their lock-in Metal instead?
That's a real shame because now I'm definitely stuck using OpenGL ES for my cross-platform mobile game instead of a modern stateless API because I just don't have the bandwidth to write my rendering code twice.
You can consider ditching Apple platforms for good. They don't want to support developers? They can get lost. I think it's the only language they understand.
6 months? Firefox before auto-updates had faster turnaround for the updates. Not only that iOS still doesn't have auto-updates. The user still has to manually agree to the nag. It's ok when your app is the iBooks. Not so when it is a modern browser.
But it is a problem when you only release 4 or 5 OS updates per year. All the built in apps on iOS require full OS updates to patch. Some iOS minor versions have existed solely to patch Apple Music. It's pretty terrible.
Isn't arguing for adoption as a measure of value rather putting the cart before the horse?
People use things when they have utility. They have utility when developers make something cool that uses them. Developers do this if there's a chance of mainstream adoption...
A lot of things Apple does is ridiculous, or at least they seem ridiculous - they seem so to me at least (or maybe I just find them frustrating). But I think (and I don't have a detailed theory regarding this) it works well for Apple's walled garden business strategy. Good or bad, they seem to be selling well.
As it has been said many times - they sell "experience", not merely products. Now, in today's tech market this is up for debate and fairly so, but people (the people who exclusively buy Apple products; in most cases because thsoe are Apple products) do believe they are buying that so called experience and what that experience lacks they explain to themselves as features.
I know that Safari does not support everything say Chrome does, but if you do not need those features, what does it matter? An example: I use Safari without having flash installed. I rarely need flash. If I do need it, I would rather open Chrome and close it when I am done with the flash thing and go back to Safari. Why? Why not use Chrome all the time since it supports (almost) everything Safari does and more? Well, because in my opinion, for what I use a browser for 99% of the time, Safari works better. I think it looks, performs, functions and feels better overall. So I would rather use Safari and switch to Chrome when I need something Safari does not do, or Chrome does better, even though on the paper spec, Chrome is the better browser.
It is the same reason I use an iPhone even though Android "has the same and more features".
Remember when IE was the gloomy figure in the corner of the room that every developer knew was there, but there was nothing they could do about it?
People didn't catch on that IE was bad until almost a decade later, by then it had finally gotten not bad. These days I don't even have to think about it because my websites work better in it, more often than not, when I open them in it for the first time.
Safari is the one I have to worry about now. It isn't just features, it's page rendering. Not having WebRTC is something all on its own.
But web technology is extremely complex.
If you fall off spec, and then find yourself needing to support those off spec 'features' it holds everyone back for a long time. How long will it be before Safari users find out how frustrating they can be to web developers?
I think the perspective is skewed, because who are websites for? Not the developers, that's for sure. It's for the users, and if the users think that Safari is better, than there might be a reason for this madness, and the other browsers should adjust their goals.
I'm a developer myself, and did webdevelopment professionally for 7 years until I switched paths 3 years ago. I know all about supporting multiple browsers and what not. But the thing is, Chrome just doesn't feel and look elegant and smooth like Safari does. The same with Firefox. That's why I use Safari 99% of the time.
There's a balance between functionality and design, and chrome seems more skewed towards functionality, and Safari towards design. When this is so, and Safari does all I need better than chrome 99% of the time, I naturally choose safari.
...and yes, Safari should be more standard compliant, I'm not disagreeing with you on those points.
> chrome seems more skewed towards functionality, and Safari towards design.
Not supporting standards has nothing to do with design. It's either a deliberate sabotage of interoperaibility for the purpose of lock-in and anti-competitive crookedness (not unlikely for Apple), or simply total neglect. Either way, it results in technology being held back because Safari has enough of a market share to do it. That's why calling it "new IE" (in a derogatory way) is quite appropriate.
> Chrome just doesn't feel and look elegant and smooth
I bet this feeling comes from the "smooth scrolling". Development Chrome currently has it, I really cannot imagine why didn't they do it earlier it's so trivial to do for major benefits.
That's one thing yes. Another is the aesthetics of Safari that feels like it belongs inside of OS X, which I use, where Chrome just looks like it's own kind of deal. There's also the thing about battery life, which again, is a design decision Apple has made (lightness over ultimate performance), and I like that too. I don't do heavy webgl or css3 stuff every minute every day, so I don't need my browser to go "all in" when it comes to performance that I don't feel anyway that in turn reflects badly on my battery. And truth be told, the only place I use my computer plugged in is at work. The rest of it time it runs on battery power, so that's a big deal too.
Flash is a poor example because Flash really should be gone for good already. The problem is not "features" but Apple holding back technology progress. That's simply bad. There were some recent articles calling Safari "the new IE" because of this.
More or less ridiculous than the App Store? As a side note, I haven't had anyone else's developer notifications for about 3 weeks now. "In review" notifications for other people's products coming to me is a little disconcerting.
You're correct about iOS. For OS X, open App Store and then Updates. You'll see individual Safari updates (separate from OS updates) in the update history.
How about the security issue with WebRTC where the browser leaks the IP address? It's part of the way WebRTC works so I can't see how that can be fixed. It's both a security issue and a key enabling feature.
Update:
It looks like Google Chrome (desktop) team has published a plugin that alleviates the problem but can cause performance degradations with apps that use WebRTC. They seem to suggest that a decent fix won't be possible until UDP proxies are in wide use and Chrome adds support for that.
I don't have a full understanding of WebRTC, but AFAIK its a browser-to-browser connection library. How would that work without leaking the ip address? The browser at least has to know who to connect to?
I don't really know anything about this topic, but the parent comment leads me to believe that you would use a UDP proxy to hide your address. Instead of sending out your address, you'd send out the proxy's address. When the proxy receives data, it would pass it to you. That way the other party doesn't know your address; they only know the proxy address. This is just a guess based on how I assume proxies would work, so I may be wrong.
People are typically okay with site owners having their IP, because site owners tend to not be malicious. You could only connect with people that you completely trust, but with many applications the users might be complete strangers or merely internet acquaintances. Given the power, there would be malicious users taking advantage of it. This was a big deal with Skype because people weren't aware that adding a contact could reveal their IP to that person, and/or were not aware that revealing their IP could lead to DDOS attacks or other forms of abuse/stalking.
> How about the security issue with WebRTC where the browser leaks the IP address
Yes, even if the user is behind a VPN, WebRTC will expose their ISP-given public IP. Luckily Firefox allows WebRTC to be disabled. Recently they added a new setting that alleviates that leak for the majority of VPN users, while allowing WebRTC to still be enabled. Would be awesome if Chrome allowed WebRTC to be disabled as well.
Why is this a thing? Your local ip address can be easily guessed. Also, secrecy is not security. I think 'exposing addresses' is a red herring, in such a small address space.
You mean most people leave their routers at default, and have an IP of 192.168.(0|1).1xx? Shocking... shocking I say.
I have to agree... the local IP address really shouldn't be considered a secret, it's also needed for LAN negotiation attempts between localized peers.
webrtc is horrible to build and integrate with a native project, even without the quirks of ios or os x to deal with. i feel sorry for whoever gets the job.
I had a look at the code a while ago, with the idea of using the AEC functions. However I quickly realised that it would be practically impossible to do that, and it would probably be a lot easier just writing it myself (even though that would be a hell of a job).
I've only ever associated WebRTC with its ability to expose the real IP address when surfing with a VPN. I am unsure if this bug is unique to Firefox, and I hope the bug doesn't show up in Safari.
Service workers seems like an incredibly dangerous feature to have in a web browser. If developers need geofencing notifications or assets caching for example then implement a tightly focused API. But to allow any developer (including rogue ones) to slow the browser and computer down will be a nightmare for inexperienced and experienced users alike.
My brother launched a website about a month ago built around WebRTC. The idea is to facilitate meaningful one-on-one videochats between people who share similar interests in life or at the moment.
Also, note the date of the posting. 4 months ago and still there...