This is an excellent article. You should be able to choose a browser and then use it in all situations. Google Search only using Chrome, Apple only allowing their own browser, Facebook and others pushing us into their own in-app browsers, all of this makes things worse for users.

(Disclosure: I work at Google, speaking only for myself.)

You can disable embedded chrome in Google app; https://support.google.com/websearch/answer/7013866?hl=en&co...

Not in Google maps on iOS though.

Data sample of 1, here, but I tapped a link in Google Maps on iOS 15 and it opened using regular embedded Safari, not Chrome or anything remotely Chrome-like. It uses SFSafariViewController and there’s a button at the top to go back to Chrome (Done), it animates in from the bottom, and you can tap an icon in the lower right corner to open in Safari or another browser. Safari is set as my default browser. I changed by default browser to Chrome and the same thing happened, Google Maps still used SFSafariViewController. I like it. :)

It's an embedded browser. When I click a web link in an app, I want my browser app to open it.

There's no option in Google maps to do this.

The button, bottom right, opens the page in Safari, and is standard across all iOS apps implementing that webview. In what way(s) is that not what you are looking for?

I just want it to open my default browser on the first click. There's a setting for that now.

Otherwise the history is lost, among other things.

It’s a usability trade off in some ways. Some people will find it confusing that a link opens their web browser. They might ask how to go back to Google Maps. This way there’s a balance. They can quickly preview the link, and if they want to keep it, they can open it intentionally in their browser or share/copy the link with one tap. Users who don’t understand how tabs work won’t find their browsing interrupted by every webpage an app throws their way.

But indeed, that doesn’t prevent an app maker such as Google Maps from making it a preference. Technically if Apple made it a preference it might break the expected UI for apps using the control. And as I noted before, there are advantages to previewing links this way, it encourages users to stay within the app.

There is no technical reason why it doesn’t log history events when loaded. It could send a message to the default browser or keep a log in the background and let the browser know when it next launches, and arguably for consistency Apple should design such a feature.

> They might ask how to go back to Google Maps. This way there’s a balance.

In iOS when an app opens another app, there is a back button specifically to go back to the original app. It's right there at the top left where the standard back button for most app navigation normally is.

> it encourages users to stay within the app.

This is one of the main reasons why they do it in my opinion. Another reason is because they can track your activity in the embedded webview.

It's probably a good sign that you had to tell this the Google engineer.

I did know you can turn it off. But I want setting a default browser that supports the Custom Tabs protocol (ex: Firefox) to make that browser be used any time an app asks for a custom tab, without any additional steps.

This is currently not possible because the filtering is done by the application calling CCT. The default CCT library implementation explicitly filters on the list of known Chrome app IDs and the app has to explicitly work around this filtering by trying the default browser first before falling back to the default CCT call.

It sounds like you're saying that this is currently not possible because it's currently not implemented that way? But of course! I'm saying they should change it so that the application asking for a custom tab can only request "please give me a custom tab".

I'm saying it's not possible at the OS level because the filtering is done in application code. CCT is not an OS service, it's a client library and a service IDL. Updating the library to remove the ability to filter by application ID is similarly not possible because binding to specific application IDs is not unique to CCT, it's simply how binding to services works on Android.

You lost me. Are you saying that the people who make Android OS can't reprogram Android OS? That is all this person is saying.

That's not what they're saying. The "chrome custom tabs" feature is a service interface exposed by an application, not the OS. There is no "open a custom tab" feature provided by Android. Therefore applications have to locate an installed browser that is known to support CCT before asking that application to start a Custom Tabs activity. The involvement of the OS in this interaction is to show the calling activity a list of applications that handle the ACTION_VIEW intent for URLs, and to bind the browser's CCT service to the interface for the client. The clients are the one choosing to only interact with Chrome at this point!

I think this should be looked at a lens of what’s net gained and net loss. From my point of view , if Apple was to allow other engines on their devices chrome will be the de-facto winner.

