Not hardly. It's rock solid and has extensive support for the latest standards. What you might want to do is go under the Developer Experimental features and explore.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Web Developers Form Advocacy Group to Allow Other Browser Engines on iOS
- Thread starter MacRumors
- Start date
- Sort by reaction score
The flipside of the security coin is that when WebKit has zero-day vulnerabilities (which has happened multiple times in the past year or so) all browsers on iOS are impacted. There’s no option to use an alternative, non-WebKit browser that isn’t impacted by the vulnerability pending a fix.
Yeah.... except that Safari is not the majority browser market share like IE was. That one is Chrome.
Having to support Chrome(ium), Firefox and Safari is an absolute picnic relative to the bad old days of IE6 and earlier - especially considering how much more complex web pages/apps are today (and the extra challenge of supporting desktop/laptops, touchscreen tablets and tiny mobile screens). That said, Safari - especially mobile Safari - is lacking on some features, esp. more bleeding-edge ones, and it *is* rapidly becoming the more troublesome of the three to support. It's nothing like the royal pain that was IE6, though.
Look at the usage stats: (That may not be the best stats site, but it's hardly making extraordinary claims) Across all platforms, Chrome is dominant, Safari is a poor second, but still significant and the rest are minnows (esp. as most of them apart from Firefox are either Chromium or Webkit under the hood). I wouldn't bet against Edge in the future, but again, that's basically Chromium, so it comes down to whether you want MS or Google to harvest your data.
Tablets - (where no one really competes with iPad) are a bit different - mostly split between Chrome & Safari, with "Android" (i.e. Chromium) a distant third, and nothing else worth mentioning.
In either case, the effect of allowing competition with Safari on iOS will simply be to hand even more domination to Chrome, which is what punters are choosing in droves on the platforms that do offer a choice.
Also, I suspect some of Safari's deficiencies are "strategic" choices by Apple to limit the power of webapps - allowing Chromium browsers (and, maybe, Electron apps) could be a disincentive for developers to write "proper" native Apps - especially in the case of the iPad: part of iPad's advantage over cheap Android tablets is the availability of native Apps optimised for tablet use.
So, if you make the OS and exclusively make the hardware for it, you can be more controlling or restricting but if you only make the OS, it's a different story? Sounds like Apple found the "loophole" and is attempting to use it to their advantage as much as possible.
The difference is Apple owns the device. The problem with engines like chrome is they require installing server like elements that communicates data.
A non-issue for 99.9999999999999999999999999999999...% of iOS users. They use Safari and are happy with it. End users do not want complexity and they never had. It all goes back to developers biting the hand that feeds them and not realizing if iOS does not do what you want just move over to Android.
Not sure what any of that has to do with browser engines???
As for privacy, apple wants its users to choose what they share. Google / fb etc would rather you couldn’t choose.
That’s all it is.
Key word here being “allow”. You’ve just admitted that the only reason Safari/WebKit is so dominant is because that’s all they allow on iOS. Let the best browsers win based on merit. I might agree with you if iPhones weren’t the #1 phone in the world, but you’re basically advocating against what’s in the best interest of the consumer.
Apple doesn’t feed web devs. They feed native iOS devs.
The issue is that Webkit and Safari are tied to the OS version on Iphones. If Apple wants to apply a "Patch", it has to be through an OS update. This is not standard practice for any other browser (or even other apps on IOS). This is why the bug in question stayed open for so long, because Apple waited until their next OS update to include the fix.
This is routine for Apple, vulnerabilities in Webkit are found, they stay open for rampant abuse until the next OS update. Compared to other browser code-bases such as Chromium or Gecko (Chrome and Firefox). Chrome has a a standard 4 week release cycle that often include patches for non-public exploits, and they have the ability to quickly push a public Patch in the case that a severe vulnerability pops up. This is the basis of the argument that Safari/Webkit's security practices are no more secure than other browsers and are therefore an unjustifiable basis for excluding other browsers.
Secondly, Facebook uses the In-App browser currently to do exactly what you despise, track you. They have access to every page you visit from their apps, they can inject javascript to interact with on-page resources (even correlating Ad ids of different companies with your FB account). The current status quo does not protect you from these dangers, only obfuscates them.
If you're truly invested in fighting these bad practices, I suggest you actually track down the group and help out. One of the other initiatives is about removing the elevated permissions available to In-App browsers Spefically for the reasons above.
So then, why not just develop a native iOS app?
Downside to allowing apps to use third-party browser engines would be that apps on iOS could be built using Electron, rather than using native iOS APIs. Can't speak for everyone but I wouldn't say having a bunch of electron-based apps on my iOS device like I have on my Mac now would be much of an improvement to the native experience App Store apps are currently forced to offer. Electron apps are memory hogs and often have poor UX.
This is of course exactly why most web developers want Apple to stop blocking other browser engines, so they can do the lazy thing and develop electron-based apps to quickly deploy to different types of systems. But in the interest of the users, I hope Apple keeps blocking this development on iOS. Natively coded apps are more than worth being locked to the WebKit browser engine on iPhone for me.
First, Electron is not mobile compatible. You might be referring to Web-Skin-Apps that are built on top of things like Apache Cordova. Second, these apps already exist and are in the App Store right now. Apple's stance here has not prevented the outcome you despise, nor have you noticed.
Electron does not run on mobile. Apps built on web technology already exist on IOS, make of a non-trivial percentage of Apps in the App store, and you have not noticed.
You might start by actually reading the document outlined. You would have found the page discussing APIs that are ONLY buggy/ incomplete/ or missing on IOS.
On macOS the ability to install alternate engines has also allowed for the proliferation of garbage like Electron to the detriment of native apps. There are trade-offs both ways.
Is incredible how many fall for this OBVIOUS trap.
The moment chromium can enter iOS, is the end of REAL alternatives to browser engines:
chromium IS google
IS the dominant player
IS ad-business friendly
Is safari the only major alternative (the other, firefox is doing not well today). MS was the other and it allow itself to be defeated.
Having ONE SINGLE COMPANY dominates ALL THE MARKETS...
think deeply about this.
The moment chromium can enter iOS, is the end of REAL alternatives to browser engines:
chromium IS google
IS the dominant player
IS ad-business friendly
Is safari the only major alternative (the other, firefox is doing not well today). MS was the other and it allow itself to be defeated.
Having ONE SINGLE COMPANY dominates ALL THE MARKETS...
think deeply about this.
While Webkit is open source and can be contributed to by anyone (and often is by community members and Google employees), Apple has final say in what pull requests make it into each release. Sometimes they simply ignore an issue, or in this case, the "Patch" was in the webkit code-base in only a few days. The delay came about because of Apple's release schedule. See, unlike other Apps on IOS, Webkit and Safari are tied to the OS version. When Apple wants to update Webkit, it has to push a Full OS upgrade. This often manifests as delayed patches and open exploits as Apple doesn't push patch versions of the OS (except on very specific, ultra-high severity this could bankrupt us exploits). They bundle the fix with the next minor release, which is ready whenever it is ready.
Other browsers (on non-ios devices) have standard release cycles where they patch vulnerabilities that they know about that are non-public, and they have the ability to push an emergency patch version in the event that a critical vulnerability rears it's head.
So the short answer to your question is, people DO contribute code and bug fixes, but it doesn't matter when the fixes get in the code base, it matters when Apple gets around to pushing an OS Update.
People have, and you're unfortunately incorrect. MS for example uses the Chromium project as it's base for the Edge browser (as you mentioned). However, what you failed to mention is that Edge HAS the up to date tracking prevention you lambast Chrome for lacking (which is understandable). Versions of Chromium have distinct differences that allow them to compete with one another. The most privacy conscious browser by most Metrics (Brave) is built on Chromium. Opening up IOS wont automatically squash Safari. It will compete with the other browsers on an even playing field, to gain and lose market share according to it's users' preference.
Second, we do not justify one companies anti-competitive behavior because another company is being anti-competitive. We go after both. The Open Web Advocacy group has other initiatives aimed at protecting user privacy and consumer choice (such as replacing In-App browsers with Remote Tab functionality instead to avoid the hosting app from having elevated permissions to inspect, record, and ultimately track whatever content you view through the in-app browser. FB on IOS uses this method right now to track what IOS users visit from FB apps and even correlate third party Ad ids with your FB account).