Hacker News Reader

Comment by astlouis44 | Hacker News Reader

Very excited for this. My team is bringing Unreal Engine to the browser, and it works great on computers but not so much on iOS due to the restrictions that iOS brings. Being able to use a Chromium browser together with WebGPU will enable a whole new distribution path for game developers who don't want to fork over a 30% tax to Apple. The open web allows for direct online distribution with no middlemen, that's always been the beauty of it.

Video demo of our platform: https://youtu.be/WSIFyz-2PeY

View on HN

This seems like a really elegant solution - it simultaneously improves browser technology for all of the internent and avoids the appstore walled garden tax.

The hope would be to that Unreal makes a generically useful browser that can navigate to any web page (include hacker news) so it can't be blocked from/taxed by the appstore. But also provides W3C/industry standard compliant WebGPU advances and ways to cache login info/game assets/game states and handle game networking - of which Unreal as well as its competitors such as Unity can use if they wanted to.

If Unreal implements its browser hooks in a non-standardized, purposefully cryptic proprietary way - then they are really just creating their own walled garden - which they can do but can't really claim any moral high ground (if that's important to them).

Sounds interesting. How do you store assets? Unless it's a tiny game (for which UE4 isn't a great fit either) you could be looking at having to download 100MB or more every time you launch the game.

Some of the biggest changes in gaming engines is that they have gotten much much more advanced about streaming first low res assets in, starting the game, then continuing to stream high res assets in on the fly.

Even if a user doesnt have cached assets (which i think is the main point against your supposition, that assets can be cached after first launch), ideally a modern game could still load very fast at very low fidelity & keep pulling down higher fidelity assets as the user plays.

Exactly, this is what we're doing with our asynchronous asset fetching system.

We have our own asset fetching system which only loads in what is absolutely necessary, for example you don't need the entire game and can often get away with loading the first 5% or so. Everything else (assets) gets streamed in at runtime in the background.

Streaming sounds great. 5% instead of the whole game is an improvement over downloading 100% just to use a small portion of the game. But if the user has to keep re-downloading those 5% over and over, then it's a bit of a wash no?

Pretty sure you can get the browser to cache websites no?

> who don't want to fork over a 30% tax to Apple

a) It's 15% for most developers and not a tax by any definition.

b) It only applies to applications which accept money from users.

c) No government has ever said that Apple is not entitled to this.

d) You would have to be crazy to think Apple will allow b) without them being compensated. What is likely to happen is that Apple will have a Payment API that you as a developer will need to call every time you accept a payment. They will then bill you for the 15% each month and ban you for non-payment. And reconciliation is easy because they can simply download your app, trigger a payment and make sure they see a corresponding request for their API.

This wouldn't be acceptable under the spirit of these regulations. And definitely wouldn't be acceptable to a lot of us.

If apple wants, they can split their OS and their phones if they want to "make money for writing an OS". At the same time that'd also obligate them to make it possible to install android OS on their hardware.

But yeah no, apple does not "deserve" a percentage of your revenue because they have written the OS and don't let you switch the OS.

Imagine arguing Microsoft should charge people x% of every software sale because they write the OS.

> This wouldn't be acceptable under the spirit of these regulations

You clearly haven't been paying attention to the EU regulations. Because it is exactly in the spirit of them and what Apple did in response to Dutch authorities demanding third payment providers [1]. They got their 15-30% either way.

And it is completely normal for Apple to have a commission on application purchases made on their platform. It's no different to how many websites e.g. Shopify or hardware e.g. Playstation work.

[1] https://developer.apple.com/support/storekit-external-entitl...

I have been. And I expect apple to get in a lot of trouble over the decision with NL.

I actually wouldn't be surprised if we saw a huge % of global revenue fine for that. And apple would deserve it.

if games work in browsers, then they would have to ban the browser, which would presumably run afoul of these rules....

I think you're confused. There are two ways to distribute applications:

1) Create a website and ask users to open it in Safari/Chrome. You have not benefited from Apple's technologies nor customer base that they acquired. You used your tools, you acquired your customers and so Apple claims no commission.

2) Create an app that is a wrapper around WebKit/Chromium. For this case you have used Apple's technologies (e.g. Swift/XCode) and you are benefitting from Apple's customer base (via the App Store). Whether you download the app from the App Store or a third party store is irrelevant. From Apple's perspective you still owe the 15-30% commission.

And as I mentioned below this is not hypothetical. It's exactly what happened in Netherlands.

3) Tell your users to install the free unreal browser if they want a discount and cross-platform support.

So you’d need to get users to install a supported browser on their device before they could play games built in this? That doesn’t seem like a great experience.

You are assuming everyone would stay with Safari?

I'm not sure the percentage, but a lot of people already use chrome on iOS. Which is just a wrapper around apple's browser engine (webkit).

If apple allows other browser engines, then Chrome would be an automatic app update away from changing to the chromium engine (blink?).

Safari has pretty high market share, something like 90% or something. However, I have a feeling Apple will want to compete with Google by if it becomes known that updated Chrome can play actual games on iOS through a mobile browser.

> The open web allows for direct online distribution with no middlemen, that's always been the beauty of it.

I'm still surprised considering it's basically WebKit under the hood. What are some of the things that don't work on iOS? Are they part of WebKit and removed for arbitrary reasons or is WebKit worse than I imagine?

- Safari Browser Extensions only work with Safari.

- Other browsers can’t have extensions.

- Stuff like WebTorrent or IPFS gets held back on iOS because WebKit.

- Only Safari can create app shortcuts on the Home Screen, even if you change your default browser

- Safari refuses to support WebMIDI, so only way to get MIDI access on iOS is to publish an app on the AppStore

- The website time limits feature (in ios settings) only works if you open the website in Safari. Other browsers can’t respect this setting.

Apple is building a web browser engine, Google is building a sandboxed application runtime - that happens to be a web browser engine superset.

False narrative.

Google is building a web browser engine that matches the current needs of developers, while Apple has under-invested in its engine for years, leaving it rigged with bugs and lagging behind others in an obvious attempt to prevents web apps from competing with natives apps on iOS to preserve its App Store revenues and enrich its app ecosystem to boost iDevices sales.

This x 1000. Couldn't have said it better myself. Apple is greedy and doing everything it can to preserve it's precious App Store riches powered by their 30% tax.

Reply on news.ycombinator.com