No Apple is not going to try to make Safari compete with chrome , especially on windows.

No developers are not NOT going to use Chrome as their target browser and use Chrome push standards

Yes people will switch over to chrome since it will be the one browser developers will target for sure to make sure every hiring works. All it takes if for one website to recommend it in order for users to switch.

Ironically the only thing saving the web from complete Google Control is the opposite of competition. I do not see a scenario where competition does occur and Google doesn’t win. Especially on a service they’re not willing to put in their death bin.

It’s fine, a lot of people still use Safari on desktop despite Google Chrome being available. And developers have to support it all the same

The same was true when IE dominated. The point being missed is if a single browser is allowed to dominate across the board, the owners of the technology become the gatekeepers of web technologies. That would have been extremely bad under Microsoft, and it is going that way with Google. In fact, there was a groundswell of negativity towards WebKit until Google broke the hegemony with by forking it, creating Blink. Which is now in a significantly more dominant position than WebKit ever was.

I’m not suggesting that Apple would be any better or that not allowing other browser engines is a good thing. However, the fact that they don’t is keeping Google/Chrome/Blink from having total dominance of the web.

I'm a regular desktop Safari user and you'd be surprised how many websites are just flat out broken in Safari, especially government sites. Part of the reason I use it as my daily driver is to ensure that the websites I'm working on get tested properly in Safari since the defacto browser for most developers seems to be Chrome.

I wish Apple would make a Safari for Windows or Linux. That the only way to test that your site works properly in Safari is to buy Apple hardware is certainly a contributor to sites being broken in it.

They had Safari for Windows for several years, but abandoned it because it didn't gain enough market share.

That is the point, they want user to complain to Site owners for not working on Safari and forcing them to Buy Apple Hardware.

Basically if you want to serve the 1.4B Active Apple Devices which nearly all use Safari, you have to buy an Apple hardware to test it.

It’s not a perfect analogue, but under Linux, Epiphany/Gnome Web is a reasonably close match for most purposes. Not sure about Windows.

The main reason safari is used in desktop is because other browsers are not first class citizens. They have access to resources that third parties don't.

Apple doesn't allow competition on their device because they know they can't win if forced to compete. Apple, even with all its resources, can only be spread so thin. By hobbling the ability to run your own engine, they don't have to try very hard.

This is the same reason they don't allow open installs. If they like an idea, they can compete at 30% more margin and with their army of engineers. Look how easy it is for them to enter the banking and movie businesses.

Keeping developers weak means they yield all the leverage. It's the modern anticompetitive playbook.

The DOJ can restore the balance by forcing Apple to open up compete fairly. It'll make for better software and products all around.

I don't think this is true. Safari on Desktop still has a considerable market share. IMO Safari is actually a pretty great browser. It is fast and power efficient, and much of the reduced feature set is stuff that I don't want anyways, like Push Notifications or PWAs on Desktop.

Btw, safari has its own API to get push notifications on desktop.

I assumed it was because they didn’t want users using the default, pre installed browser to see “this site works better I chrome” alerts on their i-devices

A sure sign they can't keep up and aren't winning over mobile web devs.

Windows search also uses IE / Edge when you search through the start menu, and this can not be changed as far as I know. Hope they rethink that for Windows 11.

Do you by chance know how to remove the annoying search bar at the bottom of the homescreen without having to install a separate launcher or rooting the phone?

> A browser is an application that can register with an OS to handle http and https navigations by default.

A browser in 2021 is a full OS, data store, compiler, network API, runtime, virtual machine, application platform, and user environment. It should really be called a Web Operating System.

It's not surprising that Apple, Google, and Mozilla have very different visions of what they want in terms of a Web Operating System.

