Hacker News new | ask | show | jobs
by pilif 84 days ago
Firefox is not in a position where it is the only browser allowed to run on a platform.

On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit

4 comments

It came out in the Epic trial that 90% of App Store revenue comes from loot boxes and other pay to win game mechanics - cry my a river for those companies.

The other companies that are making money from mobile are usually front end for services that don’t monetize directly through in app purchases or give you the option of not paying through the App Store.

The first million in revenue is 15% not 30%

But also if it is just Apple, why do the same companies create apps for Android?

Let’s say in this world where there was an alternative browser engine that supported everything that you wanted, how much uptake do you think you would have for your app if someone had to download an alternate browser first?

Did I also mention that in the US at least you can link out to your own payment system?

Also let’s not forget that Google’s app store fees are also 30%
Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.

Going through some of the list from the top:

* Shortcuts in the manifest: This seems to be standard. Would be nice if mobile Safari supported it.

* Protocol Handling: This is non-standard.

* File Handling: MDN doesn't contain a reference to a standard, and it has this caveat: "At present this feature is only available on Chromium-based browsers, and only on desktop operating systems". So not only does it seem to be non-standard; Chrome on Android doesn't even support it!

* Contact Picker: This seems to be moving through the standardization process and is not yet standardized, if I understand MDN's "experimental" label correctly.

* Face Detection: This seems to be yet another not-yet-standard API.

* Vibration: This is standard, it's a shame Safari doesn't implement it.

I'll stop here but you get the point. 2/6 are actual standards; 4/6 are just features Chromium implemented even though they aren't standard.

I'm glad mobile Safari doesn't follow every Google whim. Google has enough power over the standardization process as it is; we don't want them to control which features browsers add outside of the standard too.

In addition, parts of the list seems to be extremely outdated: Safari on iOS does support the Web Push API and most of the Notifications API (at least for apps added to your home screen as PWAs). These APIs have been supported since iOS 16.4, according to MDN.

> Vibration: This is standard, it's a shame Safari doesn't implement it.

I would rather prefer web pages do not gain the ability to make my phone vibrate.

>Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.

You missed the point completely.

Apple >forbids< any browser engine on iOS other than their own Safari. So you can't just install Chrome on iOS, because when you do you get Safari instead.

I would not care how Apple cripples their own web browser if they didn't force other browsers on iOS to use their browser engine. They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).

I am not an iOS app developer, I'm a web developer. I don't have the resources to support that kind of code when I already have a perfectly working web app on the competing platform. I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.

It doesn't matter what the standards are or aren't. Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.

And to make it worse, Apple is on the board that decides what standards get into W3C, so they are blocking useful APIs based on their own greed.

This is part of the reason Apple is currently being sued by the DOJ

https://www.justice.gov/archives/opa/media/1344546/dl?inline

Mobile safari is arguably the only thing standing between Google and total browser dominance. It's the reason why Google "only" has roughly 75% of the mobile browser market even though it has a 90% market share in desktop. I'm principally against the idea that Apple can prevent users from installing the software they want on their own devices, but we can't deny that it's better for the health of the web.

Anyway, if you want to exclusively argue "Users should be able to install the browser they want", that's fine. But you're not; both your comment and the pwa.gripe page brings up how Apple is "crippling" their own web browser. Since you use the same wording as pwa.gripe, I assume you too view the lack of non-standard Google-only features as "crippling mobile Safari". I disagree.

> Mobile safari is arguably the only thing standing between Google and total browser dominance

"Apple Is Not Defending Browser Engine Choice"

https://infrequently.org/2022/06/apple-is-not-defending-brow...

You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not purely because Firefox is technically inferior, mind you; products don't compete purely on technical merit.)

I think Chromium out-competing every other browser engine is a bad thing.

Let Google dominate the web. If that’s a problem we can sort that out. But two wrongs don’t make a right.
> I think Chromium out-competing every other browser engine is a bad thing.

Hmm. I believe that Apple can compete with Google if they want to. They have the money, they have the marketing chops, they have the incentive ($20B search engine deal) and they are the default browser.

(also, they have trained iOS users that Safari is the only default browser on iOS for 14 yrs by not allowing other browsers to be set as the default)

All Apple has to do is actually compete, not just rely on their monopoly.

I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?

You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those filters your self and apply them by using imgData.

Also the constant crashing when using canvas and the web audio api, it’s a disaster to be honest and it feels intentional, like they want me to write an app instead so they can rent seek.

As a non-web developer I'm interested if anyone can answer this question:

  If you're designing for <X> browser, how hard is it to make it work on <Y> browser?
Answering with at least {Chromium,Safari,Firefox}

Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.

What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.

What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/<other nefarious actions> can't happen.

