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.
Weakly might even be overstating it. Their roadmap has all this ambitious stuff like sideloading and competing app stores and allowing apps to link to their own payments, that they are aiming to have categorized into priority-buckets by the middle of next year. This could take the rest of the decade to actually be implemented on Apple's side.
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.
> Yeah other reasons I've heard of include the obligation to adopt iOS-specific APIs for features like scrolling and text inputs
TBH I'm fine with that. Applications, browsers or not, should use the operating system's components and APIs for things for a unified experience across all apps and interactions. On the desktop side of things, I hate when an application breaks convention for the OS it's deployed on. If I'm using macOS, for example, I want every app on my mac to look and behave like any other, consistent with the rest of the OS.
I’d say it’s even more important on mobile than it is on desktop. Third parties re-implementing things like the keyboard and IMEs are unlikely to do those anywhere near as well as the OS does, not to mention how custom implementations would break password manager integration, user-selected third party keyboards, etc.
Don't expect Apple to just open the gates and say anything goes as far as the browser is concerned. Instead, look for an Apple build of Firefox and maybe an Apple build of Chrome that you will be able to install.
Culturally, the Japanese aren't likely to care. Take a look at Linux usage in Japan to get what I mean. You will have a small but very dedicated group of users who won't change for anything, and then the masses who just use what is convenient. They don't like tweaking.
I wonder if it would make more sense and be easier for Firefox to switch to Blink, working together with Google making an alternate browser engine for iOS.
The issue that you bringing up was more of an issue of Microsoft thinking they were finished with the web and the lack of automatic updates. It was not due to lack of diversity of engines, but of market share of a single product. This is very different from having the dominant browser engine invested in the success of the web with automatic updates to ensure that the web platform is able to advance and not stagnate.
As a counterpoint, this does make it so that one group has disproportionate power over what features make it into that engine, or how they are implemented. What if their incentives change over time and are no longer aligned with what we might consider the success of the web?
The problem with forking Blink/Chromium is that in order to be able to counter Google, the organization maintaining the fork is going to need dev manpower on the order of Google’s to be able to keep up with upstream patches, which is prohibitively expensive for all but a handful of orgs (not to mention, skilled talent capable of working on web engines doesn’t grow on trees). Without that any fork that differs substantially from mainline is eventually doomed as the divergence grows and overwhelms the team.
It does not take the same order of engineers for only integration. That is false as you can see by the existing integration teams for forks that exist. And I'm sure Mozilla is able to find talent capable of working on web engines.
There are no Blink forks with appreciably large differences yet, though. In the aftermath of Google turning “evil” and working against the better interests of the web in multiple ways, you’re looking at a fork with divergences as large or larger than those that prompted Google to fork Blink from WebKit, making integration of patches from mainline Blink a full time non-trivial job.
Personally I’d rather see Mozilla working on Gecko or maybe consider switching to Servo or something instead.
Monopolies are bad regardless. It’s similar to dictators — even if you have a “good” one that works in the interest of the people, that can all come crashing down and turn to despotism in an instant.
In the case of the web, it’s also bad for any single company to have as much influence as Google has on web standards development. There’s simply too much conflict of interest at play. As a web engine developer they should have some amount of sway but if any party is to have disproportionate power it’d be better if it were an org like Mozilla that’s more likely to give issues like privacy and potential for abuse greater consideration.
Is it even worth investing in? It would require massive capital spend and the ongoing costs to stay afloat would be similarly high. There is little to no certainty to believe you could acquire users or a revenue model either. None of the chromium derivatives have managed to gain traction other than edge. It seems wiser to invest in the next platform rather than ones with big players already in the space.
Today I was asked to give permission to transmit my personal data to Google Maps to view my train route. I wondered why they didn't use Open Street Maps. Systems exist, but the people with the money don't care to use them.
My new phone is full of many more libre apps than my old phone.
I was suggesting Mozilla could help with the development. Firefox gains an engine that has a lot of other engineering hours being invested into it that can fulfill their needs.
Gecko doesn't support ios, so it wouldn't fulfill their needs here. Since Blink is known for being easier to embed then Gecko I think it would be easier for Firefox to move from Webkit to Blink than to Gecko.
Google's dominance is due to Chrome's market share. Using their browser engine doesn't affect their dominance.
AFAIK the main reason is that only the EU+UK cared about these rules and their market share is too small for companies like Google or Mozilla to invest into.
Because of the way the App Store works, browser engines segregated by region need to be two different apps. That means maintaining two source trees (EU+UK+JP vs worldwide) and two releases with two reviews.
I expect niche browsers to have a go at porting to iOS at some point (I'd love to see a project like Ladybird be the first non-Safari browser on the app store!) but for the major companies it seems like too much of a hassle at the moment.
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.
To be fair to Apple, as a user of Safari, I mostly agree with their feature omissions. Web developers have shown near limitless capacity for abusing new platform features and Apple has provided sound explanations for why they won't implement eg. web bluetooth. On the other hand as a web developer I have definitely suffered my fair share of Safari's incompatibilities (however I find myself in these situations less and less these days).
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.
On my Mac, Google Chrome takes 1.8 GB. I would be pretty sore if I had to download that on cellular while trying to hail a cab in a foreign country because the app requires something like the Battery Status API in order to extract a surcharge because my battery is at 2%.
People were accusing Uber of this 10 years ago. It's not a secret concept. And while it seems Uber has never actually done this, it wouldn't surprise me if there are companies out there who do.
I don’t think that’s true. Apple said web sites were the way to add functionality to the first iPhone, but “can be installed on device”?
Jobs framed it that way, but IIRC, all you could do is create bookmarks. Creating an icon on the Home Screen? Impossible. Reliably storing data on-device? Impossible. Backing up your on-device data? Impossible. Accessing your on-device contacts, photos? Impossible.
Also, Jobs made a vision statement about web apps in June 2007, but Apple announced a SDK only four months later (in October 2007) and shipped it in March 2008.
⇒ I’m fairly sure he knew about that SDK when he made that statement.
The ability to install web apps that open as standalone apps, and not in Safari, was introduced by Apple with iOS 2.1 in 2008. Well before this ability was added to Android.
IMHO. Apple were the first to make it useful. Because the iPhone was always online and the browser window was limited. Active Desktop aimed for the technological stars and was just buggy and slow as a result, it was cool but too flaky to be used.
Symbian I just never had an Phone expensive enough to use like that.
In the end none of them really worked out I guess.
> "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.)
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?
The counter-proposal is: don't do it. This comment by the Apple guy sums it up well IMHO:
> Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
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.
It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like iOS.
If Apple made arbitrary file access work for apps [1], surely they could make it work for Safari. But apps pay 30% and websites don't, so it's easy to conclude why they don't want to.
The web lacks intentionality that installed 'native' apps have. You search for a recipie and land on a random blog, executing untrustable code from a countless number of third parties, clicking "I agree" on that modal that says "LiveLaughLove blog and out 1382 partners value your privacy".
Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.
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.
Because some of us lived through pop up hell and Microsoft’s lack of security as it relates to web browsers in the late 90s/2000s. Web apps should be as restricted as possible.
Rich companies such as Epic, complaining about a 30% cut can cry me a river. Lock iOS down as much as possible and restrict/sandbox the web.
iOS is the only internet connected computer I’ve had that didn’t get malware and/or a virus at some point. Unless you consider an Xbox/PlayStation a computer.
And would you build for all browsers or just your favourite "standard"? It doesn't matter how many layers we add, it will always amount to the same challenge when people use different systems. That's why it's generally better to target a solution with the least amount of abstractions to depend on. Build a native app, you depend on the OS. Build a PWA, you depend on the browser and the OS.
As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.
Because there's typically at least a minimum of safety checks before an app can go into the app store, whereas a website can do whatever it wants (and can).
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.