> If only so that there is another alternative if a page renders poorly in webkit
I have a less optimistic take. At the moment, the only thing standing between the world and a Chrome-only monoculture is iOS Safari. Nobody in a suit can make a business case for not supporting iOS Safari, given its market share, and also given the fact that the entire C-Suite and senior management team at any given company are using Safari on their iPhone and iPad. A page not working on iOS Safari is a serious business problem that people will take seriously, today.
If it gets displaced by Chrome on iOS, with a tiny sliver of us using Firefox, I worry "works on Chrome" will be the only thing that gets solved for.
Well, Firefox users may never make up quite as much marketshare as it used to, but it does have one advantage: we're a lot louder and more annoying than Chrome users when stuff is broken. It's a feature! (Okay, I try not to be annoying. But I'm pretty sure absolutely nobody is thrilled when I report bugs about Librewolf not working. Shoutouts to SoundCloud for eventually fixing one of said issues.)
I doubt Safari will actually die on iOS. The truth is, Safari on iOS is kinda good. That said, honestly this whole line of thinking has gotten pretty tiring. I'm not really sure that an Apple/Google duopoly on browsers is really that much better than the seemingly inevitable Google monopoly. It's not like either of them are particularly good citizens, but Apple's relatively small influence has been very negative in a lot of ways. I'm not even a huge fan of using regulations to solve every problem, but even I must admit that EU regulations have done far more to start to reel in Google than Apple ever could, anyways. As for poor WebM support and pushing wgsl into the WebGPU spec, good riddance.
It's really sad that Google can't be trusted more. There's a lot of people there who are doing good work on Chromium and other web-related projects, and it's besmirched by greedy decisions at worst and optically blind decisions at best. When I was at Google, I did spend a bit of my time trying to make some intranet stuff work better in Firefox... It's probably a token gesture at best, but oh well.
You know we're at a weird point when the underdog competition in browsers is Apple, one of the richest and most resourceful companies of all time.
> Well, Firefox users may never make up quite as much marketshare as it used to, but it does have one advantage: we're a lot louder and more annoying than Chrome users when stuff is broken.
Slack refuses to work properly on Firefox. I don't think they care that we are being loud about it.
> Slack refuses to work properly on Firefox. I don't think they care that we are being loud about it.
Microsoft Teams doesn't make calls on Firefox, and their poor excuse of a desktop client for Linux forces me to use the web app on Chromium on my work computer.
Big shout out to Webex Teams, who's web app works flawlessly on both Chromium and Firefox but actually provides a better experience on Firefox because it's easier to make video calls Fullscreen
Yep. This is why I request (though I don’t enforce) my front end team to use Firefox at least part of the time when developing; if it works there, it works basically everywhere else without any hassle.
Microsoft teams barely even work standalone. It frustrates me whenever all the buttons stop working when I need to unmute myself during an online meeting. I then have to use my phone and hope it won't happen there too.
To be fair, I'm not even sure if Slack cares about web users at all. It just doesn't work that well, at least for me. (Though I obviously haven't tried it in a bit, so maybe it's good in Chrome now.)
It's true, but the Electron app always seemed more full featured, and at least for me, I had lots of issues with bugginess and slowness in the web browser, even in Chrome. I'm not sure why it would be slower in Chrome than Electron. Neither are particularly lightweight. Maybe it's my fault somehow.
One datapoint: I use Slack exclusively in the browser (both Firefox and Brave), and it works well. As far as I remember on Firefox there was some limitation on video calls but that was arbitrary (user-agent check or something like that).
I hadn't tried the user agent trick, I was just frustrated enough at being on my personal laptop and having to join a call then finding Slack was being terrible.
And for no apparent good reason other than bad quality software.
I only brought it up because it is high profile web application that has an arbitrary Firefox limitation, and as a Firefox user I will name and shame bad applications.
What doesn't work properly and are there issues for this where I can add my support?
I'm using slack on Firefox daily. Prefer it over loading that slow and resource hungry desktop app, if only for speed alone. But haven't encountered stuff that works on the desktop app, but not in the browser.
> You know we're at a weird point when the underdog competition in browsers is Apple, one of the richest and most resourceful companies of all time.
It's not so weird considering the following:
1. Safari only works on Apple operating systems
2. Safari development has been seriously underfunded by Apple, since Apple wants to keep people in their walled garden app store, and web apps, by their very nature, can't be controlled by them.
> the only thing standing between the world and a Chrome-only monoculture is iOS Safari
It's not really a good argument. It should be about user choice. If Chrome is better than Safari, and I prefer it, I should be able to install it. OS locked down browsers is 1990s era MS anti-trust behaviour that significantly reduces overall competition.
Mobile is king - if Safari/webkit wasn't so locked down on iOS, we may have gotten even a completely different player who made a really good mobile browser. Apple's behaviour is nothing short of monopolistic and there is no good defence of it imo.
> I worry "works on Chrome" will be the only thing that gets solved for.
In other words: with the choice of using other browser engines on iOS there is a real possibility an even larger percentage of websites will work only on Chrome, meaning in the end user choice will be reduced because either you use Chromium (on mobile and desktop) or you cannot use anything.
Both situations suck. If Chrome weren’t so dominant then it would be a no brainer to advocate for more openness in iOS browser rendering engines, but as it stands it may be the case that not allowing the diversity on iOS promotes it in the aggregate. Apple’s approach, despite being done for the wrong reasons, might be what’s less detrimental for the web.
> Apple's behaviour is nothing short of monopolistic and there is no good defence of it imo.
What do you actually propose then? Force them to release Safari for Android?
Chrome/blink has about 65% mobile market share, Safari has about 30%. If you are concerned with monopoly, how would enabling Blink on iOS do a single thing to displace the actual 600 pound gorilla in the room? Or is monopoly bad only if it's not *your* preferred choice?
> Apple's behaviour is nothing short of monopolistic and there is no good defence of it imo.
What if we have a straightforward choice between an Apple monopoly and a Chrome monopoly?
I've seen major online shopping websites deploy code that meant firefox users couldn't add items to their shopping baskets, and then classify it as a low priority bug because there was a workaround - using chrome.
Tell the devs (any here on this thread? Please speak!) of _iPhone_ iOS Safari (which is somehow different than iPad) to support `MediaSource` and I'll sympathize. They are often behind the curve, and with the size of market share they have, I'd at least like a timeline of when very popular features will be exposed. Until then, they're the new IE to me. It's popular because it's the default and that's it.
Agreed. While being forced into a walled garden isn't a good thing, it has the current side effect giving iOS Safari a significant market share to keep Chrome from dominating to become the new IE and have all those "works in Internet Explorer 6 with 1024x768 screen" websites again but this time for Chrome.
Maybe from the perspective of webdevs, from what it represents for users, that's Chrome. A Chrome monopoly may seem desirable, because they're catering to webdevs, but there's nothing they'd like more than having webdevs help them lasso all the users they can surveil and expose to ads as possible.
I get your point. However, unless mobile usage (vs desktop) gets to something like 90% and unless another 90% of that mobile is iPhone/iPad (vs anything non-Apple), Safari dominating like IE did is impossible.
However, for Chrome, it is possible without the walled garden (not to defend it or anything, but it is what it is).
That simplistic a comparison is simply not worth responding to in any direct way. Safari is Safari and IE is IE. there are some clear differences between the two, in both mobile market share and total market share. That’s just the beginning.
> I worry "works on Chrome" will be the only thing that gets solved for
Firefox is my daily driver, and I use their WebKit wrapper on iOS, and I have to agree. I'm not looking forward to a Blink monopoly in the browser space. The upshot is that we might have closer-to-native experiences for websites on iOS.
> closer-to-native experiences for websites on iOS.
What is native? If a website is explicitly testing for Firefox compatibility, they're probably also testing for Safari compatibility due to its increased market share.
It's not so much Safari compatibility, but WebKit compatibility. Anyone who wants their website to work on iOS has to test against mobile WebKit, regardless if their target users are on Chrome or Firefox. If these legislative changes go into effect, Webkit market penetration will plummet quickly to only those using Safari, and Apple will have less leverage to hold back on features that don't suit their App Store profits.
I know a fair few solo developers that don't test Safari compatibility because they don't own Apple hardware. And Safari only runs on Apple hardware (with the exception of Hackintosh).
> The upshot is that we might have closer-to-native experiences for websites on iOS
Strange. Android is 70% market share. Chrome is something like 80% market share (all playforms). Where are these glorious "closer to native web apps" we keep hearing about?
I specified on iOS. It would at least be possible on iOS if other renderers could be used, and both Firefox and Google would certainly have their own incentive to make this happen. Google don't want to undermine the Play Store, but they might want to undermine the App Store. Firefox have existential reasons for product differentiation, though web apps won't get traction without broader support by all players.
The parent was clearly alluding to “closer-to-native experiences” on Android. If Chrome will bring that to iOS, there should already be examples on Android.
Google don't want to undermine the Play Store, but they might want to undermine the App Store.
I’ll buy that, but it doesn’t seem like a reason to be optimistic about the way things might go.
> If Chrome will bring that to iOS, there should already be examples on Android.
I think I illustrated that the incentives are different
> doesn’t seem like a reason to be optimistic
I did say "we might have closer-to-native experiences for websites on iOS" (emphasis added) in my OP. Only because it would become possible, not because it would be likely
Better integration with OS features on iOS devices is still an upshot for people who want websites to do more useful things with their phones, if that becomes a possibility. Might not balance out the cost of having a browser hegemony, and it might not be something that’s specifically useful or interesting to you, but a small mercy nonetheless
> Better integration with OS features on iOS devices is still an upshot for people who want websites to do more useful things with their phones, if that becomes a possibility.
Again. "If", and "might help", and something else.
Question is: you have Android with 70% market share and all those capabilities you so crave for. Have all these nice hypotheticals happened there, or not?
I think we need all the things you mention in that comment, and much, if not all, are dependent on the rendering engine internals to implement. e.g., Firefox iOS couldn’t fix it without changes to WebKit
It just might not be worth doing until browser vendors have a consistent renderer across all platforms (true for Firefox and Chrome) and until Apple loses its leverage. It might also be that it requires coordination and cooperation across all browser vendors to a degree that is unlikely. I’m not privy to the internal politics, so I don’t know which is the case
You seem very animated about some aside I made in my OP comment, that was obviously made as a speculation. Not sure why. We're both speculating FWIW, so there's no real argument to 'win' here, not even a wager I'd consider making.
Indeed it was speculation. So I asked you basically what your speculation was based on. Because we have a platform where no such speculation is necessary: Android is the dominant mobile platform, it already has all the capabilities you speculate about and so on.
So, given that Android exists, and we see literally nothing come out of it as far as web apps are concerned, what are basing your speculations on?
So many words to avoid the hard truth: web apps suck, and "we might have closer-to-native experiences" is bullshit. Because, see my comment on Android which already supposedly has these "close to native experiences".
Why would Safari get displaced on iOS, though? Apple users tend to stick to first-party software even when options are available, unless third-party stuff has a significant feature gap (and keep in mind that we're talking about UX here, not how many APIs the browser supports etc). Did Chrome overtake Safari on macOS?
Google can prompt you to download Chrome in every service and every app of theirs you use, and every so often "innocently" break some aspect of their services if it's being touched by another browser.
I remember back when their enthusiasts here, on HN, urged Firefox users to keep an open mind that Google products breaking on Gecko regularly was just because they were so busy making the web awesome! It was strange back then, but also the product of another era of the Orange Site, you saw more of that tendency to identify with businesses such as Google than with other individual people.
And how well do you think something like that would go with the iOS target demographic?
Safari is different from Firefox for one simple reason: it's bundled to Apple products, which, regardless of their actual quality, are perceived as "luxury software" socially, and its userbase reflects that. And it's large enough that, for most companies actually trying to sell something, it makes sense to cater to.
Is the user, just some ordinary joe who isnt especially technical, going to switch banks to continue using FF or is he going to switch to Chrome and carry on his day? When google search, youtube, maps, and a bunch of third party sites all start recommending Chrome as well, what happens then?
Most websites have financial incentives to only support one browser, if they can get rid of WebKit they will, standards be damned.
Firefox is off the beaten path. iOS Safari isn’t. Someone has to be ballsy enough to do make that first call. These kids calling it “the new IE” are being dramatic. iOS Safari as it is right now is nowhere near what IE was. Any meaningful organisation that makes the first call on not supporting iOS Safari is…to put it one way…not somewhere that I want to work. Because it sounds like the prioritises are being set by a nerd with a chip on his (yes, his) shoulder instead of what’s best for the user or for the business.
Google will pay handsomely to a good bunch of "nerds" to gain dominance on iOS with Chrome as it did in other platforms, and then it will make business sense for independent vendors to drop support for anything but Chrome.
I’m less sure about that for a few reasons. Biggest among them is that (presumably?) in app webviews will still be WKWebView, powered by WebKit. So if you want your page to load inside Facebook’s browser (and you do) you’re still going to have to care about Safari.
Fair point. They already do this on Android. For compatibility reasons you understand, not so that they can track absolutely everything you do, no sir.
It might make Apple work harder maybe? For instance on my m1 MacBook Air, safari is vastly better for my battery life than chrome or ff for my workload. It makes a huge difference. That would make me use it over the others if that’s the same on the iPhone or iPad where battery life is even more important.
Presumably, the people who care about web would only install firefox on their iOS devices, while the people who don't care would just keep safari.
in other words, the chrome share of the iOS market would remain small.
So a product manager cannot just say that it works on chrome and forget about safari. Unless, somehow, google manages to boost chrome's iOS marketshare up and above safaris'!
Every time I log into a Google web app it tells me to use Chrome for a better experience. It’s happened in two, maybe three browsers in the last month. I have no hope for your hope. Google will pummel users into using Chrome, relentlessly.
I know a lot of non-technical people who use Webkit-Chrome on their iPhones because they (have to?) use Blink-Chrome on their computers.
Currently they just accept that "iPhone" browsers don't behave exactly like computer browsers, but if Google started a campaign saying "now you can get exactly the same behaviour on your phone" I'm sure it would influence them.
If your website only works on one of the browsers, you are probably doing something wrong. It is not like it was in the 90s, it can pretty much be expected your website will work on all browsers, if you are following the current HTML/CSS specs and best practices.
Its… not an argument? Have you lost your mind? It was presented as an argument for why it would be bad to let users have freedom to choose their mobile browser. Of course an argument can be born out of a concern, that’s obvious. But you can’t just dismiss a rebuttal by saying an argument is not real it’s just a concern.
> I have a less optimistic take. At the moment, the only thing standing between the world and a Chrome-only monoculture is iOS Safari. Nobody in a suit can make a business case for not supporting iOS Safari, given its market share, and also given the fact that the entire C-Suite and senior management team at any given company are using Safari on their iPhone and iPad. A page not working on iOS Safari is a serious business problem that people will take seriously, today.
This doesn't sound like an argument against the change, only a pessimistic outlook for its effects.
Right, both things can be true. Apple has a closed web browser ecosystem, and that's bad for users. Opening up that ecosystem could possibly lead to even greater market dominance by Chrome, which would also be bad for users.
MS sat on their laurels and allowed everyone else catch up though. Through the living standard all google needs to do is keep Chrome updating at a frantic pace and no one will be able to come close.
If MS doesn't have the capability of maintaining their own browser, the chances of someone else entering the market is basically nil.
IE dominated because it was the default / only known choice for a while. Then Mozilla/FF was huge because of features (tabs). Then Chrome was huge because Google had bazillion $$$ to burn on advertising it everywhere. I'm not sure how we can move away from that local maximum this time.
On the iOS side, Apple had the default + locked browser choice. Now they can try to outspend each other with Google there.
When IE 6 came out, it was also one of the best/fastest browsers at the time. Heck, it even came with the first implementation of what we all call AJAX today.
The problem was that MS declared victory and stop developing IE, expecting to use their OS leverage to keep others out.
They lost the favor of web developers, because they thought that by pushing a crappy browser they could stall the advancement of web applications. They wanted to stifle the web and have people use IE the least as possible and have developers keep making native applications.
Google doesn't have that incentive, it has the incentive to make the browser as shiny as possible to keep the loyalty of web developers, so that they won't campaign in a way that will make fewer people download their ads delivery platform. They want people to use Chrome
I'm not that optimistic that Mozilla is capable of building a good iOS browser. It's been a few months since I last used it, but the issues of Firefox on iPadOS were not because of the engine. Tabs would frequently lose order, closing a tab would close some other tab, broken keyboard shortcuts, cursor/selection issues in the address bar, random non-responsiveness and just janky UI. The issues were so obvious that it felt like it was built without any QA process, so I resorted to using Safari most of the time, which worked perfectly.
Firefox Focus on Android works much better, but it's also a simpler browser. I haven't used the full Firefox on Android, so can't comment on that.
Firefox is my default browser on Android for couple of years now. It supports uBlock Origin, and I cannot browse internet without it anymore. I don't have major trouble with it, except 1-2 cases per quarter, when it is faster to open Chrome than turn the ad blocking off and then back on.
Another case for Chrome for me is full page translation. It is very neat and mostly of decent quality.
It you go the extra mile and actually disable Chrome on Android, even Google apps will start making calls to Firefox as the browser. It makes for a much better experience, otherwise Google apps don't honor the default browser choice in many circumstances.
I don't have any Google apps with this problem (I don't use mentioned below Google News). My biggest problem so far are apps without setting "Use external browser to open links".
I can't use the internet with Firefox on Android, because while is supports uBO, it doesn't support full-page translation or Bypass Paywalls Clean.
So instead, I use Firefox Nightly on Android. It supports any extension I want to install, not just those approved by Mozilla for the Android browser. I would have a very hard time without translation.
Being able to use Fennec F-Droid was my primary motivator to switch off of iPhone. It's not perfect, but there are things it offers that iOS Safari does not that I consider to be absolute necessities for browsing the web. (uBlock Origin is certainly one of them, also WebM support.)
I've been told this at least three times now on HN over the years (pretty soon I'm going to start keeping a list of URLs so people know I'm not exaggerating.) Every single time it turns out that it isn't actually true.
It was added to desktop Safari. iOS Safari supports VP9 only in WebRTC. It may have changed, but I can't find any evidence that it has.
If you see it working somewhere, it is almost definitely using the polyfill[1].
> It's been a few months since I last used it, but the issues of Firefox on iPadOS were not because of the engine.
You don't actually know that, though, it's entirely possible that these issues are caused by having purposely limited ways to hook into the engine and system as 3rd party browser.
If GP is talking about the same issues that I frequently run into, then I'd say that's almost definitely not the case. I continue to use Firefox iOS despite these issues because I like the shared history and bookmarks with my desktop, but they do annoy me on the daily.
A couple off the top of my head...
If you do something to trigger a page load, like open the app after it has been suspended, and while the page is still loading you touch the address bar to enter an address or pick one of your "recently visited" or whatever, you will be surprised when the page finishes loading and replaces the view. It replaces the view, but you're still in the "navigation bar selected" state, so you can get them back without hitting the tiny back chevron and tapping the address bar again. I doubt this has anything to do with how they are forced to hook into WebView. It's just sloppy handling of async code.
Speaking of that same view, the top four links shown there as favicons are in a constant state of flux. Generally, it's HN, Reddit, Google News and whatever else I frequently visit, but sometimes for reasons I don't understand they get completely jumbled into something else. The icons are constantly disappearing and reappearing. It's not a big deal, but it feels unstable. I'm not sure why they don't just let me pick bookmarks to save on this view instead of automatically picking them for me. There are many things I would like to have available at a single tap, but I don't visit frequently enough to make it into my top four. Like trash pickup schedule. I don't read that several times a day, but when it's time for the trash truck to come and I forgot if today is plastic or paper recyclables, I'd like to have that link bookmarked for quick access.
Without actually digging into the code and integrations, it's speculation on both of our parts. I've had to work with platforms that made implementing certain "easy" and "simple" features in a bug-free manner difficult to impossible.
Once the native engine is available to the general public, there will be more users. When there are more users, there will likely be more resources thrown at development.
The issues in question aren't something you'd ignore just due to lack of a native engine - Firefox on iOS matters for market share reasons, they need to care about that stuff regardless of what's running under the hood.
> Once the native engine is available to the general public, there will be more users.
Why do you think this will happen? The landing page for firefox.com above the fold only makes one claim about "a lightning fast browser", with their selling points being privacy, Firefox View, editing PDFs in-browser, and total cookie protection, all of which are possible in the current WebKit experience. Either Mozilla really doesn't know how to market Firefox, or less people download Firefox if their CTA is "our browser engine is better than Chrome".
Other browsers on android can do that too. Actually, firefox has a fairly restrictive extension policy, while browsers like Kiwi let you install any chrome extension that you want.
I use it as my main browser and only had to go Chrome to open some trash sites (litteral “let me load a bitcoin miner in an invisible element” kind of trash)
Unfortunately, I had the same experience with iOS and iPadOS versions of Firefox. Very janky, lots of bugs that went on unfixed for months and years, and general lack of polish and thoughtfulness in the UI. Despite using Firefox on every other platform, I had much better experience with Safari, and kept Firefox installed only for an occasional password lookup.
FWIW, I noticed all of the same issues when using FF on my iPad, but I stuck with it, and it actually got much better, and I haven't noticed a UI/UX bug in months now. It's been rock solid once they got the kinks worked out, and I've loved running FF on all of my devices and having everything synced between them appropriately.
I use firefox on iOS. I like it because it has integrations with firefox's password management, and it feels somewhat fire-foxy.
But it is a bit janky and it is strictly worse than the android version, and that's because it's layered on top of the wrong engine and there's only so much customisation they can do to make it more firefoxy.
I really welcome a full-fat fox on iOS, not least because it implies extensions like ublock origin, and adblocking on iOS is just not as good compared to UBO on android or the desktop.
That's a disappointing thread to read. "Vlad" didn't even bother looking at what NoScript actually does, and why it's better than just having a giant on/off switch for the entire page.
Google needs Mozilla though - Firefox is the last remaining Chromium competitor Google can use as a counterargument against claims about their de facto monopoly.
That's Safari. It has way more users, and website creators actually care about providing Safari support because they want it to work on the non-technical boss's iPhone.
There's no significant Firefox presence on Android either. Sure there is an app, and there are 100+ million installs, corresponding to an install market share of >4%, but people almost never use Firefox. Usage wise, Firefox has a 0.5% market share.
Safari (WebKit) is the one that is the last remaining serious competitor against Chromium.
Firefox has already lost years ago and is so useless to counter Chrome that they have to be funded by Google in order to survive. Mozilla's competitiveness for Firefox is close to zero.
The EU Digital Markets Act will just further solidify Chrome's dominance.
> Safari (WebKit) is the one that is the last remaining serious competitor against Chromium.
Safari isn't available on platforms other than Apple's (which have a minority share of computing devices on the market), so it's obviously not an actual competitor to Chromium based browsers.
Even if the DMA somehow results in Blink engine dominance, at least the engine is open, so alternative freedom and privacy-respecting browsers can build on it and patch out any evil features while mostly maintaining compatibility. Not a great outcome, but it'd be worth it to stamp out closed computer operating systems that don't let their users control what software they install. The current state of iOS and iPad OS is completely unacceptable.
Sadly, they're probably headed into a worse situation, where they lose most of that 90% of their funding since their browser marketshare is at an all time low of 3-4%. Renegotiation is this year.
I couldn't link to any websites that render incorrectly under Safari on iOS (WebKit) off the top of my head, but I think that's rather a side effect of WebKit being the only engine available on iOS: I don't want my site to be unusable on iOS devices, so I end up spending a lot of time trying to work around bugs that only happen on Apple devices.
Sure, this ultimately means that everything Just Works on Apple devices... but it's not because their browser is up to standards. It's just that I'm forced to make it work.
To me, this is very reminiscent of the Internet Explorer situation, where I end up baking a bunch of hacks into my code just to ensure it works for the majority.
are you implying that all other web browsers implement and comply with all web standards? are you implying that no website is leveraging experimental features and hence not standard yet?
I am not, and that sounds like quite an uncharitable interpretation of my comment. All web browsers have bugs, and practically all web browsers support features that are not part of the standards track. That's not the problem.
The problem is two-fold: we have a specific browser engine that lags way behind the standards, and this same engine is literally the only choice for an operating system that runs on over 1 billion[0] devices.
When I say "lags way behind the standards", I'm not talking about unsupported features, but rather, well-established features that are supposedly functional but are simply buggy. And they're not niche features: I have personally seen bugs in features like the CSS filter property, Web Audio, and SVG rendering, that are unsolved to this date.
Web devs have to deal with Safari bugs all the time, that's why you don't tend to see them. Maybe now that there's going to be other browser engines on iOS, we can show nice "please open this page in Firefox" banners and force Apple to stop undermining their browser to push native apps.
Those of us that remember "This page works best in Internet Explorer 5" are shivering at your statement. I love Firefox and use it as my primary browser on my desktop. But suggesting to users that they should use that instead of fixing issues in your site feels bad.
There's a subtle but important distinction between "a browser misbehaves and incorrectly renders my compliant site, and I refuse to make my site wrong to satisfy it" and "a browser doesn't render my malformed site the way I want it to and I refuse to fix it because other browser (incorrectly) renders my site how I want".
Have you tried comparing it with Bromite, Brave or even Chrome? There is a very noticeable difference.
Also, I think Site Isolation* doesn't work in FF Android as it does in FF Desktop. Firefox Android is categorically less secure than its Chromium counterparts.
I have not done much comparison, as it works fine for me. I could believe that it is slower, but I still wouldn't call in slow. Perhaps my using an adblocker with FF makes it better for me.
Brilliant move. Show what is possible. Let individual developers download the source & build themselves, and run it. Make it real, make the only obstruction a legal one, one that is increasingly full of holes as a small exterior/outside hobbyist community bypasses the longstanding trenchancy Apple has dug, has moated themselves in with. Give people that first whiff of freedom.
And if someday hopefully some of the anti-trust anti-competitive legal moats do get torn down, Google will be ready.
As far as I know, JIT is disabled on iOS at the moment, so one thing developers would notice right away is abysmal JavaScript performance. (Early versions of V8 didn't even have an interpreting or bytecode path, to my knowledge, so it wouldn't even run without major modifications!)
Even if Firefox and Chrome used Gecko and Blink with JSC, that's still a marked improvement from the state of things today. Most of what I dislike about Safari are its weird rendering issues, which would be solved.
Given how vast the modern web specifications are, you could really be 99% compliant but provide a pretty mediocre experience to your users, or vice versa.
For example, I use Firefox as my main browser, and the lack of e.g. proper WebAuthN support on macOS has a much, much higher impact to me (and is making me consider switching), whereas I couldn't care less about e.g. WebUSB (which I do occasionally use, but I'm fine switching to Chrome for that use case).
To get an accurate picture, you'd have to somehow weigh all of these various standards and features in a way that not only accurately presents actual users, but also their relative importance (i.e. do websites trying to use something fail gracefully, or do I effectively have to use another browser to get achieve what I'm there for).
Ideally or potentially Firefoxes or potentially say Servos or any other browser of choice. As opposed to the very-low not-so-common denominator of this anti-invested in naughty stepchild of the Apple 30% rent-stealing profit-garden that is modern Apple.
Can you show a source, then? I‘m also pretty sure JIT (i.e. write+execute) permissions are enforced at the process level.
Some apps work around this by running JavaScript in an invisible WebKit view, but that approach has IPC overhead, so is probably only worth it for processes that interact with the UI and rest of the app infrequently (which is the opposite of what you‘d want from a JS engine interacting with the DOM).
a-Shell uses it for performant WASM execution of CLI executables, for example.
I've seen some reports of it also becoming available for iOS, but it seems to come and go between minor version upgrades and I'm not sure what the current status is.
Not an iOS developer; what does available mean in this case? Are you talking actual OS support, or simply that Apple has never approved any app attempting to do it? Because Safari obviously does it so my thinking is the OS must support it, but I guess Apple has a policy not to approve it.
Apps that want to JIT need an “entitlement” from Apple (in other words they have a signature from Apple that the operating system validates before letting the APIs work). So the OS supports it, Apple grants that entitlement to Safari so it can use it, but no third party app can get this entitlement.
But surely once "sideloading" (I hate that term, we used to just call it "installing"...) is enabled, apps not installed through the App Store will be able to utilise this entitlement?
Hope so. There should be some developer capability somewhere. And we should build for the reasonable good future, & show whats possible. Not what we can mete from the iron mailed fist of Cupertino in the real world if this or that, but what actual good is.
It'd be a mean spirited system to simply mark everything no-execute, always forever in any env. But that'd be distinct Apple flavored. Think Different, R.I.P..
Yes. On iOS you can only use the JIT through an out-of-process web browser (WKWebView or SFSafariViewController) so it’s likely Firefox and Chrome would use non-JIT in-process engine (even if that were JSC!) unless the JIT restriction is lifted.
>so one thing developers would notice right away is abysmal JavaScript performance
That's actually a good thing! If a substantial chunk of iOS users would use third-party browsers without JS JIT, then webdevs would be forced to better optimize their sites, because the perf ceiling would be lower on these browsers. This then would lead to stellar performance for those who stick with Safari which does have JIT! Kind of how using an M1 is so good today, because there's still a large number of Intel machines out there, so devs can't yet afford releasing software that's only usable on M1 from a cpu/energy point of view.
In 2021, Microsoft added the "no JIT" option to Edge for additional security [0], and here's the quote in their blog post:
>We see that most tests see no changes with JIT disabled. There are a few improvements and regressions, but most tests remain unchanged. Anecdotally, we find that users with JIT disabled rarely notice a difference in their daily browsing
Because Google would be pushing it hard? E.g. when you click a link in the YouTube app, it doesn't open it in Safari, rather it shows you a "helpful" dark-pattern prompt about opening it with:
- Chrome (mind you, I don't have it installed, so this would send me to the AppStore)
- the "Google" app (again, not installed)
- Safari (which does not open Safari, rather an in-app WKWebView, so that Sundar can still milk your precious eyeballs)
- and finally at the bottom the "Default browser app" (this is what you want)
Of course, there's no setting to save this choice once and for all, so this is done each and every time you try opening a link in the YouTube app. Wait, actually, I'm 99% sure it would suddenly remember your choice if you had installed one of their browsers. From that moment they would duly open all links in Chrome/Google, without this annoying prompt.
I bet every Google app does this on iOS to get you install their crap. Disgusting practice.
Google is incredibly aggressive in promoting Chrome yes, but every time I've seen "Safari" as an option in a Google app it isn't WKWebView, but SFSafariViewController which is for all intents and purposes real Safari — it's essentially an out-of-process Safari tab with its own separate cookies, storage, etc. Apps using it can't snoop on your browsing session and they can't dig around in your cookies, etc from standalone Safari.
It’d be useful to see the difference clearly as a user. Personally I try really hard not to use any in-app browser because I have no clue how trustworthy the developer is (except for Facebook and Google, for which the answer is “absolutely not”).
> Because Google would be pushing it hard? E.g. when you click a link in the YouTube app, it doesn't open it in Safari, rather it shows you a "helpful" dark-pattern prompt about opening it with: Chrome
Ironically the reason this dark pattern exists is because Apple refused to implement support for user-controlled URI handlers in the first place.
This has already happened. The walls have already been torn down. The EU's Digital Markets Act has made it mandatory for Apple to implement those changes by Q1 2024
Anyone care to speculate as to whether Apple will take that opportunity to permit users in other regions that same liberty? Personally, I would not bet on that outcome without similar legislation forcing the issue.
No chance of Apple implementing this outside of the EU if they are not forced to.
They are getting billions from Google every year because Safari is the most used browser on iOS, and they will do what is necessary to make this last for as long as possible.
I can see how that applies for hardware manufacturers that don't want to build multiple versions of their products; however, software can easily be region locked using a simple flag without the same economic consequences.
Most people don’t give a shit about 3rd party app stores. I doubt 90% of iPhone users even know this is happening. (I say this as an iPhone user myself). So, I’m not sure negative PR is that much of a motivator.
I don't think Mozilla & Google both start working on iOS browser engines just to show what's possible. They might be speculatively developing these, but I think it's definitely based on an expectation that they have a really good chance of shipping these browser engines.
Oh yeah, bye bye Accessibility! Firefox has become mostly unusable under Windows if you are using a screen reader, in the past 2 years. And Android took almost a decade to catch up to what Apple did with iOS. So I am guessing, this new browser will need at least 5 years to be looked at by blind users :-)
This is one thing that the big dogs, Microsoft, and Apple have been good at since the early '90s. For all their faults, they take accessibility seriously.
I know a blind guy who uses iPhones exclusively. How he manages to understand speech that fast is beyond me, but dedicating resources to accessibility when it's such a tiny market share is nice of them. But now that I think about it, are they being mandated under ADA? I honestly don't know.
No, they are not being mandated. It basically boils down to Jobs declaring that accessibility is an exceiption to ROI. IOW, realising its a kind of social responsibility. Besides, Microsoft took a long time to provide something by default, they let other third parties sell screen readers for big money to poor people. Apple always did both built-in, the API and the screen reader (frontend). Microsoft created Narrator, their own front-end, just a few years ago.
I tried to Google what Jobs said about accessibility... I only found what Tim Cook had to say:
"When we work on making our devices accessible by the blind, I don’t consider the bloody ROI (...) The company does a lot of things for reasons besides profit motive. We want to leave the world better than we found it."
It may well be that Apple is special, but in general, large software companies are motivated to care about accessibility primarily by the prospect of lucrative government contracts, for which there are usually mandated (by law) accessibility requirements. The problem for smaller companies is that accessibility doesn't scale down well - you need a lot of upfront investment (education, processes, testing etc) to get anywhere at all at first, but then all that remains useful for many more projects to come.
I read somewhere that screen readers look for a flashing vertical line, to detect the caret position in systems that don't expose it via the OS's APIs. I can't find a reference for that right now, though.
I'd argue that accessibility helps everyone, and is thus a positive to ROI. You know those low contrast text/background sites everyone here complains about? Yep, those are not accessible, and probably end up with less readers as a result.
That's unfortunate, but you don't have to use Firefox. I don't understand why some people think more options are bad. You can still use Safari or Chrome.
Chrome is spyware under a different name and they won the desktop market by sabotaging Firefox and taking advantage of their search monopoly by blatantly advertising their browser. Most developers focus on the technical features and miss what giving such a bad actor a chance to monopolize another device category means.
Firefox is barely alive because of mismanagement and Google’s dirty tactics. If one could give access to Firefox while blocking Chrome that would be ideal.
That may seem wrong only because you’re thinking about things very literally. In reality it would blocking a known monopolist with a track record of bad behavior from monopolizing another market and allowing everyone else including Firefox to take part.
Firefox won from IE. it successfully broke the IE monopoly and gained significant market share. Then, years later, chrome entered the stage and conquered both.
I don't know in which world you live, but in the world I live common people (that is, non computer nerds) all had Windows and all used Internet Explorer. A few had Firefox or Opera or MacOS, but they were a little minority.
Yes, Firefox usage peaked at about 20%: surely not negligible (didn't know anybody myself using it !). As for geographical distribution, I could only find this: https://gs.statcounter.com/browser-market-share#monthly-2009...
The data goes back up to 2009, which was quite a peak period for FF...
Sure FF has played an important role in the browsers war, but it hardly broke the monopoly, or at least it did not do it alone (Safari and Opera started to gain a significative share at the same time).
> Oh yeah, bye bye Accessibility! Firefox has become mostly unusable under Windows
Same on macos. Cannot use Firefox, because it does not work with Macpass.app [0] autotype - to my understanding because Firefox does not support (some) macos accessibility settings/features. For me the UX with Firefox is just the worst compared to competition. It's noticeably slower, uses much more CPU - thus makes the laptop hot, fans constantly kick in and drains battery. A lot of (all of it?) non-native GUI components makes the experience not good.
Arguably this could be old information, because my gripes are from many years ago, though I try it every year or so - but the situation is still way behind everyone else.
I support the Firefox's message, even donated to them couple of times, even though don't use their product, but at least on macos - experience is too bad for me to use it.
I'm writing this comment with a screen reader on firefox. Not sure what your issues are, but the accessibility has been rather stable for me after they fixed the quantum disaster.
Interesting. For me, moving with the cursor in most webpages has become extremely slow around half a year ago. I hit cursor down, and braille and speech update after about 1 second. I am on Win10 with JAWS 2022/2023.
Win10, NVDA, no braille. Only difference with the chromium browsers that I've observed is that initially pages take half a second more to load, but it is likely due to the different adblockers I have installed.
Mozilla is going to have to pull off some crazy marketing genius to have any chance against the coming onslaught from Google and Microsoft. Both companies are likely willing to do just about whatever it takes to convert that chunk of previously inaccessible users… growth opportunities like that don't appear in the browser space very often.
A few weeks, at least. By that point, nearly every user should have gotten a notification that YouTube, GMail or Google Search is 100000% better with Chrome.
Why do people install those apps? Because the first time they visit that site on a new phone it tells them that everything will be better in the app, without mentioning that this is mostly true only for advertisers.
Ehh...I do think the native app often gives a better experience than mWeb.
Don't get me wrong, a really well-written PWA with fully cached assets is often almost at a native app experience level, but that's not usually the case with most mWeb implementations.
For Gmail, perhaps — I think that’s one of the best cases for push notifications on the web — but YouTube basically comes down to whether you need large offline storage and search is a non-issue.
One thing I noticed about both Google and Facebook’s apps before deleting them was that in addition to using more battery, both were slower in their apps than using the web site. That was surprising but consistent & a large part of why I ditched them.
For me, YouTube comes down to the fact that if I use YouTube through Firefox for Android, and install the "Video Background Play Fix" addon, then I can go for a walk with my phone in my pocket and listen to things through YouTube without having it pause as soon as the screen turns off.
Well, I believe you can do that if you pay for YouTube Extortion Edition or whatever it's called. Which I used to do, until too many ads still came through and I got pissed off.
(Though note: if I got to a YouTube link through anything other than going directly to the site and searching, then it would open in the app. Which would then pause when I turned off the screen. Which was irritating. Fixed by disabling the YouTube app entirely. Life is much better now.)
There are content blockers, which are not as comprehensive as Firefox or Chrome extensions but also avoid the performant and privacy concerns common in that space.
Historically there have been issues with inefficient code on pages with lots of elements or larger data sizes than expected. Since web pages are complex and ads continue to evolve, there’s this constant arms race where people run more code trying to block them and that code takes time and memory to run, and the update cycle means things are pushed out quickly.
A lot of the examples I’ve seen were unexpected situations: e.g. if you look at every <img> with a poorly-tuned regex and someone uses data: URLs, it might be backtracking pathologically on orders of magnitude longer strings. There used to be an issue with each injected CSS file being stored separately - it was fixed years ago but there was a multi-year period where people would complain about Firefox being slow, you’d ask if they had AdBlock Plus installed, and the performance issue cleared up as soon as they disabled it – the problem was an extremely large style sheet multiplied by every open tab and iframe. It was bad enough that they officially called it out on the Mozilla blog:
The other thing to remember is that a browser developer has to support every user, not just the savvy ones. You might know to stick to certain more-trusted extension but the Safari developer’s threat model has to include someone’s grandfather installing McEaglePatriotGuardElite and blaming Apple when their iPad is slow or that injected code is exploitable. Apple characteristically chose to respond to that by reducing flexibility, which is certainly a valid decision but also one people can reasonably disagree with.
So use an Invidious instance. Sure, YouTube blocks the subtitles for some of them, but if you need subtitles, it only takes a couple of minutes to find one of the new subtitles-available instance, and you're good for at least a few months.
I’m saying that it doesn’t do the web a service to break one monopoly while doing nothing about the more successful second monopoly. I want an open App Store but I also want fair competition in the browser market.
A browser from an Ad company and … I don’t know what Mozilla is these days. Doesn’t sound very reassuring. I hope they’d at least try to address memory and performance issues from their desktop counterparts. One amazing (and unmatched) feature of Safari on any platform it runs on is how smooth and battery friendly it is.
I browse the web most of the day on my Pixel 6 Pro, and battery usage indicates Chrome has taken 3% of my battery since last full charge. I'm sure iOS has a similar battery usage monitoring feature, I'm curious what percent Safari shows for you?
edit: and I'm at 13% remaining (blame TikTok), so not like I just woke up with a full charge.
The % is related to the amount of time you spent in a given app (and how much battery it consumes in that period). If you don't use your browser, then of course, you will not see battery use allocated to it.
It'd be cool if the Android version of Firefox got some UI love to bring it back to where it was before they force-updated folks to the "phone only" UI.
Pull to refresh is currently only enabled in Firefox Nightly on Android. There are still some open bugs to be fixed related to pull to refresh gesture breaking some websites.
>It'd be cool if the Android version of Firefox got some UI love to bring it back to where it was before they force-updated folks to the "phone only" UI.
Since this is open source, everybody should be able to adjust the UI to their liking. However, there are too many obstacles for this to be a valid option. What would be needed to make this possible? I think Firefox could become much more popular if the users could collaborate easily on designing the interface.
Is there a way to have tabs at the top of the browser? I like that about Chrome on my tablet, I can just hit the tabs at the top to swap, whereas on Firefox you need to hit the Tabs icon at the top right that brings up the switcher, then find the one you want and click that.
Did you even try looking? Settings > Customize > Toolbar. The settings list is not long on Fx mobile and the ability to change the position has been there since the day of the UI refresh.
The question was not about bottom vs top, iiuc. It was about having the tabs always visible vs behind a tab button. As far as I can see, there is no way of doing that.
Not that I would want it, myself, since my current counter is 48 tabs and I don't want a bunch more hit regions when I'm thumb-browsing.
It appears I did miss a part of the question. My tab count is ∞ because I'm over 99 and tabs are unloaded. At that rate, if I were on a tablet or something, I'd prefer access to TreeStyleTabs or the like anyhow because horizontal becomes a squished mess. I assume the ctrl+tab as well as alt+{1-9} shortcuts still work.
Most likely, yes. The entire iOS GPL ban to my understanding only exists due to a combination of an iOS App Store policy that's weirdly enforced (who is surprised...) and the fact that Apple's own code signer is required to be able to distribute an iOS app, and that one is proprietary because Apple, which means you can't use other people's GPL libraries in your apps.
It's highly likely that apps will still required to be signed by Apple, even if distributed outside the Apple App Store, just like Gatekeeper on the Mac.
I don't think the license matters at all, but you may not be able to upload something you can't prove ownership of, and there is still the notary requirement to run, it only changes the distribution channel after all.
What you could maybe do is do reproducible builds, staple the notarised x509 on it afterwards. Then you can 'prove' it is the same app, but still have the signed version in distribution.
I am deeply interested in Orion [0], the browser developed by the team behind Kagi search.
It is not widely used, but it's quite impressive. I feel this is the time for a better browser for the masses. I am not sure Google + Mozilla are the right actors to bring it alive.
The minute that browser has a Linux build I'm going to try to make it my default browser. I have not been this excited for an unreleased software package since KSP 2.
What surprises me about this is that they have only started this recently. At least with Google I thought they probably had an internal build of Chrome for iOS using Blink, even just for testing.
> The correlated activity from Google and Mozilla could suggest that they're expecting Apple to drop its restrictions on third-party browser engines in the near future, or the companies could simply be hedging their bets.
Ugh, imagine being an engineer on the project if it's the latter. At a company strategy level, it may be wise to put resources into having this ready to go. [1] At an individual level, putting tons of effort into something like this with less than average hopes of launching seems extremely demotivating (and doesn't look so hot for "impact" in perf either).
I wonder how much effort it is combine the iOS UI layer and the non-iOS blink layer. I'm terrible at estimating effort even for my own projects so it's hard to speculate.
[1] A bit less wise to do speculative projects while simultaneously laying off 12,000 people with no warning.
Yeah. This seems like a dream job for mediocre developers who are just at google for the paycheck and the creds. And considering the layoffs, they don't seem to have a shortage of those.
Quite the opposite! I would find it highly motivating to work on something like this, even if it was just a 5% chance it would make it onto actual phones. You certainly need the right types of people who are motivated by the right factors, but that is not unique for this case.
It would be more motivating for me if in the 95% event that Apple rejects it from the app store, a PR disaster can be launched against Apple for it, and instructions are published to install it on a jailbroken phone.
Don't even need to jailbreak, nowadays you can build/sideload using a free iOS developer account, especially if the projects in question are open source.
...which only works for a few days until you need to build/sideload again on a free account. (Or a full year if you have a 100$ a year paid dev account).
Sideloading isn't a solution because Apple artificially crippled it to make it only useful for demoing and testing apps, not as a secondary install method.
True. I guess my point was that, given the insane number of zero-click iMessage exploits there have been, you’d have to really not care about any of your data to use a jail broken phone.
I mean, i could understand if you were working on some sort of research prototype that might fail, or otherwise something new and unique, but just porting an existing browser engine hardly seems to be instrinsically exciting in and of itself, so what would the motivation be?
I've worked on these sort of "5%" / "just in case" projects before and mainly accepted them because they were deeply technical, difficult and I was sure I was gonna learn a lot from them, no matter if we got the go ahead to ship them or not. Sometimes I was the only one in the company who wanted to work on it, while other times it was something everyone wanted to jump on, I guess the conclusion is that different people find different things interesting. Some people like porting software to different platforms for example :)
Well, lots of people find structural problems with a massive code base but have no justification to rewrite/make changes to it. A chance to revisit decisions might be exciting for someone who feels they could perhaps do a better job with it.
> I would find it highly motivating to work on something like this, even if it was just a 5% chance it would make it onto actual phones.
Have you ever put 6-18 months of your life into a project that got canned? If you haven't, I'm not sure you should make that kind of statement without having actual experience knowing what that's like.
It’s a balance. I more-or-less learned the first time that I needed to be getting more out of it than the “release success”; nowadays I’d codify a specific part of that as “always carve out the time to improve your skills as part of the project.”
I’m teaching the computer how to do something, at the same time I’m teaching myself how to do it.
That said, when that’s not possible - At least one project had at least a few weeks (it’s been awhile) of stupid wrestling with undocumented Xcode CLI internals. That was nearly completely wasted time. It sucked then, and it (dilutedly) sucks now.
Haha, let me count the ways. This describes nearly an entire decade at Microsoft for me. It's not that bad. Some of those projects were amazing feats and fun to build. You eventually develop an "ok, what are you going to pay me to build next" attitude.
Some people may develop that attitude, but I haven’t. I care a lot about what I build and I care that it’s useful to people. I am unable to accept putting in tons of work only for something to never see the light of day.
A project I put years of my life into got killed off in a merger and it’s still the most demoralizing event of my career.
Careful not to imply that other's don't. I'm pretty passionate about what I build, but cancellation is a fact of life. Doesn't mean it wasn't fun to do the building. One of my projects at Microsoft was something that was always destined to actually be sold by hardware partners, and the hardware partners released devices that were far, far too expensive so it flopped and the whole thing was canned. But we made an excellent product that won some awards, and frankly, knowing we killed it on the software side is good enough for me.
I sure have. It requires a specific attitude and mind set. If you go through those 18 months hoping this will actually see the light of day, there’s a big chance you will be disappointed. If you rather see this as a technical challenge, and your task is to prove that it is possible, releasing the final product might not be as big of a motivator itself. Of course, you might not always know that the chance of success is so low up front. If you don’t, I would guess it is a lot harder.
Kind of a stretch, but all of my hobby projects are like this. I have spent years on a TUI library for Swift, without any intention of releasing it. I do it to understand how terminals and layout systems work. In this case I am more motivated by the knowledge gain and experimentation than actually having others use the product.
It happens. Let's not pretend that everything we do changes the world or is even meaningful. It pays our bills and lets us do what matters to us.
On a less cynical tone, 6-18 months on a project, then we change company, or get fired, or the company shuts down for good. Some of my startup customers pivoted or shut down. I got paid, not my problem.
Anyway, it's better to work on successful projects. They expand the business.
Working on a project with only 5% chance of launch is almost a guarantee that you will be at the front of the queue for layoff when the company decides to do layoffs.
There was an entire massive team engineers at Microsoft that worked on iPhone/iPad versions of Office for many years, and every time they were ready for release it was blocked by Ballmer. Their work finally saw the light of day the moment Nadella took over and was instantly a hit.
Google engineers often spend years on less exciting and interesting projects that get canceled or don’t succeed. Plenty of people would enjoy working on this whether or not it launches, and it’s also a high-profile bet, so I’d say it’s in the very top tier of desirable projects.
As much as I hate the App Store and want competition, for the sake of all the non tech loved ones in my life, I sincerely hope that either doesn’t happen, or that it is difficult enough to get people to “add” additional stores.
This doesn't seem to be the practice in a European country I live in btw, but I've seen it elsewhere (once bought a cheap android phone while travelling).
I'm not going to setup parental controls for Aunt Marge but sure as hell she'll call me when she installs spyware/malware and wants my help in fixing the problem.
I know that's the result of multiple app stores if a trusted entity can't/won't police them.
Why does it matter whether project is shipped or not? I work for money. I don't have income cut from this project. Whether it's shipped or not is outside of my interest. All that matters is whether it's good enough to ship.
I'd even say that shipped projects usually are less interesting because they're filled with mundane but necessary tasks and bugs, dragged by compatibility.
> I wonder how much effort it is combine the iOS UI layer and the non-iOS blink layer.
These browsers all compile and work on macOS. Getting them to work on iOS involves lots of fiddly details like forcing the browsers into single-process mode, integrating it with their existing mobile UI, etc
but core technologies like rendering won't be much different
The actual launch (or landing) probably doesn't really mean much for less senior employees as long as they would get enough attention from their management. But for those managers and above, it might.
> Honestly I think this is bad. We'll end up with Blink everywhere.
That could happen, but alternatively we could get Browser War III¹, in which Apple reintroduces an extremely competitive Safari for Windows in order to counteract the Blink (Chrome, Edge) hegemony. That would not be great news for Firefox, though.
It would need a good client. WebKit browsers exist on Linux, but almost nobody uses them due to their shoddy support for extensions and general lack of care put into cross-platform support. If you've got WSLG or a Linux machine laying around, go try the Epiphany browser - basically what would happen if you ported WebKit to an OS-native GUI with minimal modifications. It's pretty unusable compared to Firefox or Chrome, on every hardware/software combo I try.
I'd love to see "Cross-platform Software Dev"-era Apple throw their hat back into the ring, but putting Safari on other platforms is a big commitment if you want to take it seriously.
GNOME Web seems decent enough for me. Last time I tried using it the main issue was the lack of Widevine and similar DRM… if it weren't for that there's a good chance I'd be using it on my Linux machines because a GTK browser feels a good deal nicer on a GTK desktop than XUL and whatever the UI layer for Chromium is called.
I like the UI and overall design philosophy, but WebKit seems to be too neglected on Linux to be a reliable experience. The difference in text presentation between GTK/Cairo and WebKit itself was really jarring, and something I'd bet you'd notice on Windows too. That could be fixed with a well-made client, but it's a lot of work that I doubt Apple wants to go through.
> The difference in text presentation between GTK/Cairo and WebKit itself was really jarring, and something I'd bet you'd notice on Windows too.
When Safari for Windows was still a thing, Apple actually ported a good chunk of Cocoa along with it to support it, including text rendering. This meant that while it was still supported, Safari for Windows had some of the nicest looking text of any Windows web browser.
Based on Apple's more recent Windows releases which are built around WinUI, if they were to bring back Safari for Windows they'd probably take a more native approach, though.
I don't think they need to worry about this — traffic from Apple devices is oxygen to Google, which is why Google pays Apple $15 billion per year just to be the default web search provider.
But Apple has been quietly working on a search backup plan for many years, and they've been in the email business for longer than Google's existed. (I migrated a couple decades worth of email from Google Workspace last year, and I haven't regretted it so far.) I don't think building a YouTube competitor would be interesting for them.
> I don't think they need to worry about this — traffic from Apple devices is oxygen to Google
Which remains there when people switch to Chrome
> But Apple has been quietly working on a search backup plan for many years, and they've been in the email business for longer than Google's existed
Ah yes. They will just flip on the non-existent rumored Google-level search and the non-existent public email service to take on Google monopoly in search and email.
> Which remains there when people switch to Chrome
Fewer than 5% of iOS users will switch to Chrome as their dedicated browser. (In-app browsers will continue to be WebKit.)
> They will just flip on the non-existent rumored Google-level search…
Just like the flipped on the M1 after a long gestation period, exactly. It was 2015 when Applebot was first noticed crawling the web. A couple hundred employees with Apple's resources can do a lot in 7 years.
> …and the non-existent public email service…
iCloud Mail is Apple's public email services, and very few companies hosting email at Apple scale — iCloud has over a billion active users. If you have access to a Mac or Windows PC (https://support.apple.com/en-us/HT204283), you can set it up today. iCloud+ adds support for custom email domains.
From the perspective of users or developers, what's bad about this? I mean, we generally take it as axiomatic that it must be bad, but the dream of anybody being able to come along and make a Web browser is long dead.
That the network effects of everything only being tested on Chrome will mean that for some sites you have to use (eg Government, e-commerce you can’t do without), you’ll no longer have a choice of browser, and that that dominant position will be maintained even if Chrome starts to really suck, or Google decide to lean in to “you need a trackable Google account to use this”.
I am not 100% convinced that the existence of Safari exclusively on Apple platforms is all that effective at preventing this -- for instance, if you don't particularly care about mobile users you're pretty much already living in this world today.
Maybe, though maybe less so for business Web apps or other boring uses.
Either way, monopoly or oligopoly can also have salutary effects. Flash was a complete blight on the Web and all it took was Apple saying “no, we aren’t going to support that” and it disappeared practically overnight. Chrome’s been similarly effective in pushing forward some basic security measures. Hard to imagine this happening in a world of 50 different browsers with roughly equal market share.
I don't think anyone's talking about another elephant in the room: Facebook could very easily make their own framework for embedded web browsing and get all of their tracking ability back.
It doesn't matter that they can, and want, to invest as much as they do today in the browser space. Microsoft's IE was also the most competitive until it killed off the competition, then they decreased quality.
Back then the decrease in quality was by way of not developing new features, or developing them in a quirky way, that was all well form them because they didn't want web applications to displace native Windows applications.
The decrease in quality you may see from Google may come in privacy, they'll be able to tighten the surveillance as much as they want once no website you care about works outside of Chrome and you can't switch.
Yes and it was incredibly difficult to displace the monopoly of a vendor that had incentives to make their product, ultimately, unattractive in every regard.
Imagine now the network effects and a browser that actually keeps up to date, they'll just have won, period.
Hopefully Mozilla takes security seriously with mobile Firefox, finally. Otherwise Apple will appear justified in their regulations. The Android version of Firefox doesn't even support IsolatedProcess yet.
The Android version of Firefox does support NoScript and ad blocker extensions, though.
Releasing it on iOS would be huge. No more almost-functional Safari ad blockers with multiple pricing tiers! No more all-or-nothing JavaScript toggle button!
Honestly, the only thing keeping me from iOS is its inability to run a browser with a decent extensions ecosystem.
Technical question: What would a third party browser rendering engine allow, that using the safari renderer doesn't? I figure if you make a browser by just wrapping the safari renderer then you can make it do whatever you want it to. Why does the renderer make such that big of a difference?
Firefox addons on iOS, ported directly from the desktop versions with no modifications, will be possible. Gecko has a lot of under-the-hood knobs and dials that simply don't exist in Webkit, but are needed by the addon ecosystem.
Yes, you can run standard desktop Firefox extensions on FF for Android. There was a whitelist of extensions Mozilla allowed you to install though, I'm not sure if that still exists on the most recent versions.
The hoops are far too technical, finicky, and poorly documented for the average user to curate their own add-on list for Fx. It's a real shame since I think a lot of it is to make sure the add-on's UI is responsive, but many of most used add-ons on desktop have no UI to speak of (like redirecting AMP links, skipping short links, etc.).
You can use uBlock Origin on Firefox for Android. The biggest feature I miss when I switched to iOS, although I've found Orion beta also has this feature and is decent.
It's far from just the render engine that's being constrained. The whole virtual machine is restricted. The DOM, the js engine, the wasm engine, anything at all running or touching web code is locked the heck down.
There's a couple places browsers can add or supplant web platform features, but it largely prevents browsers from doing much at all to add to the web platform in any way.
In the rendering case, there's always work on css features & especially tuning that the browsers are up to. Just being faster, lighter weight, having more or better tuning is a great capability, a place where more than one small in-group should be able to experiment & improve & explore.
> It's far from just the render engine that's being constrained.
It is unclear whether this would still even be the case.
My understanding is that it's a _policy_ limitation preventing third party browsers on iOS. But there's also iOS security policies preventing JIT to have a fast browser.
I cannot imagine Apple opening up JIT-capabilities to all developers on the app store. I wouldn't be surprised if they didn't relax this at all. Perhaps they will they grant entitlements for JIT to a select few.
I agree that whether or not they'll allow JIT is an orthogonal issue based on security policies, but I don't think it's out of the question.
The security argument to not allow a JIT is that mapping code segments as executable+writeable opens up a lot of interesting attack vectors, and therefore allowing JIT weakens security. This is true of course, but the argument is a bit dubious for a few reasons. The first of which is that the OS is supposed to have sandboxing mechanisms that don't allow escape from the sandbox even if something goes wrong, and therefore prohibiting a JIT shouldn't be required in the first place. Furthermore WebKit itself has a JIT (whatever Apple calls their JS implementation), so iOS is already vulnerable to these kinds of issues in some sense. Finally, in general you can write and link in arbitrary code into your program (in read-only sections of memory), so attackers can already write exploits in C/C++/asm/whatever.
Obviously Apple needs special consideration for WebKit itself since the WebKit rendering engine is linked into a ton of applications, so a security issue in WebKit is a major problem because it affects many programs on the phone, including a lot of first party applications. But this wouldn't be the case with a third-party iOS browser, since even if Apple allows you to install a third party browser, they're not going to allow you to replace the system webview implementation with a third party one. Therefore a bug or security problem in Firefox/Chrome/whatever should be limited to just that app, and wouldn't have the same scope as a WebKit vulnerability.
Apple is notoriously restrictive so maybe they won't change their policies. On the other hand I think the current technical argument for not allowing third party programs to have JIT code is pretty weak, so I could definitely see a different decision being made at some point in time, especially if there was pressure from the legal team (e.g. due to things like EU anti-trust regulations).
This is a pretty big claim. It's not that the browser can't be secure. It's that Apple might not have total control & oversight over what is executing. And that Apple won't pursue further to find out: they just make their job easy for themselves by arbitrarily saying all code that runs must be reviewable in the app store. That's not a mark on other people's JIT engines: it's a mark on Apple's willingness to understand/pursue/investigate. At great cost to the consumer, in this case.
I don't want to be slanted in only one direction, so let me share the other side of the coin: in the new Web Extensions spec that Google has built from the ground-up by fiat (mv3), they too ban dynamic code of any kind: all code must be built in to the extension. And the extension can't be any kind of virtual machine, can't execute any kind of programmatic system within itself. Because Google too is a murderous shitty coward that hates the world, that hates potential, that wants to limit freedom, that curbs what is possible, under exactly the same premises of being for our security, but which also obstructs massive classes of very basic very simple very generic software that poses a threat to these sizable corporations ability to stay in absolute control. Generally I'm pretty ok with Google's behavior, but this particular vicious turn of events deeply deeply against the web & possibility makes me lower them to the same low dog piece-of-shit fuckwad coward shitsmear con-man that I have long seen as a fairly distinclty Apple low lying cowardice. For your protection is a vicious piece of shit lie, and end of basic liberty. Shame, you vicious piece of shit fucks, shame!! You call it security, but you are just not willing to actually do the work to understand or look at & investigate: you make an easy fiat rule that excludes countless valid & good uses, because it makes your life easy & benefits your systems of control, lowers user-agency. It's directly agains the end-user, and yet they say it's for our benefit: this is the worst kind of lie.
Ok? that's why you have the option to disallow them!?
I for one use web-apps that I need notifications from, it's a crucial feature which Apple has sabotaged on purpose for no other reason than self-interest.
If you personally don't want to use a feature, that's fine, but you're putting out a statement like that as if no one should be allowed to use that feature because some devs tend to use it for spam. It just takes like 2 or 3 clicks to remove rights of notification from a specific app, so it's not a big deal either way.
Why do they drag their feet so much regarding open codecs? It seems like they just need to take an existing dependency and integrate it in their browser, that doesn't seem like a lot of work. Maybe I'm completely wrong about that? Are there hidden complexities? Maybe they want to implement the codecs in-house? Royalty/licensing issues?
They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have?
> They want to only offer good options, to guarantee a certain UX. All of the codecs they do support have hardware acceleration and tend to be among the best in their class. Why would they duplicate functionality they already have?
This is provably false though. For example, they support Opus bitstreams either through WebRTC (because it's required) or inside their own buggy special-snowflake .caf container (so they do support the more "expensive" encoding/decoding part of Opus that could benefit from hardware acceleration), but they don't support Opus audio files (that is, the '.opus' Vorbis container which everyone uses to hold Opus audio, which is the "easy" part of supporting Opus and doesn't benefit from having hardware acceleration because there's nothing to accelerate there).
And they control their own hardware for how many years now? Their A4 silicon first appeared in 2010; they could have easily added whatever hardware acceleration they want to, but they chose not to.
Frankly I'm not sure what their motivations are. I guess they just don't care?
I’m trying to say they don’t care about anything other than the “blessed” path. Anything else is by accident. They couldn’t see a point to opus files, so they didn’t bother.
Well there’s setting the default search engine. That’s not part of the rendering engine, but remember when IE6 was so much better than Netscape? Or vice-versa? If content is way better from one part of the internet, then users will select that corner for search too.
WebGPU is key. Apple has been dragging their feet here while their AR / ML teams catch up to the rest of the industry.
8thwall (https://www.8thwall.com/projects) has some pretty good demos of completely cross-platform AR/VR stuff. All this gets a ton better if iOS somehow supports WebGPU.
And then there is user fingerprinting and ads stuff. A ton of fingerprints today are from CSS quirks and the like. Renderers can favor or disfavor these things.
Actual extensions (like ublock!), bleeding edge/experimental web features like new webassembly or web APIs (firefox and chrome usually implement these before Safari does), stuff Apple has decided to sabotage because it threatens the app store (like fullscreen).
> But on the other hand, if you care about your privacy, why would you trust a third party to intercept all of your web traffic?
uBlock Origin is free and open source, and its code is thoroughly reviewed by many contributors every release. I trust uBlock Origin over a filtering mechanism built into a closed source browser such as Safari.
WebKit may be open source, but Safari is not. The interface to access Safari's content blocking settings and the platform on which Safari content blocking extensions are built are both closed source, so your FUD about "intercepting web traffic" would be more appropriately directed at Safari than at uBlock Origin.
Yes, I have personally downloaded the uBlock Origin source code. I have also reviewed the code and suggested improvements. However, I don't even need to download the code to realize the benefits of uBlock Origin being free and open source. Even if I hadn't downloaded the code, there are many other users and contributors who have reviewed the code, and you can confirm this by taking a simple look at the activity in the GitHub repos.
So you think there is sone great conspiracy and that Apple is secretly tracking your web browsing history. But it only happens when you install a third party extension that sends it a bunch of JSON rules and that it went through the trouble of having two content blocking implementations that work ‘em the same way - one in Safari and one in WebKit?
My point is that because uBlock Origin is free and open source, anyone can see that it is not tracking users maliciously. On the other hand, Safari is closed source, so your FUD would be more applicable to Safari. There is no easy way for users to verify how a closed source browser such as Safari implements its content blocking. In terms of transparency, uBlock Origin is strictly superior to Safari.
You're changing the topic. You originally accused developers other than Apple of maliciously intercepting web traffic. I responded that your FUD is actually a greater concern with the closed source Safari than the free and open source uBlock Origin. What you're saying now about ad blocking coverage and web views is completely irrelevant to the invalidity of your original argument against an open browser ecosystem on iOS.
You are comparing a “web blocker” to a “browser” you are also waxing prosaically about how much better is and failed to show any examples.
The fact is that your ad blocking extension won’t work at all within embedded web views.
We know for a fact that a third party ad blocking extension can not intercept your web browsing history on iOS whether it is open source or closed sourced. It has no access to your web browsing history.
Your assurance comes from open source, mine comes from knowing that my third party as blocker doesn’t have any access to my web browsing.
The comparison is between Safari + Safari-compatible content blocking extensions and other browsers + fully-featured content blocking extensions (such as Firefox + uBlock Origin).
You have been spreading FUD about fully-featured content blocking extensions like uBlock Origin, which is not a very good argument because Safari itself is closed source and its behavior is opaque. A combination of Firefox + uBlock Origin is fully free and open source, and its behavior is fully and easily verifiable. It is absurd for you to criticize combinations such as Firefox + uBlock Origin when the combination of Safari + a Safari-compatible content blocking extension is clearly less transparent due to Safari being closed source.
Apple's anti-competitive App Store restrictions are preventing the superior combination of Firefox + uBlock Origin from existing on iOS. Fortunately, regulations will soon make some of Apple's anti-competitive restrictions illegal in some major markets.
uBlock Origin not being able to protect web views on iOS is yet another restriction imposed by Apple. If browsers on iOS were able to supply web views to other apps and activate extensions in those apps, as the Custom Tabs feature works on Android, uBlock Origin would have no issues blocking content in iOS web views. Don't blame uBlock Origin for a restriction that Apple created.
The difference is, webkit doesn't have an army of angry weaponised nerds that will go out of their way to remove every single unwanted pop-up and ad imaginable the second they appear.
Yes because people who care about unwanted advertising and tracking by a phone with an operating system built by an adTech company whose default browser doesn’t allow any type of ad blocking…
You are always welcome to run arbitrary JavaScript in the page. However, this does not mean the APIs other extensions use to block resource loads will work.
So it went from “it only supports JSON” to “yeah it supports more. I just don’t know if it will actually work. Because I haven’t looked into it’s capabilities”
That's a different question than was being asked. The current API does not really allow for anything like uBlock to exist. I expect if Chrome moves to a similar interface sites will start serving ads that 1Blocker will not be able to stop.
I said what I meant to say, I've literally drafted web standards before and Safari is often the last to implement them. I'm not talking about WebUSB or WebGoogleAnalytics or whatever
Don't forget about the times where Safari implemented standards wrong, or changed the standards after the fact.
Viewport units have been around for a decade now, and Safari still can't get them right.
For example:
Let's say we want to make a chat window, where a user can type in an input field at the bottom and little message bubbles appear above. Sounds like a job for flexbox and viewport units.
Okay, we'll have one flexbox div container with it's children being the chat messages and the input which get aligned to the bottom. Now we'll position the container so it takes up the full page using viewport units (e.g. take up 100% of the viewport's width, and take up 100% of the viewport's height).
Oh no! When the user scrolled through the messages, the browser's tab bar appeared and instead of calculating that 100% of the viewport is 100% of the viewport, the viewport isn't being updated, and now the input field has been scrolled out of the page.
That's okay, we'll just use the new dynamic viewport units which specifically account for the problem that Safari had invented, and which only took 8 years to come out.
Okay looks good, time to send a message.
Oh no! When tapping on the field input, now the keyboard covers up field so we can't see what we're typing.
>_<
Good work Safari...
Real good work...
When I say I want something to take up 100% of the viewport, I mean 100% of the viewport.
MediaSourceExtensions (https://caniuse.com/mediasource)is one good example of a useful API which has been supported by roughly ~every browser for years except for safari on iPhone.
On that page it says that media source was implemented in 2014, on year before Firefox and Edge.
I guess in your world "every other browser" is Chrome. And, sure enough, there are some parts of the API that are only implemented by Chromium-only browsers, and are not implemented by either Safari or Firefox.
Yes, but each app is approved by Apple before being put on the App store. Direct BLE and NFC control have lots of spoofing "dangers" and privacy issues.
Good lord people really don't get how Apple makes money. Have you ever wondered why apps like Jira, Github, or Notion aren't loudly complaining about the 30% App Store fees? It's because they don't pay them. How? By not actually selling the service in the app.
If all you want is an app for your users to use, you won't pay a dime outside of the developer fee. If you want people to discover your app in the app store, download it, and then pay you then it's a 30% cut.
Why if you can do that in a browser? Isn't much simpler? I don't want to install an app for every stupid thing. It's just simper to open the browser at a particular URL. The browser is a runtime environment capable (with PWA, that are not supported on iOS) of doing 95% of things a native app can do with decent performance without needing the user to install anything at all.
Anyway nowadays apps are even built with web technologies (such as React Native), would just be simpler to have only the web version, a single codebase that can be used with an iOS device, an Android device, a PC, a smartwatch, a TV, whatever. Distributing an app is a pain, especially for iOS, you have to submit it for review, Apple has to approve it, you cannot do certain things, why? I get that on Android is simpler, just install the APK and done, but unfortunately there are a ton of iOS devices out there.
Many native apps are better. Of course web people like to use web tech for everything. I like native mobile (kotlin/swift) a lot better for mobile dev.
And buy Apple devices to build, release, and test? That's expensive considering I can just open Epiphany in a mobile-sized window to see how WebKit renders.
There is some important information missing: recent EU legislation ( Digital Markets Act and Digital Services Act , aka DMA and DSA) will force the big providers to open up their platforms.
That includes chat service interoperability, allowing app side loading and alternative app stores, .... and a mandate to not restrict any significant functionality to first party only solutions, like JITs on iOS.
So this will become reality soon, at least in the EU.
The interesting thing will be if Apple opens up globally, or if they restrict this regionally.
ps: companies will definitely delay and fight opening up however they can, but the regulation at least avoids many problems that GDPR had and should be easier to enforce.
You send your friend your public key. He sends you his public key. You can now chat over any protocol as long as you encrypt the payload using your keys.
I don't think that was table stakes for SMS, iMessage or RCS. "Encryption", with the caveat that all first-world law enforcement can peek inside if they want, is not meaningful. Sorry.
Most of the code needed is still in Gecko's repo at https://searchfox.org/mozilla-central/source/widget/uikit but probably doesn't build anymore. Would not be surprising if someone had an up to date branch in a private tree somewhere though...
It seems that the way iOS implements W^X protection would prevent a performant JS JIT from being created. It will be interesting to see if/how this is worked around.
The implementation of that is not actually very difficult to do yourself (though I wouldn’t recommend it). The problem is you can’t actually flip the mask to execute unless you have permission to JIT which Apple currently doesn’t provide to third party apps.
Basically every JIT javascript engine now use W^X protection by default. So it is probably a non-issue. I think the problem is 'does apple even allow you to toggle the w and x bit?'.
If only a real Firefox for iOS 9.3 was released. It would make the unused iPad 2 I retrieved way more useful than it is now. That could be the thing that would motivate me to create an Apple account to download it. And, I bet, would reduce e-waste by a lot by allowing older iThings Apple is not willing to support anymore to be useful again.
I don't know any details on this project, but what I read from space between lines is that this could be a handy tool to have a better position on the annual negotiations of default search engine setup. If you can have just a 5% discount from Apple by having this choice, the whole engineering cost would be immediately paid off.
Nope, but if Google and Mozilla are putting this many resources into it, they might know more than we do, and I could imagine this coming with iOS 17 in September.
I am cheering on Mozilla doing this. They are the only bastion of a free internet left: we need a browser option, a good option, which isn't beholden to advertising dollars at every turn.
Let's hope they also add extensions. In the meantime let's hope mozilla readds extensions in android in a meaningful way which might stop its downward spiral
very interesting times. a few months back, i started contributing to a mobile browser app (OPEN-SOURCE) that has an integrated wallet. I think browsers are going to have many more usecases than just browsing the web.
Payments is going to be a key enabler - web2 or web3.
I think for this to catch on, they're going to have to make a real business unit out of it. People are accustomed to their money in the bank being managed by humans that they can call. A wallet on one browser on one device isn't going to cut it for the layman.
This whole thing feels like a lobbying push, and to be frank, I am more worried about the monied interests who might have bought this kind of lawmaking and what their end game is.
People in this situation could also have chosen to not buy a cell phone in the first place, eschewing that benefit for using landlines or cordless phones; and yet, I don't think we would consider that a reasonable limitation, right?
Clearly, then, there is some line that we must draw where people are buying something they think they want and yet should still get to have full access to, and I don't see why it would correlate with Apple vs. Google.
In my case, I barely wanted a phone: I want a good camera attached to a good touch screen; I have requirements past that largely dictated by size, weight, and durability. That's the device I am looking for.
The devices which satisfy my needs are mostly from Apple or Samsung, both of whom lock down their devices. (Can I install an alternative browser on a Samsung Android device? Sure. But is it my device? No. No it is not and it has never been, by far. Samsung is only ever so slightly better than Apple with respect to that shit.)
The reality is: every device should be open. It shouldn't be some trade-off in the space where you don't get to have a device with any of the other key properties you want just because it is always a better business model to build a walled garden and then shill your services, charge a usage tax, or run advertisements.
That said, in a world where it is allowed to build closed devices, and it is some random set of tradeoffs that we all have to tolerate, we have to get to complain about it, because then it is just yet another property of the device, and we get to complain about all of the shitty decisions we had to put up with, whether that's the pricing, the functionality, the quality, the experience, the "tactile feel"... or whether it is open or not.
So like, I don't really see the framework in which this one axis is something where people don't get to complain because "they should have gotten some other random shitty device that isn't at all what you wanted but was open"... this seems to just be some broken narrative--mostly pitched by people who clearly aren't also tracking the anti-trust work against Google and haven't been a part of the fight to jailbreak all of the random locked down Android devices--pitched by people who seem to just like locked down stuff and Apple's puritanical control over morality :(.
These people don't even want freedom. When I read their posts, I almost can't believe they're not bots created by Apple to promote and normalize their interests.
I just wish their shitty decisions didn't affect me. Unfortunately they do.
It is simple, choose an Android device. There are many premium android devices.
If you don't know by now that on iOS devices all the browsers are running the same engine under the hood, especially on a tech site like HN, then there isn't much hope for you.
I'm a reasonably-satisfied Android user, but Android is nearly as locked down as iOS. Sure, I can (and do) run "real" Firefox on my Pixel, and can (and do) side-load apps, but there are quite a few things I can't do.
For example, my Pixel 4 just fell out of Google's 3-year support period, so I no longer get security updates. I would be completely happy to run LineageOS or some other alternative that would extend the life of the phone with regular updates, but I can't if I still want to be able to use Google Pay and other apps that require the phone to pass SafetyNet. Those sorts of apps are a part of my day-to-day, so being unable to use them would be a showstopper. (I've read various things about tricking apps into believing the phone passes SafetyNet, but none of the methods seem particularly reliable, and for every user who says it works, there's another person who couldn't get it to work.)
So sure, it is technically possible for me to treat the phone as "open" and run whatever OS image on it I want, but then I become restricted in other ways as to what I can do on it. Maybe you don't care about being able to pay for things using your phone (etc.); that's fine. But I do, and I consider it a critical feature these days.
Given that there isn't an individual vote on each property of a device/ecosystem, iOS is probably the least evil rather than a completely optimal choice for many (if not most!) users.
Just imagine that type of reasoning applied to other parts of life, like politics, work, interpersonal relationships... "Love it, change it, or leave it" has three components, not two.
And if they'd bought one, and were unhappy about some aspect of that, you'd be here and write "But it's not your decision to buy an iPhone?". We don't live in a world were you can get your perfect choice with no compromises, and having made a compromise does not imply that you can't criticize decisions made by the system you choose.
Buying an Android phone certainly allows you to run other browsers that use their own rendering engines, but Android is hardly open; you are still restricted in many ways from doing what you might want to do, with little recourse. Installing a third-party OS image is possible, but then removes your access from some things that you might still like (any app that requires SafetyNet to pass, for example).
The bottom line is that there is no open phone platform out there that even remotely provides feature parity with Android or iOS. Anything you do is going to be a trade off, and for some people, there is no way to satisfy 100% of their needs and wants. That doesn't mean we aren't allowed to complain about the bits that can't be satisfied.
A significant % of people who buy iPhones are not able to make a truly informed decision about this at the time. They find out way later what the actual consequences of apple or google's walled gardens are, and can only escape the garden if they have an android phone with an unlocked bootloader
> A significant % of people who buy iPhones are not able to make a truly informed decision about this at the time
I mean the devices change year to year but are people seriously finding themselves surprised by what iPhone can do but Android can't or vice versa?
If we were talking about a college tuition loan or a mortgage then yeah I'd say `not able to make a truly informed decision about this at the time` but this is like the lowest stakes decision possible no?
> It's not cheap to swap ecosystems
Is that true? Seems like there is always a nearly free phone deal out there and your network will probably migrate everything for you anyway.
Most of the studios participate in MoviesAnywhere meaning a movie purchased on iTunes automatically shows up in your Amazon, Google, Vudu, etc library.
How many apps that you purchased that have an Android equivalent aren’t based on cross platform subscriptions?
Walled garden policies make full migration not possible, at least for free. Things like your music library, ebooks, in-app currency, etc are often not allowed to move.
If I were to move to iPhone now, I'd have to spend at least a hundred bucks finding and buying alternative apps.
Where is this narrative coming from? Only about 20% of App Store revenue coming from non game in app consumables (came out in the Epic Trial) and the other big money makers are from services like Netflix and Spotify where you can easily use your app cross platform. Even Apple Music is available for Android.
Most users aren’t complaining about any “walled garden”
About time. The way to free developers from the 30% app tax on iOS is through the web. Apple has been doing their best to drag their heels in order to keep grip over revenue from in-app purchases inside their walled garden, but the writing is truly on the wall at this point.
As an aside, for anyone interested in WebAssembly and the future of gaming in the browser - my team and I at Wonder Interactive are bringing the full power of native gaming to the web. We're building out a platform and suite of tools that allows developers to publish, host, share, and monetize their games directly to their players online, without any middlemen.
The current focus is on the Unreal Engine (4.24, 4.27) and UE5 support which is coming later this year. Other engines will follow such as Unity, Godot, Open 3D Engine, and custom engines we can provide porting for on our paid plans. We're building out a WebGPU backend for UE5, to really enable high end desktop and console quality games in HTML5. The goal is to free developers from storefronts that charge a 30% tax on distribution.
I wonder how difficult they're going to make things.
> To help protect against unsafe apps, Apple is discussing the idea of mandating certain security requirements even if software is distributed outside its store. Such apps also may need to be verified by Apple — a process that could carry a fee. Within the App Store, Apple takes a 15% to 30% cut of revenue.
Even if there is a choice, iPhone users might tend to stick with Safari anyway. Desktop Safari's market share is about 10%, roughly the same as macOS' market share, which seems to suggest limited appetite for browser customization.
> Desktop Safari's market share is about 10%, roughly the same as macOS' market share
Where you're getting these numbers from? Doesn't sound right to me, but maybe I just have a biased sample. I'd guesstimate that 50% if not more of my friends with macOS run Chrome, small percentage (2 or 3) runs Firefox and the rest Safari.
I have never read or heard of anyone using desktop Safari due to a “limited appetite for browser customization”. In every context of every conversation I’ve witnessed where desktop Safari was mentioned, every participant was fully aware other browsers exist.
As an example, Safari is the only choice if you don’t want to give more marketshare to Chromium but also need to programatically control or retrieve information from your browser. Firefox has no AppleScript support, which disqualifies it immediately.
One reason for that might be wanting to use the same browser across mobile and desktop though. I know I stuck with Safari for a while because of that.
I'm now on Firefox for both Mac and iOS but the iOS experience isn't that great.
Once other browsers are allowed on iOS, it's possible more users will migrate on both desktop & mobile to Chrome/FF.
No. Apple's iPhone app policies on iOS are stopping it. Safari on iOS is utter garbage. Once regulation fixes Apple's app policies, Safari will have to get better.
> You mean like all of the developers who aren’t creating native apps on Android and are creating PWAs?
I'm not sure I understand your wording right... Are you saying that devs creating PWAs are "free?" Because it's well-known that PWAs has been stunted by Apple and Google. The technology is well behind its potential. PWAs could do significantly more if they had better access to system APIs.
> Because it's well-known that PWAs has been stunted by Apple and Google.
It is not well-known. It is well-believed.
I don't believe Apple has intentionally crippled Safari just to prop up their native platform. Google are the ones who invented the PWA buzzword and spend all their devrel effort on pushing. It's hard to believe they would also try and hamper that.
I have occasionally needed to advise mobile users how to use a simple web app showing phone's location on a map. Sample size is at least tens of people, selection bias to somewhat young and active people. Based on this "research",for a median iPhone user a location-aware web app is simply broken. Without external help, they are unable to change the (default/dark pattern, I do not know?) setting of not letting browser access to location data. You are welcome to come up with reasons why Apple has made it so difficult. I have difficulties to think other than intentionally crippling web apps.
Not every website I visit needs to know my location.
Not every website with a map needs access to my location.
Only websites I specifically allow to access my location should have access.
On the iPhone and specifically safari I've never had an issue or a steep learning curve to showing someone how to long press the reader view (AA) in the url then select _allow location_ or whatever.
I wonder if you sample all had something in common. Did they not regularly use this web app? Was this an event specific web app? If so it would be nice if the web app detected mobile browser by user agent and displayed instructions for activating location. Might help reduce confusion.
There must be a higher bar (making it harder to blindly click 'yes') for user consent on the web because there's so much less intentionality behind what arbitary code your device will execute. Visiting any popular news website will run untrusted JS delivered through 10 different intermediaries in advertisements.
I think any complaint directed towards Apple's development on Safari can also be directed towards their actual native platform. Terrible/non-existent documentation, frequently breaking APIs, and a completely hostile app store and bug reporting/feedback process.
> So now there is a great conspiracy by both Apple and Google?
What conspiracy?
They have huge economic disincentives to further PWAs - there is no need for any conspiracy.
In the first presentation of the iPhone, Steve Jobs laid out a vision where the smartphone would run web apps, using fundamental web technologies (HTML, CSS, JS). He quickly backtracked when he realised Apple could impose a 30% tax on transactions in the platform.
> Maybe web technologies just aren’t as good as native?
No one said they are, but that's no excuse to drag your feet in implementing simple things like push notifications.
> In the history of computing there has never been a cross platform general purpose GUI framework that didn’t suck.
What GUI framework? I barely even know what we are talking about anymore. You don't need one with PWA - again, you're using fundamental web technologies, and enabling them to make system calls.
> Not to mention most Android devices in the wild are low end and don’t handle complex web pages well
So that's another excuse to not further PWAs, huh?
> What GUI framework? I barely even know what we are talking about anymore. You don't need one with PWA - again, you're using fundamental web technologies, and enabling them to make system calls.
Let me ask you this then. Name one cross platform framework that wasn’t meant to build command line tools that hasn’t sucked?
QT? Java Spring? React Native? Electron?
> In the first presentation of the iPhone, Steve Jobs laid out a vision where the smartphone would run web apps, using fundamental web technologies (HTML, CSS, JS). He quickly backtracked when he realised Apple could impose a 30% tax on transactions in the platform.
He “backtracked” because his “sweet solution” wasn’t good and everyone wanted native apps and web apps were called “a shit sandwich” by developers.
Do you know the history of creating “applications” using “web technologies”? They failed for RIM, Microsoft, and Palm. Web apps suck not to mention the clusterfuck of the front end ecosystem.
Every single platform that went down the “we can do great web apps” backtracked. They have never been good enough.
> So that's another excuse to not further PWAs, huh?
You mean making an app that’s actually performant on the majority of phones out there?
> He “backtracked” because his “sweet solution” wasn’t good and everyone wanted native apps and web apps were called “a shit sandwich” by developers.
Sure, the 30% cut of all sales was just a sweet coincidence.
> You mean making an app that’s actually performant on the majority of phones out there?
Twitter and Uber have PWAs for countries where low-end devices are the majority of phones.
> They have never been good enough.
Complete bollocks, there are plenty of excellent web apps out there, and it's one of the most important mechanisms for software delivery nowadays, in both the enterprise and consumer spaces. You are a fundamentalist and there is no point discussing anything here anymore
Were you around back then when developers were clamoring for native apps? It came out in the Epic trial that 80% of all app revenue came from games with in app purchases.
Besides that, most of the biggest players like Netflix and Spotify don’t even allow in app purchases.
Where are all of the great web apps for mobile? Have you tried using any of these web apps on Firefox for Android or is Firefox also involved in the conspiracy?
No one is clamoring for cross platform web apps accept web developers who want to foster a shitty Electron like experience on mobile.
And look at all of the server side work that Uber had to do.
And this wasn’t done to avoid the “30% tax” since Uber doesn’t use in app purchases. You do have Apple Pay as an option. But that’s a standard credit card transaction.
> PWAs could do significantly more if they had better access to system APIs.
Isn't the whole point of PWAs that they're easy because they're just web apps? If you start using system/OS specific APIs you lose all of the benefits except for the instant install time.
The problem with Electron is that it's bloated by including a full browser engine and Node.
A couple of years ago I worked on an app that ran on 5 platforms (iOS, Android, Windows, macOS, ChromeOS). Initially we used Phonegap and Electron but then we created our own native wrapper that used the OS webview.
Our macOS app went from 100MB to 5MB of download size and the memory usage also went down considerably. IIRC correctly it consumed like 15MB of memory.
It certainly didn't look native but for our use case (education) that was not an issue. We were able to target 5 platforms with a very small team and the GUI was a single codebase made with InfernoJS and MobX.
People prefer Electron because it gives them a consistent environment across operating systems, OS versions/update patch numbers, browser versions etc.
If you write your app to work in all possible combinations of the above - like you'd write a web page - you can use OS web view.
But not everybody wants to do that because it's not as straight forward as just writing your app and being able to fully rely on your environment. Perhaps you actually need features that aren't universally available in the OS web view yet, and performance degradation because of polyfills is not acceptable.
Also, OS web view is usually locked down more than Electron. It's basically a browser without the UI around it. Then you need to hack your own native bridge instead of just using whatever Electron made. I guarantee your version is going to be worse, you simply don't have the combined resources of the Electron open source project.
> People prefer Electron because it gives them a consistent environment across operating systems
People don’t prefer an application that takes up more memory, drains battery life and that’s not consistent with their other apps. Developers may prefer it.
How many users are switching back and forth between Windows and Macs?
The same applies in the other direction. When I was a Windows user, I hated the iTunes interface because it felt like a bad Mac port. I was a former Mac (and current) Mac user so I could tell.
Even before that, the Windows QuickTime Player felt like a bad port.
If the users don't want an Electron app, they won't use it and the developers will feel the need to change their ways.
Software development is not just about the users. Many Electron apps are single dev ventures. It's not easy to maintain multiple different platform specific apps even for a large enterprise. The larger the app the more difficult it becomes.
Does it? My feeling is that users use whatever you give them. And then they buy a new device because theirs is "becoming slow". They don't say "wait, Slack is just a glorified IRC, it should work on my iPhone from 2008, I will just refuse to use it" because they need it.
There are no alternatives to the Slack ElectronJS Desktop app. That's the whole point: they don't want to maintain native apps. And they don't open their API to let others do it, I guess because that may hurt their lock-in benefits.
Everyone loves to complain about how bloated Electron is. No one offers a solution that performs as well in supporting all of modern webs technologies.
So some of the richest companies in the world chose to invest in the more powerful platforms, does that mean if you don't already have billions in the bank, you aren't allowed to create applications for users on multiple platforms? It is an enormous amount of work to learn the intricacies of multiple programming languages and frameworks and then to get feature parity accross all your native applications will literally take you like 3x more effort to implement them. Moreover, the reason these companies chose native is because it provides more features and the reason web technologies can't provide these features isn't technical, it's political.
A smaller company’s ability to compete is not my problem. But why would I want to give any random web page that I browse to the same access to my computer or phone that I give an app that I choose to download that is much better sandboxed?
And most apps that would be suitable for PWAs are in fact free. How would Apple or Google benefit financially?
Besides most of the App Stores’s revenue comes from games
What happens when either Apple or Google introduce a new feature to their native platform?
Nope, the product managers in the tech industry do. It's all about cost (or perceived cost). Web tech is more successful because it seems cheaper. Not because the resulting apps are better.
revenue-per-employee has been at record highs in the industry for years now. Maybe companies could hire a couple more devs to make decent user experiences and native apps, instead of cheapening out and treating development like a cost center and using Electron apps as a way to just hire fewer devs (at the expense of a worse user experience).
If your revenue is under $1m, it's only 15%. If you'd do your own payment processing (stripe) and tax consolidation (?), it would only equates to about 11%.
When you pay close attention to things like web standards, one would have noticed how during the last 2 years the Webkit team seems to have woken up from a decade-long hibernation. They're actually releasing things, and in a pretty decent pace.
As the article implies, very likely due to regulatory pressure building up. And that tells you everything you need to know about Apple's stance on the web: they hate it, as they hate anything that is interoperable and uncontrollable. They'll starve the web to the maximum they can get away with and now that maximum is reducing, hopefully.
If the web was developed today, it would be rejected from the App Store. And while I agree that Apple was first, others followed suit and the spirit of something like the web is terrifying to established tech monopolists. Just read the Gates emails about the web from the 90s.
The most interesting thing for me is that iOS Safari has said they will support push notifications this year.
And I get it, most of us don't like push notifications, and on the web even more so. But lack of push notification support is the one thing that was forcing a lot of developers from just doing a decent progressive web app and instead forcing them into the App Store. I'm interested to see the growth in PWAs once iOS finally supports web push.
And just to try to head off the "but native apps are better" arguments in advance: yes, they can be, but I hate having to download apps from a company that I'll have a very short-term relationship with (or sometimes even a longer relationship). E.g. I recall.going to a charity event and having to download a (pretty poor) app for their silent auction. Only reason it needed to be an app instead of a website was to send pushes about being outbid, the auction ending, etc
That's what I said, Webkit has recently sped up their development, for all the wrong reasons.
As for Firefox, as much as I sentimentally align with it and still use it, it's a dead browser. I have access to some analytics of websites with a billion+ views/year and it doesn't even show up. It has like 0.5% market share on mobile.
They're irrelevant in this iteration of the browser wars.
It would surprise me greatly if Firefox were sending invalid User-Agent headers.
User-Agent headers are mandatory; and it would be counterproductive for everybody, including Mozilla, if Firefox were sending invalid User-Agent headers.
For years I sent a blank UA string. It worked surprisingly well until about 2010. Only real issue was some Tomcat servers would just barf out stack traces.
UA switcher is a pretty popular addon in the Mozilla ecosystem. So it may well be more popular than UA stats alone can surmise. (Though probably not enough to matter to businesses too lazy to test anything besides the top two.)
According to Mozilla only like a third of all Firefox users have installed any add-on at all. So multiply the number by 150% and you have the highest possible Firefox usage rate.
It's a different thing. Apple doesn't care about implementing them whereas Mozilla wants to strangle Google with their bare hands and would rather die before they implement them out of principle.
As much as I hate Apple's walled garden, I have to admit that the inability to do this is the only thing stopping Google from having complete dominance in the Web browser space.
The choice isn't Apple's walled garden OR Google's web dominance.
The choice is: Apple makes a broken browser with no available substitutes to make more money off the app store, OR they will need to actually invest in their browser and compete with Google.
The EU has wisely decided that Apple forcing people to use a broken browser is anti-consumer.
So now, Apple will need to compete in the browser space as well.
It's amazing how fast Apple has started to fix it's many problems in Safari all of a sudden, <sarcasm>I wonder what the reason could be...</sarcasm>
You’re greatly overstating the problem of using Safari. Google’s devrel team has astroturfed a lot about that but if you’re the average working web developer it’s been easy to support all of the evergreen browsers for years - the big win was dropping IE11 support — and you’ll see a significant performance or battery life win by dropping Chrome, which the average user will appreciate a lot more than not having WebMIDI or sites nagging them to enable push notifications.
The mistake here is seeing only one company abusing its market position when it’s really two. While I don’t like how Apple handled this — Firefox deserved better — it’s also the case that Google used their dominant positions in search, email, maps, and video to promote Chrome. I’d be a lot more comfortable allowing Chrome on iOS if it was accompanied by regulatory action banning that and requiring Google to do real QA on other browsers and not use proprietary Chrome APIs on their production sites, which held back Firefox and Safari performance on YouTube for ages because they were using the web components standard instead.
> if you’re the average working web developer it’s been easy to support all of the evergreen browsers for years
All the browsers bar Safari.
> you’ll see a significant performance or battery life win by dropping Chrome, which the average user will appreciate a lot more than not having WebMIDI or sites nagging them to enable push notifications.
I think the average user would much rather have a browser that follows web standards.
Why?
Because 90% of the apps on the app store could just be websites instead.
And what difference does that make?
Apple can't take a 30% cut off a website.
> I’d be a lot more comfortable allowing Chrome on iOS if it was accompanied by regulatory action banning that and requiring Google to do real QA on other browsers and not use proprietary Chrome APIs on their production sites, which held back Firefox and Safari performance on YouTube for ages because they were using the web components standard instead.
This has nothing to do with Chrome, or allowing Chrome on Safari. It has everything to do with the developers at youtube not updating their own service. Any regulations/QA would need to lie with the youtube team, not the chrome team. iOS users shouldn't have to suffer being locked to a historically bad browser because of it.
> I think the average user would much rather have a browser that follows web standards.
Which specific unimplemented standards are preventing your work? I’ve opened plenty of bugs in all of the major browsers and it’s decidedly not the case that they’re mostly Safari.
Last year’s interoperability push ended with a noticeable lag for Chrome:
> This has nothing to do with Chrome, or allowing Chrome on Safari. It has everything to do with the developers at youtube not updating their own service.
Yes, we know. Now think about whether it’s possible that working at the same company might make them less quick to prioritize work which undercuts a key selling point their company spent billions marketing. It’s not like the YouTube developers didn’t notice the big effort to put Chrome banners all over the site was a management priority.
Anyone who remembers how Microsoft products used to have weird bugs when used in non-IE browsers knows how that could end.
> Which specific unimplemented standards are preventing your work?
Still no proper Opus support, where it was available in Firefox 10 years ago.
Also bugs. My experience is that it's a common occurrence that I make a change, and it works correctly in Firefox and Chrome, but it breaks in Safari and I need a workaround just for it.
As soon as this happens, Google Chrome will be the winner with the other Chromium-derived browsers on phones for iOS. This has also already happened on Android when the user has the choice.
This will just cement the Chromium dominance and the EU has made that worse.
Firefox is no where near competitive enough to unseat Chrome or Safari.
> As soon as this happens, Google Chrome will be the winner with the other Chromium-derived browsers on phones for iOS.
Not necessarily.
Just look at how well Safari has started doing all of a sudden in the Interop 2022 report: https://wpt.fyi/interop-2022
Safari went from worst to best in cross-browser issues.
The fact of the matter is, the year that Apple realised that they weren't going to be able to escape or hold up the EU's coming regulations to open iOS to other browsers, Safari suddenly became important again.
Why would they do this if they were just going to concede the web to Google?
I actually hope Google gains complete dominance over the Web, and that in response, a meaningful coalition of powerful companies moves to do something better.
The whole thing - web browsers, web servers, HTML, CSS, JavaScript, etc - is so incredibly stupid, from a regular person's point of view. Programmers love all this shit, because Programmers just want to sit in a cave and play with their legos. But normal humans just want to do something. They just want to compute X, or move Y, or talk to Z. They don't want to hear excuses from Programmers about how hand-crafting 15 bazillion frameworks in googledy-gook languages is The Future. They do not care. They just want their life to be easier. And it takes a metric shit-ton of bullshit to make the Web useful enough to just get shit done.
Start a server. Install an operating system. Install a web server. Install an application. Design an HTML, CSS, and JavaScript web application user interface. Design a server-side application processor. Handle the storage, indexing, retrieval, transformation, authentication, authorization, encryption, deployment, backup, load balancing, and everything else. Learn 30 different tools and systems and frameworks and 10 different languages and 500 different paradigms and make something so complex that Leonardo would call you a genius if you could somehow explain it all.
All for little Jimmy to tell his teacher he's got the measles and is staying home from school. Or Margaret to order a replacement driver's license from the DMV. Or Kumar to order a pizza.
There are much better ways we could be using technology to solve people's problems than the jumble of bullshit we have today. But the jumble is propped up by trillions of dollars, hundreds of millions of jobs, and entire nations worth of infrastructure. Until one player dominates it all and controls it, nobody has a reason to upset the apple cart.
I hope Google does become the evil empire, so the rebels will see the chains on their hands and finally begin the fight.
Why would a user pick Chrome over Safari? From a software development standpoint, maybe Apple would stop tying browser versions to the OS if they had competition. Safari is IE all over again with users stuck on older versions because they can't upgrade their OS.
Yeah I’m really worried it’s going to lead to, or at least encourage a browser monoculture like back in the IE days. I idly wonder if being the default will cement safari as the most popular browser on iOS though.
Some comments seem to be optimistic about the potential change from Apple. But once Apple relax webkit requirement from app store, it will mean all "do not track" cookie enforcement would be easily worked around.
The default can still be Safari, not "all" enforcement will be worked around. We simply can't trust Apple to do the right thing without supervision, though. As we've seen with the App Store, Apple uses these positions of de-facto authority to disempower the user and reinforce their own profit margins. We let them fly by the seat of their pants for too long, regulation is long overdue for this business (and app distribution sector as a whole).
If you want to opt-in to Apple's protective blanket, do so. It's not an excuse to weld over the safety hatch for the rest of us.
The default _browser_ will mostly be Safari. But the moment webkit requirement is relaxed, all in-app browsers for Facebook, TikTok, Youtube, Instagram, etc will be replaced with their own forks without any respect for "do not track". They will become the second most used browsers on iPhone, not Firefox or Chrome.
I think that says more about how awful Safari is than anything else. I personally hate Google's anticompetitive nonsense, but I hate Safari's glitchy rendering even more.
How will enabling alternative browsers from Safari's takeover of Apple-based products, somehow bring the end of other browsers elsewhere? If anything this helps prevent that and since Chromium is open source, app creators can distribute their own browsers if so desired. Lots of people like to complain about the lack of having 100 different browsers to choose from with different backend engines, but if it is so easy then feel free to get started on it.
I see this argument all the time - how is it anti competitive if you have to buy a device from apple to use the apps?
Its not like anyone can just make an iphone, it's not like the PC market, it's not even like the macOS market.
If people (consumers) in general gave a rats ass about it they would pick an alternative. It's not even on their radar. Price is 95% of why androids sold at all, and they had all the time in the world to make something better.
I personally love the idea, but professionally hate it. IT shops chose apple for it being locked down, and burdening 3rd parties with extra support costs if the platform is wide open is a crappy thing to do.
The anticompetitive aspect is obvious, right now Safari development picked up full steam again after years of being half abandoned. Because of regulations, they can't just afford to rely on the browser monopoly anymore.
I look forward to seeing if any of the dire predictions from Apple fanboys who once vehemently opposed this sort of thing will come true. Will confused proverbial grandmothers get tricked into using firefox and then pwned by scammers? Will everybody abandon Safari and give Google a total browser monopoly?
> Will everybody abandon Safari and give Google a total browser monopoly
This one is scary. People who don't know history like to think that IE was a backward browser and MS forced it upon people but what actually happened is that IE was very innovative until Microsoft diverged from the standards and lock people into it. When the ecosystem(websites) integrates enough that your platform(the browser) is the only way to run all that(through Google services for Chrome?), they stop innovating and start monetising.
The difference being that Chrome is open source (ok fine, Chrome is closed source but the important parts like the rendering engine are open source as Chromium). So they can't lock anyone into anything. If they try that they'll just get forked. Indeed we already have Edge as a well-maintained fork.
Which isn't to say that Safari and especially Firefox aren't important drivers of competition. But the situation is nothing like the situation with IE.
There is lock in it’s just more subtle than the IE situation. Have you seen the chromium codebase?
It may be open source but no individuals or small teams would be able to manage a competing product, you’d need huge investment to compete. There’s a barrier to entry all the same.
Plus keeping up with the constant updates while trying to build a competitor…
Yes, but in the case of both Mozilla and Linux, they had a huge running start and have developed their moats (for what they are) over a long period of time.
A new organization coming in fresh and thinking, "hey I know what, let's fork Chromium", does not seem like a very long lived effort. I also don't see any new operating systems coming out from an unknown team anytime soon.
The open source projects you use as examples are entrenched, and it's going to take a major shakeup and/or cracks in the large organizations for something new in the browser or operating system space to emerge.
Firefox is great, but it’s barely hanging on at ~4% marketshare. That might skewed by Firefox users having tracking mitigations set up, but the result is the same regardless: devs and the suits above them calling the shots will see the tiny usership and ask why they’re spending anything on supporting it. It’s barely competing at all.
The standards and functionality that are required in a modern browser are already far beyond what "an individual or small team" could build from scratch.
The existence of Chromium absolutely makes it much, much more feasible to launch a Chrome competitor than if Chrome was entirely closed source.
Anything forked from Chromium can’t be significantly different from Chromium, because any change of that nature increases divergence from Chromium and makes it more difficult to keep pace with the firehose of changes being pumped out daily by Google’s massive Chrome/Blink team. It means that forks can never be anything but mostly-cosmetic reskins unless the party forking sinks resources equally large as Google’s into the fork, which gives Google power to shape the web as they please unopposed.
> unless the party forking sinks resources equally large as Google’s into the fork, which gives Google power to shape the web as they please unopposed.
I imagine even this already very unlikely outcome would also depend on said fork having a big slice of market share before they even try to drift away from Chromium, otherwise it won't have any effect and will likely die exactly because of said differences.
There are several chromium forks that do more than just "cosmetically reskin" the browser and they definitely don't have teams as big as Google's.
Additionally, nothing forces a company/group to merge that "firehose of changes". If google ever oversteps sufficiently, there is always the possibility that companies that are maintaining forks will stop integrating those changes.
> There are several chromium forks that do more than just "cosmetically reskin" the browser and they definitely don't have teams as big as Google's.
Very few of the changes in even the most diverged of Chromium forks change anything significant about Blink, which is really what matters. The bulk of differences are tied up in the bits wrapping the engine.
If forks don't keep up with Google's changes they're putting their users at risk of getting hit by 0days and other vulnerabilities.
> Very few of the changes in even the most diverged of Chromium forks change anything significant about Blink, which is really what matters. The bulk of differences are tied up in the bits wrapping the engine.
That’s because they don’t need to because there’s nothing wrong with chromium. In the hypothetical situation where Google goes rogue and messes with chrome to the point that forking is required, this would be done differently.
Google going rogue isn't the only concern. It's also that in a Chromium-dominated world, there is no room for other parties' voices in shaping the web. Google gets what Google wants, regardless of whatever protests Mozilla, Apple, Microsoft, or any other organization might have.
Have you ever seen a serious "fork war"? Open Source may be possible to fork, but that isn't a guarantee that everything will be hunky dory after a hard fork. The drama and chaos of "we need a trustworthy fork" after a bad actor does something unsociable can be awful (especially if that bad actor remains in play). Security/safety/IP audits of past code pre-fork after a major fork has become necessary isn't free or cheap and takes resources. Drama can draw weird boundaries between project attempts and create a lot of internecine fighting among the "survivors" of the "upstream crash". There's so much sociopolitics that may be involved. Open source projects still involve a lot of people, at the end of the day, not just code. Open source applications have died in a fork war.
The situation is different from IE, but there's still a lot of similarities and open source isn't necessarily the balm it appears to be. They code may still "be there", but code still needs people to believe in it/trust it/work on it.
Of course they can, it's about the marketshare and not the code. They can make some part of the browser running in their cloud services and no matter how much you look into the Chromium code the websites which support this will run in Chrome only.
Why would websites support this? Well, it can provide good rankings in search or some other goodie like speeding up the loading times through Google CDN or something and works for %90 of the people(because they use Chrome). Once enough websites integrate this, it's over.
> But the situation is nothing like the situation with IE.
Google isn't trying to kill the web and grow desktop App development, so yes it's different. And also people weren't complaining about Internet Explorer while it was innovative and competing against Netscape Navigator with annual releases. It was after 5 years of stagnation, not supporting new W3C standards, and unfixed bugs.
Google learned from Microsoft's mistakes. They participated in standards, they update often, and resolve bugs quickly. Everything Microsoft didn't do.
They also implement new features outside of standards but just as temporary experiments mind you. If developers happen to adopt them and implement them on their sites, well Google's hands are tied and y'all might as well make them standards (e.g. SPDY, QUIC).
Or, because the control the standards process they can propose a change to a private list, push it to WHATWG and get representatives from Apple and Firefox to pull it into the "living" standard without any public discourse or feedback (e.g. removing alert();).
This isn't to say everything they're doing is bad, but that doesn't mean they aren't working in their own self interest.
About as relevant as the parent... Not very relevant, but since the parent gives a short overview of browser engine history, we might as well point out that it started with the then-excellent khtml from the KDE project, that powers konqueror. That's little known, and a very interesting history tidbit.
Just pointing out there's a whole family of HTML engines, and Webkit wasn't the origin. It's also likely that it's the reason why Webkit is GPL, and we're able to have this discussion.
In my experience, Apple haven't exactly been very open-source friendly - I know working with them there's a rejection of any GPL dependencies, even if well separated and unmodified, or even just tools used in the build process if they're GPL3+.
I don't doubt if Apple developed a html engine from scratch it would use a different license, and the entire landscape of browsers would look very different today.
I'm the OP. I'm questioning the relevance, which is in response to the assertion that "The difference being that Chrome is open source (ok fine, Chrome is closed source but the important parts like the rendering engine are open source as Chromium)". My aim is to point out that WebKit is also open source, and that the engine being touted by the GP is actually a fork of Webkit. Its provenance in this case irrelevant.
Chrome got popular because IE grew to be terrible and Firefox became bloated and slow over time. Opera was a decent alternative but their alternative renderer couldn't keep up.
If Apple keeps their browser compatible, I doubt they have much to fear. Linking users to the app store because your site doesn't work is a great way to drive them away from your website, I doubt there will be much push for installing Chrome.
Currently, Chrome for iOS has a slither of the market share that Safari has. Most people don't even know you can install another browser at all. Unless Apple makes/keeps their browser uncompetitive, they won't lose a serious amount of market share.
If I recall correctly, Google was paying 1$ per install, so everyone was promoting Chrome and Chrome was actually better than Firefox.
Firefox then made a lot of missteps, tried to make a push open video and audio codecs for idealistic reasons and lost. They also failed to catch on Chrome's performance for quite a long time. They spent a lot of resources into experiments that went nowhere.
Safari is just as bad about not following standards though. I could sympathize a lot more if your argument was between Firefox and Chrome/Safari. In my mind Chrome/Safari are the hegemony.
I don’t know why you think that, it certainly sounds wrong to me. Like, not just wrong in a technical sense, but like, crazy wrong.
Did you live through the IE5 and IE6 days? Does the term “quirks mode” mean anything to you? Do you remember how Mac IE was completely different from Windows IE? Internet Explorer, back in the early 2000s, was a serious support burden for anyone doing web development at the time. Around 2010, Google dropped support for IE6 (in apps like GMail + Youtube) and a ton of other sites followed suit. It made a big splash across all the news sites and all the web developers breathed a sigh of relief, because they could say “we’re dropping IE6 support because Google did.”
Meanwhile, there was a parallel world of IE-only sites. Some of them were built on future widespread web technologies like DHTML, others were built on stuff like ActiveX. ActiveX ended up in the trash bin (where it belongs) and DHTML became normalized. It was… common, and annoying, to deal with corporate sites that only worked in IE, and then build your own site and fight to get it working in IE. It was not a fun time to be a web developer.
Maybe 6 or 7 years ago, I remember that Safari was missing some of the newer features that Chrome or Firefox had, but when I investigated, it usually turned out that I was using some future/experimental feature in Chrome or Firefox, and it wasn’t a problem with the standards-compliance of Safari per se. Or sometimes I was relying on behavior that was not part of the standard at all). Nowadays, my sense is that Chrome tends to have more experimental stuff available and a better set of dev tools, but otherwise, most stuff works in Safari or Firefox with little to no modification.
Things work but all too often the page renders differently. On top of that Safari only supports the part of web standards Apple agrees with. It may look like Safari supports something and then you get into it and they support like 10% of the standard, or the full standard but only on Tuesdays. It is rather annoying.
I agree that Safari should do better but Embrace, Extend then Exterminate is a real thing and lacking functions is not the same as having alternative "standards".
"You need to download Chrome" is the scariest thing these days, especially if you see it in Firefox.
> what actually happened is that IE was very innovative
We remember things very differently, then.
IE was hardly innovative, unless you count things like the <blink> and <marquee> tags, and the ActiveX which their blatant attempt to tie the web to Windows.
The other thing IE was known for was missing, incomplete, or out-right broken support for extremely basic HTML, CSS, and Javascript functionality that other browsers had no issues with. Leaving web developers to scatter their code/markup with IE-specific workarounds. Compounding this problem was lack of regular releases and updates. Except for security fixes, Microsoft considered IE to be part of the OS and refused to issue updates for it between OS releases, for the most part, which is why IE stuck around so long.
Nobody _wanted_ IE. It was just there as part of the OS at the same point in history that Internet access became a mainstream thing.
IE 4 and 5 were innovative (IMO as someone who used both at the time - 1998-2000 - and actively converted family members to IE) compared to Netscape: it had a cache which worked consistently (important in 28.8 modem times) - Netscape would ignore the cache in some situations, i.e. resize the browser window and it would re-download images, even though it had them in its cache, and also IE had things like smooth scrolling which helped make things "nicer" to scroll and feel better from a UI perspective, and things like "make favourites available offline" feature, where it would download a bunch of full pages (whilst you were dialed up), and you could browse them after you disconnected.
After IE 6, things when downhill fast with the stagnation, but before that point, IE was a good browser.
The biggest issue with IE is it was HEAVILY integrated into windows. That in turn made it really slow to move. To get IE 6, you needed windows 2000, to get IE 7/8, you needed XP, to get 9+ you needed Vista.
That particularly became a problem because the time gap between XP and Vista was huge (and a lot of people skipped it and went to 7/8/10). In the meantime firefox and chrome came up and started innovating rapidly. Chrome started it with the evergreen model and FF quickly adopted that model.
You used AJAX-based websites, right? That was first available in IE. Initially, IE unto version 6 was extremely innovative. Then Microsoft won, and they stopped trying.
They innovated on the side of the user. Not the rendering engine. I loved the IE interface.
But if one window crashed, the whole IE crashed. Then Firefox tabbed browsing took over hungry for system resource. But at least it didn’t crash, right?
I remember IE research pane. Innovation in the browser became from a toolbar thing. Remember google toolbar? It was the number one bar in many countries.
But then Firefox extensions took over hungry for system resource, but not like Chrome hungry.
IE had addons. Some of them slowed the browser. And it had plug-ins.
It had everything independent innovation needed to thrive. It just didn’t have any vision for the “open web”. No one understood what that was then anyways.
And where ie could not innovate on the web, they used active X plug-ins. This was the Microsoft way. You can’t blame them for being themselves.
"It had everything independent innovation needed to thrive. It just didn’t have any vision for the “open web”."
But it didn't had an open source core and was windows only. The vision was microsoft only (forever).
"This was the Microsoft way. You can’t blame them for being themselves. "
So the argument is, "yeah, Microsoft is a big monopolist who do everything they can, to lock people on their system, you cannot blame them for it, this is just the way they are"?
Either way, in this case luckily their monopol strategy failed and IE died because of it.
Also `box-sizing: border-box` was how IE designed CSS box sizing (to be simpler to math for the CSS writer rather than simpler math for the Renderer programmer). The fact that it is now just about "required" boilerplate in most CSS reset/normalization steps to throw in a `* { box-sizing: border-box; }` rule to opt in to "do it the IE way" is a massive, vestigial, lasting testament to IE's innovation in CSS in the early CSS standards.
Allowing a dominant OS to foist a bad browser on all of us is not a good way to prevent a dominant internet search company from potentially foisting a bad browser on all of us.
Two different contexts here: Google still has a major dependency on the web so we cannot pull its money out of the platform that easily. Also, everyone nowadays understands how important platform control is and MS made a significant mistake before. If Google abandons the web then some other random corp will pick it up. Why would Google allow that? A market monopoly is not something passive which can be retained that easily.
My “confused proverbial grandmother” has already been tricked away from using safari. She does all of her web browsing through the Google app.
Not the Google Chrome app. The Google app. :facepalm:
I’ve tried to explain why this isn’t necessary but as far as she knows, google is the internet. And I cannot say anything to convince her otherwise. After all, every search in safari will re-advertise to her “hey you should be doing this in the google app” and she will click the button without even thinking.
My wife seems to only use the Google app as well. The G app has a confusing multiple back button design. The normal safari back button takes you back to Google homepage and the other back button iPad the bottom in your history. Whenever she shows me something in the Google App I always pick the wrong one.
I'd like to take a moment to appreciate how we're afraid of which search interface Grandma uses.
A hundred years ago, we'd be worried about getting knifed by strangers, bear maulings, starving to death, being homeless, eating food laced with botulism and lead, influenza, tuberculosis, diphtheria ...
To be fair, I think the origin of the worry may be that the elderly and less technically inclined are prone to being taken advantage of (rightly or wrongly). You're very correct that things are better than ever, as it were, but vulnerability seems to have endured in some ways.
Just like mine, who also accesses her photos by unlocking her phone, going to the camera app, and then to her photo roll. She never goes to the Photos app directly.
That site’s methodology skews towards people who hit their monitoring service’s customers’ sites. That doesn’t mean it’s wrong but just limited to a certain corporate vantage point — every time I’ve compared it to server traffic it dramatically understated Firefox and, to a lesser extent, Safari. This got worse after tracking protection and ad blockers became more widespread.
Currently I’m seeing Safari and Chrome at roughly 50:50 and 60:40 for visitors across some large public sites. That’s the reverse of what NetMarketShare has, but agains I don’t think that’s malice or error as much as different perspective.
Yes I think so. I predict that Apple will stop neglecting Safari now that they're forced to compete, and also that most users will stick with the default anyway.
Yes because of the great choice of browsers on Android, companies of all sizes are eschewing native apps and telling Android users just to use their website. On the other hand they are being forced to create apps for iOS.
That's why Google's apps ask you in which browser to open links, with Chrome being the first, and default, choice. And conveniently "forgetting" the user choice.
Don't forget about Google search which will push Chrome every chance it has. And Youtube.
As someone who has used Firefox on Android as the default browser for years, one thing that I must say is that Android never conveniently forgot my choice.
I'm not talking about the OS. Google's apps conveniently forget the choice on iOS. Less aggressively in the past few months (probably caught by Apple), but still.
Oh, I didn't know that on iOS the apps is responsible for picking another app to open an resource.
In Android, the app just throws an intent to open something, the OS opens the list of app capable of handling it, the user picks the wanted one (either 'only this time' or 'use this as default next time'). The OS, not the app, then remembers the choice.
> Oh, I didn't know that on iOS the apps is responsible for picking another app to open an resource.
I don't think they are responsible, but you can invoke a specific app if you need. Google's apps keep showing this sheet with "browser choice" quite often, conveniently forgetting that the user keeps setting "don't ask me again".
The choices are: Chrome, Google, Safari, Default system browser.
The thing I was never understand how can one use chrome on android when its not allowing ads blocking? Zillions of notifications and pop ups, fraud ads that have more space than information you want to read. Trackers that slow down your pages and destroying battery by sending every move to google several times a second. Constant redirects to google store, constant attempts to subscribe you to mobile provider premium services. Android users living in spyware hell.
What does that have to do with the narrative that PWAs are a great alternative on Android yet no company seems to take advantage of the fact and they still all create an iOS, Android and web app?
That is a total strawman, and please don't use the perjorative term "fanboys".
Not many Apple fans have ever defended Apple's exclusivity on the browser engine. It's long been an annoyance, honestly.
But it also has never had anything to do with scamming grandmothers. That's always been an argument for not allowing arbitrary untrusted app downloads and/or 3rd party app stores. Nothing to do with browser engines, where Apple's (weak) argument has always been about the risk of unknown browser vulnerabilities allowing malicious code to escape the app sandbox.
And if iOS browser share winds up mirroring macOS browser share, then it'll go to about 2/3 Chrome.
I don't make the connection between "Apple fanboys" and preventing a Chrome monopoly. Surely one's opposition to a monopoly is independent of one's choice of operating system.
But yes, most likely this will result in a Chrome monopoly.
It would be strange to force Apple to allow its competitors to establish footholds on their own platform, against their will, only for a Chrome monopoly to emerge months later. A web monoculture will be harder to undo than enacting smarter antitrust legislation.
I don't know if that's a good reason but it's definitely a true reason. Chrome on Android devours power.
The thing people are worried about is being forced to use Chrome and Chrome being a worse experience than Safari. If web developers en masse say "oh thank god finally we can drop support for Safari" then we're in a worse situation for everyone involved. We've done nothing but trade a lack of choice for a different lack of choice and ensured that the already dim situation for web apps being ported to non-Chrome browsers will get even worse.
Would Safari on Android (and with the same features) eat less battery though?
I agree in general regarding it being better if multiple engines are available. On the other hand, when I build something, and I'm developing it on Firefox, it usually just works on chromium-based Browsers. Safari tends to be the odd one out that has some weird behavior, although it's much less common and much less bad than it was in the IE days.
Also: not having to buy a Mac every few years just so I can test things in Safari sounds sweet, too.
Web developers wouldn't drop support for Safari as long as a significant amount of users use it (and especially not if those users are premium users, which they tend to be: higher disposable income, better trained to pay for things etc), so I don't think that's an actual risk. At least for anything I'm involved with: we'll drop Firefox before we drop Safari, and we pretty much keep Firefox only because some developers and some PMs are using it.
> Would Safari on Android (and with the same features) eat less battery though?
Yes, probably. WebKit browsers on other platforms like GNOME Web/Epiphany on Linux is easier on battery than Chrome or Firefox. WebKit is generally speaking more efficient than Blink and Gecko.
It’s a Chrome problem with Firefox somewhere in the middle. It’s like 4 hours battery life difference on an M1, too, and since I use a hosts file for ad blocking I don’t think it’s just that.
Could you please elaborate why you hope 'Chrome gets banned'?
I understand not being fond of the its ubiquity, especially with many Websites now requiring Chrome. And Google is allegedly abusing their dominant position. But banning it? Why?
Doesn't matter. Google is done. Mozilla's thing will be trying to out-race Apple on Privacy. Mozilla should stick with WebKit, only allow more granular control.
Why would that make it worse? It's not like they would use new rendering engines, they'd just use the same ones they're already using on desktop. You should make sure your site is compatible with those engines anyways.
It depends. Power efficiency on Safari with iOS is quite optimized and many features are integrated to iOS. E.g. some authentication workflows to Apple services.
Why does that matter, though? Web developers don't assume the entire world is "Safari on iOS". They have to handle all the various desktop browsers, as well as everything that runs on Android.
If it's not possible to do a particular Apple-specific authentication workflow in Firefox on iOS, then users will fall back to whatever else is already implemented for other platforms.
If users don't like how Firefox or Chrome on iOS drain their battery, then they'll stop using them and go back to Safari.
> Why does that matter, though? Web developers don't assume the entire world is "Safari on iOS". They have to handle all the various desktop browsers, as well as everything that runs on Android.
My comment might have been in wrong place, but the point was that it is difficult to be competitive with Firefox or Chrome on iOS if Safari integrates better on Apple systems.
And what if implementing these impacts other platforms.
Because Firefox has a tiny user base and nobody is going to follow their standards as long as other browsers do enable third party cookies. Also, there are alternatives to third party cookies for most use cases, they're just more difficult to implement.
Neither Google, nor Microsoft, nor Apple seem to care much about re-engineering third party cookies. Until that changes, any attempts from Mozilla to change the standards is a waste of time and effort, really.
I see a privacy.firstparty.isolate, but no thirdparty variant. Was that just an error on your part, or is it a pref that needs to be manually created, even?
It breaks things because a lot of websites expect it to work. If websites stop working then Mozilla will lose marketshare even faster. Still, it's not that difficult for people who know what they're doing to find.
It breaks legit uses of cookies. We need standard non-cookie based authentication. All browser features that enable violations of privacy need privacy respecting alternatives. Adoption cant happen until they exist.
Yeah, I've never understood this. Disabling third party cookies is the first thing I do with any new browser (uBlock Origin is second). It takes 30 seconds and very rarely causes problems.
If Safari weren't shoehorned through iOS user throats, webkit would cease to exist.
Right now web developers are forced to support webkit because they can't tell iOS users to install Chrome for better experience.
If they could, they would drop webkit and provide blink-only experience. Many websites do that to Firefox nowadays.
And if webkit can't render website, Apple would replace it with blink. So Safari would become another Chromium reskin and Web would finally settle on a single engine.
You say that like it's a desirable thing? Being a spec with multiple implementations is a feature of a good platform, not a bug. It pushes the Web towards consensus-driven evolution rather than design by one actor (in the past, Microsoft; now, Google).
I have no idea if it's a good or bad thing. Having single engine for a web developer is a good thing. Having no competition is a bad thing. Having engine controlled by a greedy ad-driven corporation is a bad thing. Blink is open source and theoretically could be forked by anyone, so that's a good thing. Blink is the most advanced engine, so that's a good thing.
If Apple wants to position WebKit as an important independent implementation of web standards it needs to run on more than just Apple hardware. I shouldn’t have to own a Mac an an iPhone to test my code on Safari.
What I really like to see next to this is the requirement that when I tap a link in an app that it opens in the default browser.
Too many apps, such as Reddit open with the WebView of Safari, which sucks. I'm not signed in there, it doesn't add to my history, and most importantly, they get to inject a whole bunch of tracks that I don't want. See [0].
Doesn't Android open the Chrome web view too? On F-Droid I think you can get a Bromite web view, but I'm not sure how these web views work, and if I can get a Firefox one.
When you open a link in an app, you're often directed to a Custom Tab (you can recognise them by the menu in the upper right corner being the browser's). Those are handled by your default browser. I'm using Firefox Focus in that capacity and it works great.
