HN user

agust

793 karma
Posts10
Comments120
View on HN

The security/privacy argument has been debunked many times.

How do you explain that all other OSes, including Apple's own macOS, manage to allow other browser engines?

Do you think the iOS team is that incompetent?

Worth noting that Apple doesn't just cripple iOS Safari, it cripples all iOS browsers because it also forces them to use WebKit, the crippled browser engine underneath Safari.

It would be fine if they just made Safari bad, that's their choice. But they don't stop there: they make the entire web bad on iOS purposely to promote the native apps they can tax.

Yeah that's why the bigger the market they can reach with a version using their own engine, the more likely they are to invest into doing it.

Now the question is what's the threshold for this market to be big enough? Maybe Japan's joining in pushes it past that point.

Yeah other reasons I've heard of include the obligation to adopt iOS-specific APIs for features like scrolling and text inputs; developing a separate app for these markets and therefore loosing their existing userbase; and signing a pretty crazy contract, among other things.

But the bigger the market they can reach, the bigger the reward, and so at some point it may justify investing resources to work around those roadblocks and accept the drawbacks.

So after the EU and the UK, Japan is now putting an end to Apple's iOS alternative browser engine ban too.

Those are 3 large jurisdictions, I wonder if that's now a market big enough for Chrome and Firefox to invest into iOS versions of their browser that use Blink and Gecko under the hood. From what I heard this was one of the main reasons they haven't done it yet.

The likely outcome of alternate, capable browser engines coming to iOS will be to push Apple to invest in Safari so it can compete with them and not loose all of its market share.

Otherwise, yes it's likely web apps will prompt their user to use a browser with a capable engine on iOS if they exist. Nothing to configure, install and use.

Users will then be able to use capable web apps that take up a tenth of the storage of native apps, that are cheaper and portable across platforms — among many other benefits.

Browser engines define the capabilities of web apps and websites. When they don't support APIs or have bugs, they impact negatively web software.

Apple's WebKit is renowned to be lagging behind, refusing to implement crucial features and being rigged with bugs, hence limiting the capabilities and quality of web apps, and effectively preventing them to compete with native apps.

Getting other browser engines on iOS would be beneficial for developers, businesses and end user by making mobile web apps viable.

Apple vs the Law 1 year ago

I didn't say Apple invented mobile web apps. I said Apple invented the ability to install mobile web apps on device.

I'm not 100% sure no other mobile OS allowed this before to be honest, but I'm pretty iOS is the one that popularized it.

Apple vs the Law 1 year ago

Mobile web apps that can be installed on device were invented by Apple.

This was the way developers were supposed to develop apps for the iPhone when it was released, before Apple introduced the App Store.

"EU is already so harmonized that startups can shop for best corporate structure and law, just like they do in the US and run their business smoothly."

It's not harmonized at all, it's fully fragmented.

You can't hire someone working from another EU country. You can't raise capital across the EU. You have many different rules, regulations, taxes, etc depending on the state.

Just one nitpick: the DOM is not updated by CSS here, only the value of the CSS variable is. (It will indeed cause style recalc and paint though, and result in poor performance as we can see with the demos.)

iOS404 2 years ago

So they can make it to work for platform-specific apps that they tax 30%, but can't make it to work for interoperable web apps which they can't tax. How convenient.

iOS404 2 years ago

And what are they suggesting to improve the proposal? Apple, which makes $20B a year with Safari, surely has enough resources to make a counter-proposal?

iOS404 2 years ago

The APIs coming with a security or privacy risk are always gated by a permission prompt on the web (contrary to platform-specific apps). Safari has gone even further by only allowing some of them (e.g. Push notifications) for installed web apps.

These APIs are also much more restricted than their proprietary-ecosystem equivalent.

Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.

iOS404 2 years ago

Why would they belong in a platform-specific app but not in a standard-based web app? Because Apple can't get 30% out of it?

Although Apple now has to allow alternative browsers to ship their engines in the EU, they actually set out ridiculous conditions for browser vendors to be able to do so. Therefore, as of now, none have done it.

This is malicious compliance from Apple to try and make the law ineffective.

"Browser-specific failures are the number of WPT tests which fail in exactly one browser." From wpt.fyi

In other terms, WPT test failures for Safari means Safari has bugs or unsupported features that both Firefox and Chrome do not have.

As for Interop, it focuses on a specific, very limited areas, like "scrolling" or "subgrid" and is in no way representative of the overall feature set of a browser.

So no, contrary to what you're implying, it's not that Chrome is too advanced, or doing too much, it's really Safari that is buggy and lagging behind both Chrome and Firefox (by a lot).

Interop is only a tiny subset of the entire suite of WPT tests, and it only contains tests that all vendors agreed upon, so no browser will look bad in Interop.

If you look at the full WPT test suite [1], you'll see that Safari is by far the one failing the biggest number of tests, i.e. the most buggy browser.

The Safari team likes to use Interop to trick people into thinking Safari is as good as the others. It's just a PR play.

[1] https://wpt.fyi/results/?label=experimental&label=master&ali...

You seem particularly willing to ignore the facts in order to paint Apple's actions in a good light.

Apple releases developer notes containing changes included in its betas. Such a change should obviously have appeared right away when iOS 17.4 beta 1 was released. It did not.

After two weeks of backlash, Apple did confirm it was removing the feature in a public statement. They just did not want to announce it publicly before.

After two other weeks of bigger backlash and the start of an EU investigation, they publicly announced they would not remove the feature after all.

They 100% intended to remove the feature, and 100% backed down.

So? They removed them without any announcement for two weeks (hoping no one would notice), then officially announced it on their website when the backlash was growing.

They then backed down after Open Web Advocacy ran surveys, an open letter and the EU started a investigation.

Or maybe Apple is not infallible, they took a shot because they are very arrogant and thought they could get away with it, and it failed miserably because now there is a law which makes their abusive behaviors illegal?

This is Apple's propaganda to try and save face. What happened is the EU stepped in and explained to them what the consequences of breaking the DMA would be.

Apple backed down, like they did a week ago with PWAs.