Hobson's Browser: How Apple, Facebook and Google broke the mobile browser market
infrequently.org
infrequently.org
(Disclosure: I work at Google, speaking only for myself.)
There's no option in Google maps to do this.
Otherwise the history is lost, among other things.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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/
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.
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.
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.
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.
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.
With WebKit, its update once, secure all apps everywhere.
https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
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.
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.
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.
Oh and my default action on all IAB windows is: top right menu > Open in... > Vivaldi