Hacker News Reader

Comment by astlouis44 | Hacker News Reader

WebGPU + WebAssembly is an alternative way around walled gardens, which would enable Epic to distribute Fortnite to iOS users via a client side web-app, enabling them to bypass Apple entirely.

View on HN

> which would enable Epic to distribute Fortnite to iOS users via a client side web-app

I'm sure Epic would be super excited to implement all of Unreal Engine in WebGPU.

They're already working on a WebGPU adapter :)

They are?

https://www.google.com/search?q=webgpu+unreal+engine

The top result there is a third party trying to achieve this. Not Epic themselves.

Such I've heard from some friends that work there. WebGPU isn't even released on most browsers, so it's unlikely we'll see it for several years.

It's not that much different from Vulkan.

It would certainly be a great thing if UE was to have a second try at this. Nothing on any of the public roadmap (https://portal.productboard.com/epicgames/) or references in WIP code that suggests this. Lets hope your friends are correct :P

I got the impression the HTML5 with WebGL platform was removed at least partly to minimize the scope of work with some of the large renderer changes Epic has made between 4.26 and 5. So now does seem like the right time for them to try to tackle the problem again.

WebGL was based off openGL, which was already pretty much deprecated at the time browsers implemented it for better APIs like Vulkan/Metal.

Do you have proof?

That doesn't work if Apple doesn't add support for WebGPU in their Safari, which is the only browser engine on iOS. It barely got push notification support. Hell I can't even play a standard opus audio file from Safari.

a) Apple was part of the working party for WebGPU.

b) It's already implemented in Safari Technology Preview.

c) No browser other than Chrome desktop supports it: https://caniuse.com/webgpu

I'm not speaking about WebGPU specifically, just about how Apple is generally behind in implementations, especially on iOS. Apple supported push notifications on MacOS Safari for years, and just recently has it only been added to iOS. Even that Safari Technology Preview is only on the MacOS version of Safari, so like push notifications, doesn't mean iOS support until it happens.

"Behind in implementations"—of non-standard "standards" Google loads into Chrome and then pushes devs to include in their web apps, just like Microsoft did with ActiveX back in the day, and for exactly the same reason: so that not only does their stuff only work on Chrome, but people like you see it not working on Safari and think the reason for that is that Apple is somehow working against them for nefarious purposes.

I don't think that works when Apple have implemented notifications on MacOS Safari for years. So it's not that Apple disagree with the standard, but they don't want to bring it to iOS.

Apple are even on the WHATWG standards body that defined notification spec: https://notifications.spec.whatwg.org/ . And WHATWG is the actual standard, not a non-standard standard. W3C ceded to them a few years ago, which is news to me.

If we were talking about other features, like Web Bluetooth or Web HID which are just drafts on W3C but Google decided to implement anyways, I wouldn't disagree with you. I use Firefox myself, so none of these are supported on Firefox either.

> So it's not that Apple disagree with the standard, but they don't want to bring it to iOS.

This argument would have held a lot more water a couple months ago ago, before Apple implemented web push notifications on mobile Safari. [0]

[0] https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-a...

Apple intentionally sabotages iOS safari to stop you from doing this.

Everything makes sense now. I’ve wondered for years why they’ve dragged their feet with Safari and your hypothesis fits. I wonder if MS followed the same line of reasoning in the 00s.

Reply on news.ycombinator.com