Tdlr: does developing on chromium encourage browser incompatibility?

> Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.

Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it.

The web worked fine for decades without smart fridge integration or whatever weird thing Google has decided that browsers must be capable of most recently.

Making things work in chrome and Firefox is trivial and is never hard but when it comes to safari you have to figure out the special dance to make things work properly even when targeting it first.

No developing for chrome does not encourage browser incompatibility.

The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.
I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;)

https://webventures.rejh.nl/blog/2024/history-of-safari-show...

Seeing that there are cross platform game engines, it seems to me that making a web game is not the best way to go. How do you plan to monetize it? Get people to put their credit card on your website? How is your web game performing on Android? Have you tested the performance on the typical mid range Android phone?
Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own.

I have various avenues of monitization; sponsored ads and letting players buy cosmetic items.

I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.

As an iOS user, I’m quite happy you have to jump through these hoops instead of being able to force me to use a Google product.
You can still build a PWA and get most of the benefits (I use a few PWAs on my iPhone daily). Or you can package it through Expo and rely on the Reader app exception without letting users sign up on iOS (although the rules around that are changing and you might be able to).

I get the gist of the article but what specific features do you need to let people just use your app as a PWA on iOS? Do you need access to the NFC, for instance?

I need web bluetooth to give users the full experience. They can use most of my platform currently on Safari, but not the really cool stuff that web bluetooth enables.
> They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).

Why don’t you encourage them to get an Android? What makes you think that people who prefer an iOS device over Android would even install Chrome after you nag them with dark patterns?

> I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.

Sorry, not following you: Apple is forcing you to give them 30% of nothing? How exactly is that a problem?

> Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.

Yes, how dare Apple look after their [checks notes] customers by preventing devs from using the features that would most annoy their customers?!? Such a greedy thing for a company to do, to give customers what they want! The only true purpose of a company ought to make it easy to slurp up customer data and monetize eyeballs!

> What makes you think that people who prefer an iOS device over Android would even install Firefox

100% guaranteed people would. I know this for a fact. You somehow have proof of the negative for some reason. Maybe you can share that.

Regardless, just because you are satisfied with iOS as a platform doesn't mean others don't continue to wish for improvements.

Can I ask which version of iOS was perfect in our mind?

What fact? Have you checked Firefox's market share even on desktop?
That people would use Firefox on iOS. That fact. Do you know English? It seems like you understood what I said, but still had a hard time comprehending it. Are you okay?
> Can I ask which version of iOS was perfect in our mind?

6.

Guess what? You not having the resources to have anything but a shitty PWA is not my problem.

Do you really think that you are going to get any level of monetization by forcing users to first download a hypothetical web browser that has all of the features you want? That web browser doesn’t exist on any mobile platform

You have no idea what my web application is, or whether it is shitty or not. So thanks for the troll - it reminds of my days on reddit, but now this pointless internet interaction is over.
A web app has never in history been as performant as a native app.
Not everything needs to be at the highest high of "performant", and you're ridiculous to use that as a gotcha.

I told you, this pointless internet interaction is over. You are not here to argue in good faith, so take it somewhere else.

> No browser in iOS can use anything but WebKit

Your statement is true only outside of EU countries.

Is any popular browser actually available with non-WebKit browser in EU? So far I wasn't able to confirm this.
No it's not. The percentage of people who actually can use alt stores is so small that nobody will really dedicate money to make browser build for iOS. Why would they when Apple would just make the work impossible anyway.

It's pure malicious compliance from Apple. Anybody defending Apple on this is simply delusional.

Alt stores and web engine stuff are two separate things: https://developer.apple.com/support/alternative-browser-engi...

Browsers with alternative engines can be offered in regular AppStore. That's why I wonder why isn't this a thing. At the end of the day, browser makers probably want to reduce confusion and complexity of maintaining two vastly different applications under the same name. This most likely isn't a case of malicious compliance, you got yourself carried away here I think.

I think malicious compliance is a fair interpretation of the situation: https://open-web-advocacy.org/blog/apples-browser-engine-ban...
I think the main technological limitation is that other browsers cannot just-in-time compile (JIT) JavaScript or any other embedded language. Except in the EU.

ETA: your link includes JIT; I’m pointing out that that’s why they don’t exist outside of the EU. Non-JIT browsers would just not be very performant.

If that is true, this is malicious complaint. Unless Safari has the same restrictions, of course.
This whole thing is of Apples doing. Of course they don't want to comply.
And regulators are obviously unwilling/unable to hit them with fines that really make a difference beyond "cost of doing business" small change.
Specifically due to regulations that Apple incited.
A significant amount of apps can get the 10% rule rather than 30%.

It doesn’t necessarily change the point in the end but it is worth noting.