For example, Apple and Google have opposing interests on iOS. Apple generally benefits from replacing web apps with native apps, while Google generally benefits from replacing native apps with web apps. (Google's own apps might be an exception.)

Web developers may like (Google/Chrome's) PWAs, but they are not aligned with Apple's business interests (or their vision of user interface, responsiveness, power efficiency, privacy, etc.) any more than Flash was in 2010.

This article isn't fully accurate. I just went to my Android phone, searched for a random thing with the Google search widget and the links I clicked on all opened in the default browser (which for me is Firefox).

Mine doesn't. It opens a search result in an embedded browser, which claims to be "powered by Chrome" when you open the three-dot menu. (Android 8.1.0)

Hmm, perhaps its something that changed in more recent versions then. My phone has one of the Android 12 betas on it. I certainly do remember this being a thing though, but not in a while.

At some point might you have gone to Search > Settings > General and unchecked "open web pages in the app"? Pretty sure that setting is on by default.

The Google app uses Chrome Custom Tabs, which allows the calling application to filter the browser implementation by application ID. The documentation encourages this by showing how to limit to the various Chrome app IDs (stable, beta, canary, and dev). Naturally, the user-respecting action is to try a CCT request with the default browser and fall back to known app IDs, but Google themselves don't do this and don't show how to do it in their documentation.

IMO it is absolutely inexcusable that a device I paid for, does not let me run the software I want to. Lack of browser engine diversity is but a small symptom of that larger root problem. The owner/user must have final authority to run, use it as they like.

If the market is failing to ensure this for the vast majority of the phones and tablets sold, the state must intervene. This is classic monopoly abuse.

You don't own your device, you are just licensing it.

When you pay for a device you are only paying a license to use the device, since you need a firmware to run the device and the firmware is licensed to you without any ownership transfer.

Your device does what the firmware allow it to do, therefore you are only allowed to do what the real owner of the firmware wants you to do.

Well, you've paid, and that very moment everyone has stopped caring what you think.

This is one of those topics that I noticed the symptoms of but didn’t sit down to conceptualize and connect all of the dots. This article clearly ties together all the loose ends and even goes as far to offer potential solutions. A great write-up

Hot take: I know this is controversial, but I want to say it: Only developers and a few tech bloggers care about PWA.

I have never seen or heard of anyone using a PWA outside our little tech bubble in real life. Nor have there been instructions in the news or many clickbait YouTube videos about how to use PWAs on your phone or PC.

PWA is the label for “do things like an app in the browser”. Things like easy install on the homescreen, storing a lot of data locally, notifications, nfc, bluetooth, location and camera (in a user-friendly way), … This is something people definitely want to do, but can’t, and that’s why PWA remains stuck for a niche audience.

The main problem is mobile safari. It is such a limited environment that basically apps are impossible to do for real world use cases in the browser. So, by necessity, even though I was hired to work on the web platform for my organization, I’m now working on a native app.

Apple has handicapped the mobile browser to the point where you have to go native. It is even worse than the IE days, because back then you could make a single web app that supported all browsers. You could have a web-only strategy. This is no longer possible for most organizations.

I do think that for us developers PWAs are great. But for users, not so much IMO. Native apps (even the ones made with React Native or similar tech) are 99% of the time of higher quality than a web app.

That comes down to having more possibilities (even with every PWA feature implemented, there would still be so many missing), greater performance and battery efficiency.

As a developer I would love to see PWAs get more capabilities, but as a user I don't want my native apps to get replaced with PWAs to save on some money.

My thoughts are similar. It’s possible to make high quality, kinda-native-feeling PWAs, but that definitely doesn’t come for “free”. In fact it takes a level of attention to detail and craftsmanship that frankly few developers seem willing or capable of, whether that’s due to indifference on behalf of the developer or management riding their ass pushing them to ship sooner.

So the most likely outcome is that the average PWA would be less pleasant to use than the average app, which is a pretty clear cut loss for users.

A lot of users won't install a native app but will use your web app.

From a user POV: Installing a native app is a decision. The native app capabilities let it do shady stuff with ads and exfiltrating your PII, might eat your battery, spam you with with notifications, and in case you forget to uninstall an annoying app it's a fail-open situation where it can keep on doing all this stuff in the background unless some day you remember to uninstall it. Browser ad blockers don't work on them. The app only works on your phone and with someprobability a web version doesn't exist, so it's a piece of tech that is inaccessible using a real computer, with a real screen and keyboard etc.

its still just an assumption that pwa success is blocked behind some chicken and egg problem. i dont think you can say it is “definitely” something people (lots of them) want. as of right now it looks like the people who want it most are giant platforms like Google, Amazon and Facebook who want to build game platforms that circumvent in app purchases. thats a valid reason and if its meant to broaden it will. these companies are worth trillions after all

> Things like easy install on the homescreen, storing a lot of data locally, notifications, nfc, bluetooth, location and camera

> The main problem is mobile safari.

Ah yes. "The problem". And not the fact that a lot of what you want is badly specified, poorly implemented and considered harmful by both Safari and Firefox: https://webapicontroversy.com/

Modern PWAs are inferior to products compared built with more traditional means.

Show me a traditional App Store app that doesn’t pay 30% of IAP to Apple.

Easy, any app that is making less than a million a year, or any app where people have been subscribed for over a year. They pay 15%. Also you didn't specify the app even had to be paid, so any free app counts too.

This was only true a couple months ago and required a them to be sued by Epic (and a general "trust busting" attitude from the new admin) for them to drop it. They didn't do it out of the goodness of their hearts.

Well, Tim Cook testified under oath that they had been doing the change to 15% for under $1M before the actual Epic Games lawsuit was filed, and that it had been in the works for over a year. And Biden had not been elected yet, even when they rolled out the 15% change Biden still wasn't President.

Unless you actually believe that Tim Cook committed perjury.

>Unless you actually believe that Tim Cook committed perjury.

One. He knows there are no way to prove him wrong. Just like many other things he had said during Apple vs Qualcomm and Apple vs IMG. When there are ample of evidence his word are either lying by omission or a spin on a word's definition.

Two, AFAIK, he didn't said "they had been doing the change to 15% for under $1M before the actual Epic Games lawsuit was filed, and that it had been in the works for over a year."

He said and I quote "probably has its origins several years ago". They could trace that back as Phil Schiller's letter to Tim Cook on App Store if it needs to be.

Listen to yourself. “Under the works.” Dude, c’mon of course it was the lawsuits.

Wouldn’t be the first time he’s done it, for this very topic in fact n

PWAs are just mobile Web sites and they are doing just fine, regardless on how someone feels like calling them.

99% of applications don't need to be an app, a Web page with some fancy data form and data presentation widgets is all that is needed.

Best of all, I don't need to deal with the mess that Android development has turned into.

IMHO, Apple should be sued for Antitrust here, but somehow they are America's darling and can get away with everything.

Except of course they are being sued right now......

I still can’t believe Apple gets away with their browser rules on iOS. Yes you can have default browsers now, but they are still built on what Apple says so.

This is made all the worse by the embarrassing bugs in Safari. Apple broke IndexedDB in the current stable Safari and isn't in any rush to fix it (see https://news.ycombinator.com/item?id=27509206). Safari updates are so infrequent that developers will have to include workarounds to this issue for years.

It's been fixed on master for over a month, but it hasn't been included in any of the Safari releases that have come out since then. When someone asked the Webkit engineers when we can expect a fix, their response was "Apple does not comment on future releases." https://bugs.webkit.org/show_bug.cgi?id=226547

If I asked you to imagine what you could do to sabotage the web, it would not look very different than what Apple is currently doing. Add "support" for modern web features but then actually subtly (or not so subtly in this case) break them on a regular cadence. To be clear, I don't think the Webkit team is doing this on purpose, but the effects on the web are still the same.

Perhaps it's because, to the user and the government, the "chrome" around the browser (bookmarks, experience, branding) is more important than the engineering details underneath, which most users don't care about. And governments, seeing other browsers are allowed but they have to use some similar plumbing, don't really care as the branding and sync and all that is different.

To them, it's the same reason why Apple might say you have to use the system Button instead of making your own Button, or use the system way of handling Graphics instead of making your own way of handling Graphics, use the system WebKit instead of rolling your own WebKit. That's a harder nut to define.

I honestly don't think more than 5% of users give a rip on what their browser internals are, if not less.

If we are going by that analogy, to governments the “chrome” is important when the “pipes” underneath are a common resource it regulates.

I don’t think govs regulating the implementation of anything in the OS is a good idea, but we could at least expect some wrist snapping to unlock the situation.

Has someone perhaps tried making a browser on iOS while sandboxed (aka. without JIT, and only sideloadable of course)? My understanding is that interpreted JS execution has abysmal performance and battery life characteristics, and given that Apple only entrusts themselves to run arbitrary code (since third-parties could just RCE themselves any bypass app store review otherwise) they can't allow other browser engines to use the JIT entitlement - it would look like they were intentionally handicapping the performance of other browsers.

The restrictions on JIT aside, my understanding is that there's also a separate rule that you can't have any web browser engine except the system version of WebKit.

Well, yes, but i'm trying to make a case for why Apple would want to prevent other browser at all - that being how it would look like Apple is intentionally handicapping other browsers by not letting them use JIT, raising less-explainable antitrust concerns.

One explanation could be that Apple doesn't want an "electron situation," where every app comes with it's own fully-loaded web browser, is a memory and CPU hog, and a security risk if the app is out of date. Like is currently happening on PCs.

With WebKit, its update once, secure all apps everywhere.

I'm curious if FirefoxOS had gone differently if Apple and others would've considered supporting a native-web approach for apps. (Albeit also tied to only one or a few blessed HTML and JS engines.)

That was the Apple party line when the iPhone was first released – the only Apple-blessed way to build iPhone applications was to build mobile-friendly web applications. There was a backlash – everybody complained and demanded native applications; the App Store was opened the year after.

https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...

IIRC FirefoxOS did it differently. Apps were local bundles of web tech. Not only pinned links to open a browser.

Apple was in critically bad place when windows dominated with Internet Explorer, and Adobe with its apps. These two companies dictated where the users would be, and Apple had to beg them to play nice.

The iPhone was a whole new platform where Apple had 100% power on where it could go; opening the door to third party browsers to bring their domination to the platform from the start must have been seen as suicidal.

Another explanation, less popular, is that Apple restricting to WebKit actually helps foster browser competition at the moment.

Let me explain. Right now it's WebKit vs Blink (Chrome and all Chromium-based Browsers, including Brave, Vivaldi, Opera, Edge, etc.). If Blink were to be allowed on iPhones... you'd see Chrome become even more dominant. Firefox is dying on PC, has less than 1% mobile share, and is no competition in this case.

Requiring WebKit is what prevents an even greater Chrome monoculture.

It is totally about preventing alternatives to the App Store.

That's the rule, but you have to wonder why. They don't get more money just because Google can't spend their own development resources on targeting and validating Blink/V8 for iOS.

90% of the revenue is games. Mobile Chrome would only need to support idiosyncratic Unity and Unreal web targets for a significant chunk of that revenue.

You can decouple the browser engine from JS, e.g. use Apple JS core with Chromium/blink

There are a lot of poor arguments made in the article:

1. WebViews have existed since Windows 98, and they are not meant for embedding third party web content but for rendering first party web content.

There is a lot of web content rendered in WebViews which has not been vetted to run outside of them. There are also frameworks like Cordova which surface native capabilities through extensions. They can do this because portions of the WebView run in-process.

To provide user choice here would both break a significant portion of these apps and would result in third party code being injected into your application. It is simply untenable as a position.

On the other hand, the stores _already_ have policies about apps using WebViews to render third party content. Witness the recent article about FakeSpot being removed from Apple's App Store due to complaints by Amazon. A far more appropriate (if still very aggressive) restriction would be around web views being limited to first party content - content included in the application, or marked as being renderable within a particular application's Web View.

2. More calling out for Apple not being aggressive for PWA technology. In this case, there is a linked list of features that were 2-5 years delayed - but not to any standard release. Thats the delay from when Chromium shipped the feature.

Chrome has a very different perspective on Web technologies from Chrome OS, which sought to have no native applications and to have web technologies be the only way to use the laptop or tablet. While they since have backed off on this approach by allowing for running Android applications, this meant for a long time that lack of a "WebUSB" API would also mean these laptops effectively did not have support for any USB devices beyond what the underlying OS included.

It is also worth noting that when people bash Apple for not shipping technologies like WebMIDI aggressively as Chrome, they also leave off that neither Firefox nor IE shipped the features (until recently, when IE became a chromium vender fork). They also leave off how many of these "Chrome Specials" are not tracked to become standards.

3. Even if Apple deleted the one line about not including a third party web rendering engine in submitted apps, I would imagine substantial additional changes would be needed before a Chrome or Firefox was willing to invest in porting their rendering engine over.

The iOS security environment is based on a sandboxed model with distribution-time grants of static entitlements and user-granted dynamic entitlements. Trying to become the system default browser for something like PWA would involve getting apple to create and grant entirely new entitlements, such as "write and execute arbitrary binary code" (for a Javascript JIT), or "modify home screen" (to install a PWA as an application icon). Even support for the chrome execution model (multiple rendering and background tabs to isolate individual sites) is not fully available on iOS.

Hardly impossible, but it would take a lot of work by all parties. It would also mean that third party browsers look less like a tweak to app review and more like long-term strategic partnerships.

Actually, even IE3 on Windows 95 supports the OLE embedding method, and you can build a "framed web view" browser.

What was the Magisk module called, that allows us to change the engine of IAB on Android?

Oh and my default action on all IAB windows is: top right menu > Open in... > Vivaldi

I saw a lot of comments arguing about technical requirements, but companies like Google, Apple, Facebook, and others, don't do what they do because technical requirements. They do because they want control. More control they have over the platform people are using, more money they can extract from them.

Facebook is literally controlling majority of social media and controlling your data! Apple is right in this issue

This is an inane comment. The author Alex Russell speaks for himself not his employer. He's always been outspoken on Twitter and he spends much of the article criticizing Google, the place he worked at for over 12 years.

well it seemed a bit funny that he used to bash apple while he worked at google and now that he works at microsoft he bashes both apple and google. in all cases he leaves his current employer out of the criticism.

I guess that he joined Google because he is pissed with Apple and joined Microsoft because he is pissed with Google as well.

Maybe the next step is to create a startup and bash all incumbents

Yes, he's very outspoken on Twitter where he twists reality to suit his own worldview (which is almost invariably "Safari bad, put Chrome on iOS") and he completely ignores the realities that are:

- So many APIs he raves about are considered harmful by both Safari and Firefox: https://webapicontroversy.com/

- Chrome is blatantly ignoring all input and forces poorly specified internal Chrome APIs onto the world under the guise of "standards"

But sure. "He's outspoken on Twitter" should really absolve him and any criticism of what he writes is "inane".

I don't typically agree with Russle on most things, but Safari is in fact bad.

Safari is, in fact, fine. The "Safari bad" argument comes from people who are keen on turning the Web into something it can never be: an app platform.

I very very very much prefer the "bad Safari" to the shiny Chrome which pushes (and ships) "standards" so bad other browser developers can't even understand them [1]

[1] https://github.com/mozilla/standards-positions/issues/459

Edit: grammar and typos