Recent submissions

Comment · 7 months ago
Comment · 7 months ago
But if the web engine you have to use is a) shitty and b) the same as everyone else (except slightly shittier [1]), how are you going to make it popular?

The browser engine is an important piece of the puzzle when it comes to getting people to switch browsers. If a site works faster or better on browser B, that's a reason to switch.

If Apple's WebKit engine doesn't allow you to do video calls, you could build that into your engine and actually compete.

Why would Google and Mozilla spend millions on developing and maintaining their own engines if they didn't think that it provides value, e.g. a competitive edge?

[1] In the past, Safari did get some features that other browsers on iOS didn't get, e.g. Being the default browser (you couldn't set Chrome or any other browser as the default until iOS 14(!), Nitro JIT (Safari was significantly faster than other browsers on iOS for 4 yrs), camera and microphone access (video calls only worked in Safari), Web Extensions, Apple Pay, Fullscreen API, Add to Home Screen (ironically)...

Comment · 7 months ago
Right. So I don't know the costs of the hoops we need to jump through for our app to be granted a place on the app store. I'm not the guy who does the spreadsheets :). I do know that we've spent considerable time to make changes to pass app store review.

For example, our platform requires a subscription, but we can't link to the page where you subscribe anywhere. That means that if our FAQ page links to the subscribe page, and we have a link to the FAQ anywhere, we have to block that from happening. This isn't just extra work (to prevent users from ending up on that subscription page), it actually prevents us from offering users a way to subscribe or even change their subscription from within the app. This directly hurts our business model (subscriptions) and UX (users have to change their subscription by manually visiting our site in a browser).

All of this work means we either have to charge the user extra money (increased costs for consumers) or do less with the money we have (decreased value for the consumers).

I know this doesn't fully answer your question, but I hope it sheds a bit of light on what these extra costs are and how consumers end up paying for it.

Comment · 7 months ago
Comment · 7 months ago
The WPT graph shows failures for tests that fail in only one browser. So the accelerometer tests, for example, would need to pass in both Blink and Gecko for it to count as a failure on Safari's part.
Comment · 7 months ago
Comment · 7 months ago
Comment · 7 months ago
> business hires three teams?

Yes. The web's winning feature is "it works everywhere". If your app doesn't work for the wealthiest 50% of users, why go that route? Making a desktop web app work on mobile, just for Android, is a lot of work. It needs to work on both iOS and Android to make it worthwhile.

> they all depend on full desktop browser to work (often due to sheer fact that they are complex apps that don't work well on mobile screens)

Gmail, Office, Docs - they all exist on mobile (as native apps). So it's not the complexity itself that makes it a problem on mobile screens. What does the native Gmail app do that the desktop web app doesn't?

> Android's market share is 68-70% worldwide.

Not in the wealthiest parts of the world, where the money is.

Comment · 7 months ago
> if you break the app store monopoly, you can install chrome or firefox and do all the web-app-platform nonsense you want

Apple would also need to be forced to provide the APIs that browsers need so they can properly integrate with the OS (a lot of those APIs are private, currently), but good point, that would absolutely be one way to break this open.

Comment · 7 months ago
> In other words, Apple has successfully prevented you from writing a web application

... by abusing their monopoly position on iOS (instead of competing).

Good outcome?

Comment · 7 months ago
> Google often doesn't bother even with a spec.

I'm sorry, but that doesn't seem to be right. They have a process: https://www.chromium.org/blink/launching-features/

> I wouldn't really quote Alex Russel on anything related to standards

I disagree :)

...but it's getting late here, have to shut down :)

Comment · 7 months ago
I thought this was obvious, but higher costs for building and maintaining an app (vs a web app) means higher prices for users. I think people would love to pay less, and would hate to pay more.
Comment · 7 months ago
First of all: don't they? (honest question, I truly don't know if Africa has more PWAs compared to US/EU/etc)

Second: There are many reasons why businesses would opt for a native app. Notifications, for one (not available on the web on iOS until just a couple of years ago). Also, native apps allow for more tracking (whereas browsers are paranoid by default).

Third: A few years back, companies like FB, Google and Twitter all launched "Lite" versions of their apps, specifically targeted at Africa and other developing markets. They were all web apps (or wrappers around web apps). I will admit that this was years ago, and I have not checked if these Lite versions are still around and/or widely used.

Comment · 7 months ago
> I care whether Apple would compete with Google, and they wouldn't.

They receive $20B a year from Google (search engine deal). Some estimates put WebKit/Safari's budget at $500M. That's a rounding error away from $20B of pure profits. I completely agree that Apple is not in it for the good of the web. They are in it for $20B a year.

And even if they wouldn't want to compete: fine. Let them give up. Make room for browsers that do want to compete (or at least, let them try).

> WebKit isn't a browser monopoly, it has less than 20% of the browser market share.

That monopoly on iOS is enough, though. The web has to work on iOS because the wealthiest users have an iPhone, and all they have is WebKit. I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do. In other words, Apple is in full control of what we are able to do. Building features for Android users is often not worth our time and money, so we just don't build it.

Comment · 7 months ago
Funny you would say that. Because businesses and users have only one choice on iOS: native apps, because the web app isn't viable (and/or available) on iOS.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton