Its a shame Apple gets away with stifling browser competition and forcing everyone to use Webkit.
Of course it's a brilliant move: by controlling the stagnation of web browser tech, they can force developers to implement apps with their high-lock-in native app frameworks.
Google does the same thing with Android, but it is not nearly as blatant as Apple's flat-out blocking competitive browser implementations.
It's tempting to be cynical but there are good reasons for this. The main good reason is power efficiency. As the seller of the device Apple is the chief party held accountable for poor battery life. You or I or other technical folk might point the finger at particular apps but the typical consumer will just bemoan the "poor battery life on my phone". Apple takes ownership of that outcome and if that means forcing it to be a priority for all browsers, so be it. It's what lets them advertise the battery life for web browsing that they do.
Additionally, I would like to challenge the unsupported notion that WebKit is "stagnation of web browser tech". While there may be issues here and there, my impression is that Apple is overall committed to pushing the envelope[1] and adding compelling features.[2]
This makes zero sense. You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise. But for some reason Apple needs to limit the special case of apps that are browsers?
I think the most charitable explanation possible is that Apple doesn't want any kind of "open with..." choice ala Android Intents because they aren't very usable. For the same reason they don't allow you to set the maps application or the phone application.
As a person who has done a lot of platform design, I can definitely relate to that desire. OTOH, as a user who prefers Chrome and Google Maps, it drives me crazy that the default is always to open Safari and Apple Maps.
> You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise.
The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient. And they're willing to ship later to achieve it. I mentioned WebKit. A more obvious example of this is their approach to multitasking. Android let apps do more or less whatever they wanted and they supported multitasking first. Apple waited until iOS 4, but the more structured and regulated set of APIs they came out with was much more battery friendly.
> I think the most charitable explanation possible is that Apple doesn't want any kind of "open with..." choice
Yet iOS 8 added a bunch of extension APIs.[1] You can literally open content in other apps via the system share dialog, including third party mapping and voip apps. The stated reasons for waiting until iOS 8 were that they needed to do a bunch of architectural work first.[2]
Your argument is still not making much sense. I don't see how the power efficiency of the APIs is relevant. The point is that they currently allow tons of applications (E.g. Candy Crush) that drains the battery. What's the reason for making the browser a special case? It's just rendering to the screen like any other application.
One argument I could see being made is that the browser is used more than others and thus warrants tighter control. But even that is weak. People are draining their batteries all day long playing games as it is.
I believe that the real reason is that Webkit needs privileged APIs and unique executable memory regions for the jit. Giving third-party developers that access would make jailbreaking a simpler process.
> The key phrase being "within the limitation of the platform." Apple's been pretty consistent in designing (and limiting) key developer APIs to be power efficient.
Which I applaud. But those APIs constrain all applications equally.
So if Apple allowed browser applications to include their own rendering engines, their APIs would naturally constrain those applications too.
Now it could be that Apple does not want to enable applications other than WebKit access to APIs that would allow jit compilation. OK, that is reasonable. But in that case, why not allow browsers to provide their own rendering engine but just mandate that only JSC is allowed to run JS?
Or why not just say that only Apple apps can jit and let the market figure it out?
(I'm going to drop the thing about 'open with...' because it was a distraction and ancillary to my main point, which is that Apple is doing this because they want to control progress of the web platform on iOS)
>This makes zero sense. You can install 3rd party apps that can do whatever they want (within the limitations of the platform) power-wise. But for some reason Apple needs to limit the special case of apps that are browsers?
This objection makes zero sense. You cannot install any 3rd party app, just those that got approved. And a power hog or whatever app can always be de-approved.
Yep. I hear "we can't do anything about it" all the time. Politics, economics, demographics. But the thing is, people have a voting bulletin they can use every day, the bank note, and that is always listen to. And they don't use it to vote.
Facebook is very privileged by Apple, for instance see React Native which somehow is allowed to circumvent the usual "no download of code". It's the exception that proves the rule.
They could de-approve browsers if they were inefficient too. Webkit on iOS is extremely conservative in terms of energy use, but it does not make it impossible to create a webapp that would drain your battery.
Um, no. Just look at sites like caniuse.com and see how much farther ahead Chrome and Firefox are than Safari iOS. Safari iOS has become this generations IE 6. It is seriously holding back the web. And worst of all it really only gets one update a year!
[1] is not good article, no test, no numbers.
[2] neither is this. no info about the test other than the results. just knowing that chrome rendered flash by default at the time of this article, i know its irrelevant.
[3] claims 70%...
Anecdotally, Chrome uses dramatically more memory and CPU than Safari for me (note: I typically have 100+ tabs open at once), and gives me somewhere between half and two thirds the battery life, for the same type of use. I have flash turned off for both and most ads blocked via /etc/hosts, so there shouldn’t be anything especially unfair in the results.
Google web apps (gmail, google maps, etc.) seem to be a particular offender.
False. From [2]: "The native Safari made the new Retina machine look good: 13 hours and 18 minutes. Google’s Chrome, on the other hand, forced the laptop to tap out at 9 hours and 45 minutes."
It's not holding back the web, settle down! It can still render websites perfectly fine and will continue to do so.
Seriously, what horse are you backing where iOS Safari is compared to IE6?!? What oh-so important feature you simply must-have, that would even begin to signify that iOS Safari is "holding back the web"?
The web dev world is absolutely mental at the moment...
I'd pay top $$$ if someone could show me how to let a mobile Safari user record audio on their microphone and submit it. iOS doesn't permit this in any way, whether it be with getUserMedia or media capture forms. The only way to do audio recording is to build an iOS app just so I can get this one simple feature which is exactly what they want. Repeat this story for a dozen other features as well.
Apple's total opaqueness on what their plans are for the future functionality of their browser certainly doesn't help either.
I tried to circumvent it a while ago when I was playing with the Web Audio API by allowing an iOS user to "upload" a video, from which I would then extract the audio using decodeAudioData. Unfortunately it returned an error on callback in iOS.
Perhaps it could still work by processing said video on the server and sending back the audio, but keeping everything client-side was my requirement.
Web pages that can access the microphone sounds like an absolutely insane idea to me, but then like I said, web dev is absolutely mental at the moment...
I'm suggesting that the web is fine - its stupid nonsense like javascript access to the microphone that gives the illusion that the web is moving forward, and that some people are freaking out proclaiming the end of days because some ridiculous feature hasn't been implemented.
How is it ridiculous just because it's a feature you don't use?
There are plenty of uses for newer standards, that's why they're created, but it only works if the browsers carry their weight and implement them consistently. Safari doesnt, and is thus holding back the progress, just like IE6+ did.
I can see why that'd make someone cross, but it seems in line with how localstorage works + how browsers define their "private browsing" features. On Chrome, for example, when in Incognito mode, you can't undo-close-tab a tab after closing it. Effectively, every tab you open in these "private browsing" modes will sooner-or-later "self-destruct", including all its cookies, localstorage, etc. (iOS?) Safari just chooses "sooner" rather than "later."
If your site relies on using localstorage during the lifecycle of an individual page, you can always replace it with an in-memory mock polyfill if you notice it's missing. There's probably an NPM package for that.
The point of standards for browsers is that you shouldn't need a polyfill just to support a feature (localStorage) in one browser. Ideally, it would just destroy its contents after your private browsing session is done, just like the way (I believe) all browsers treat cookies in private browsing mode.
Sure, what I'm saying is more that localStorage doesn't have the standards equivalent of an SLA guaranteeing it'll work for the "within the lifecycle of one page" use-case. Apple, I think, are just being opinionated (and pushy) here: they think the right way to tell a web-app "your localStorage won't save" is to undefine the API, making trying to write to or read from localStorage raise an exception, so that your app is then forced to decide whether it can go on without localStorage (by handling the exception, or by using a polyfill which does the same) or that it can't (by just telling the user "don't use this page in Private Browsing mode, doofus!" and stalling out.)
It's certainly not the approach everyone would be happy with, but it allows developers much more flexibility than the contrary case, where private browsing is a silent effect that might make apps do very stupid things (like, say, downloading the same huge asset bundle into localStorage over and over.)
> downloading the same huge asset bundle into localStorage
This would happen anyway no matter what storage or cache is used since all data is cleared after private browsing session is over.
Breaking localstorage (with an over-quota error) is not the way to deal with this. Polyfills are just more crap in complexity and downloaded bytes to compensate for a browser's issues.
It would be much better to have a navigator.isPrivate flag enabled so apps can check the environment accurately, not guess based on whether certain APIs work or not. It's not about SLAs but supporting standards. Deleting client-side data is all that private browsing needs to do.
That doesn't follow. If it literally behaved like a normal browser that would break the privacy guarantee of private mode. In fact you could argue that browsers that implement localStorage in private mode are the ones who are not standards compliant.
From the Web Storage spec: "[localStorage] is designed for storage that spans multiple windows, and lasts beyond the current session."[1] Thus if a browser is discarding localStorage prior to the end of the current session, it's explicitly against the spec.
This is more than academic. If apps aren't written to explicitly use ephemeral storage then they may not function as expected in private mode, like, say, unexpectedly causing data loss.
Check http://caniuse.com/#compare=chrome+59,safari+TP yourself, and you see the differences in scores is mostly because they give 1 point to every API, however non-important it is. Meanwhile, Chrome supports some good ones (File Storage, WebRTC, Pointer Events etc), but Safari supports some good ones that Chrome doesn't too: MathML, HTTP Live Streaming, Video and Audio Tracks, SVG fonts. But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats.
MathML has been dead for years. HTTP Live Streaming (HLS) is not part of the spec and never will be. What is part of the spec is MPEG-DASH. But, File Storage, WebRTC, and Pointer Events? Those are actually useful for modern web development.
"But Chrome also tries to push various proposals of (mainly) theirs, down everyone's throats."
Never experienced that with chrome, but I developed a kind of hate towards mozilla, for forcing IndexedDB and IndexedDB ONLY and refusing for anything else and therefore killing FileAPI and WebSQL
That's consistent with the parent comment. They're working on WebRTC.[1] Possibly they're making it power efficient first and then shipping, as opposed to shipping and then making it efficient.
Not sure if you're serious about 1 update per year...iOS has ~4 major releases per year. (9.0, 9.1, 9.2, 9.3). Safari receives updates in each one. iOS 10.3, which is in beta, comes with tons of Safari changes.
Uh, duh? That's because HLS is not a web standard and never will be so nobody else is going to bother building it into their browsers. The standard (ISO/IEC 23009-1:2012) way to do adaptive bitrate streaming is MPEG-DASH.
"Just as much" is a bit of an overstatement considering how primary web browsing is. I mentioned one reason: it's what lets them advertise the battery life for web browsing that they do. Web browsing is a distinctly primary use case for a wide range of people and a fundamental value proposition of the iPhone from day 1.
Another thing that makes browser engines special is that they can be used to build "native" apps. Apple famously banned Flash. But if they allowed you to use any old web engine they could run into the same problems with poorly optimized apps on their platform. So Apple's not just forcing other browsers to adhere to their efficiency-first priorities... it's forcing all apps.
They could easily stick a "* using Safari" on the battery life claims if it was about advertising.
Apps are free to be inefficient. You can use some horribly slow JavaScript engine and build all your code that way. You can use Python or Ruby. Another comment mentions that Cordova apps are allowed, so it doesn't seem like the WebKit requirement even applies when building "native" apps.
No one cares, no one reads asterisks. There often useful/important, but they might as will not be on boxes. Either that or they signal a lie. Like the old windows laptops that used to advertise great battery life is long as you didn't actually move the mouse or do anything and had the display brightness at zero.
The other commenters are right. If people bought an iPhone, downloaded Chrome (the REAL Chrome), and use their phone and got six hours of battery life who do you think will get blamed? Apple.
People here all sorts of stories about how Apple doesn't have good battery life in the use chrome on their computer and it doesn't cause their computer to have five hours of battery life (even though Chrome is a known battery hog) so it must be Apple's fault. Blame the $900 phone.
For battery reasons alone I completely understand Apple's decision. There are plenty of other issues, such as keeping things updated with the latest iOS API is that are needed by the default browser, although some of that could be worked around with large third parties like Google.
I know they were missing features the people are absolutely clamoring for here on HN, but every time I asked they never seem to be something that I care about. I don't really care about web RTC, I don't remember the last time I wanted to have a webpage record audio, the fact that local storage doesn't persist across private browsing tabs is a FEATURE to me.
I think this fits well with the other article that's currently on the front page. Lots of people here in another text sites trounced Apple for their computer updates this year, but normal users seem to be very happy with them. A lot of these positions seem to just be too far out of Main Street (and there are so many iPhone sold that mainstream is GIGANTIC).
And when they download Clash of Clans or whatever the hot new game is, and the battery lasts 90 minutes, Apple doesn't get the blame? If it was about ensuring battery life stayed high even when the user is clueless, they'd be doing more than they are.
> And when they download Clash of Clans or whatever the hot new game is, and the battery lasts 90 minutes, Apple doesn't get the blame?
Correct. If it lasted 90 minutes they would clearly attribute it to playing the game. If however a regular mix of typical daily activities gets low battery life, that's just the phone's fault.
But I would add that Apple has done a lot of work to make their game APIs power efficient. Metal is a perfect example of a more proprietary approach that achieved significant speed and battery life gains.
You're right, they have done a ton of work. Unfortunately, you can't make developers use it. So you find some games that don't seem to do too much but waste your battery, and others that are very impressive and barely touch it.
The only thing I can say is games are different. People seem to have a since the games can use a lot of power and be willing to accept that. And you're definitely not wrong, many of them are written terribly and destroy battery life unnecessarily.
But the other thing is it's obvious when I play a game. Where is I don't really think about using Safari, but I'm sure I use it dozens and dozens of times a day. So I'm very conscious of the fact that Pokémon go or whatever else I'm playing eats my battery, but all the little interactions with the web browser eating an extra 20% probably wouldn't raise a flag for me; I'd just think my phone's battery life got a lot worse.
Note: I see that "no one cares, no one reads asterisks" sounds really harsh, if anyone is taking issue with that, and wasn't aimed at the GP. I simply meant that people (including myself) don't tend to take them into account so I don't believe it's a good solution to the problem.
Allowing a custom web browser is different than allowing a system wide custom WebView... Since you can't currently do anything similar that's a weird complaint.
For example, I have Google Maps installed, but if I make an app and add an MKMapView it is the same old Apple Map it is everywhere.
In the case of Electron, the application is the webpage. Apple allows web apps built with Cordova on iOS, but warns that they may be rejected in the approval process if they run too slow.
I kind of doubt it. My understanding of the rule is Apple will not allow any alternate web renderer on their platform. You might be able to get away with the old opera mobile thing of having another server render the image and just serve the image on the phone, but no one wants to actually do that.
Sometimes it is wise to be cynical, especially when dealing with companies which pride themselves on their profit margins while keeping their users at a tight leash. Doing anything else is not only bad for your budget but also rather illogical, knowing that those profit margins depend on keeping users' noses pointing in the 'right' direction.
So, yes, there are good reasons for Apple being very determined over what you can, and more importantly can not do with Webview and Safari on iOS: they do not want iOS to become too good a host for web-based apps for fear that they might out-compete appstore-bought apps as Apple does not make a cent off the former. This is also why Apple does not allow other 'real' browsers on iOS as those could be used to circumvent these restrictions. That thing about power consumption goes just as much for other apps as it does for web browsers so it is rather easy to defeat that argument.
"stagnation of web browser tech": why do you think Blink became a thing in the first place? Also: Progressive Web Apps and Web Components are not fully there yet on Safari (WebUSB, WebMIDI, etc...Look it up). It is not in their interest to move App developers to the web and AFAIK, they didn't start moving again until too many made fun of them, calling Safari the new IE6.
Safari has one of the best Web Components implementations, with excellent Shadow DOM and Custom Elements compliant to the latest spec in the Safari 10.1 beta. These are the two most essential Web Components specs.
By comparison, Edge doesn't have either, and Firefox has no Shadow DOM and old out-of-spec Custom Elements.
How is it that Safari is holding the web back in this area?
(WebUSB and WebMIDI have nothing to do with Web Components, they are hardware-specific device APIs.)
All browsers have these sort of bugs. This is not unique to WebKit. All browsers have "quirks". All browsers have parts of standard APIs that they implement incompletely or slightly different. None of this is unique to WebKit.
I think it is really simple. I don't think it has anything to do with power efficiency. If anything resemble notable cause, then Apple simply wanted to be the sole API provider. Apple doesn't want Mozilla / Microsoft / Google / Opera etc implement their own browser engine and demand or even dictate Apple's iOS implementation roadmap. It's better off the have the full control of what developers can do on iOS.
> but the typical consumer will just bemoan the "poor battery life on my phone"
There's a quote:
"Make a system that even a fool can use, and only fools will use it."
Except it isn't true in this case. Which is unfortunate because developers should know better: supporting only a single brand is bad for competition, and will turn computing into a monoculture.
When Chrome stops trying to melt peoples computers, I'll give them more of a chance. It's been well known for years the chrome is very hard on battery life compared to Safari, and while they seem to be working on it they're still WAY behind. It doesn't seem to be a high priority for them (relative to new features), so I don't see why they even try.
It doesn't have to be Chrome. It could be Edge, Opera, Firefox or some other browser that's yet to be invented. Currently none of these will ever exist on iOS.
Forcing Webkit on errybody might be mainly a security thing. Also, depending on what counts as security, maybe Apple doesn't want analytics on everyone's web browsing experience sent to Google.
> You or I or other technical folk might point the finger at particular apps but the typical consumer will just bemoan the "poor battery life on my phone".
You don't give people a lot of credit for even minimal logic with that statement. I've dealt with a large number of low-tech users and every. single. one. of them has understood the relationship between battery life and the applications they run.
They also understand what having GPS, active WiFi and watching a couple of hours of video will do to their batteries. The only ones that have a problem with this are the ones that pay $800 for a device that struggles with normal 2-day usage because thin trumps mAh.
How so? They have no restrictions on web browser development. Firefox has been there and I use it as my daily driver. Since KitKat, Android System WebView has been an app on in the Play Store based on Chrome that gets updated regularly.
Not to mention that Android also lacks a lot of restrictions that iOS has, JIT code = no problem, mono for android has many more features than the iOS one for that reason. You also don't have to use Google Cloud Messaging, you can do your own push notifications via IMAP, XMPP, etc. (Assuming you and your users are okay with pushing an 'okay I'm willing to sacrifice some battery life for this' button). Mapping components that use OSM are freely available, etc.
Heck, you don't even have to use their phone app, you can install a SIP client. It's perfectly possible to use Android as it exists in AOSP without Google stuff at all. Some 3rd party apps may want to use things like Google Maps embedded, but there are projects that replace those and an Xposed module to fake the signatures to match. The Google-less Android system is really a decent experience if you're willing to put the work in to it.
> Assuming you and your users are okay with pushing an 'okay I'm willing to sacrifice some battery life for this' button
This is the fundamental difference in philosophies behind Android and iOS.
Apple likes to build their software (most of the time) like Python - its an opinionated platform that strives to make that best decisions for users. They've determined there's very little user benefit from having multiple push notification services, and they don't want to give users a way to shoot themselves in the foot by enabling such a setting that would impact battery life like that.
Many of Apple's decisions can be viewed through that lense.
> Apple likes to build their software (most of the time) like Python - its an opinionated platform that strives to make that best decisions for users.
I'd argue it's a platform that strives to make best decisions for Apple, and that's not the same thing as being opinionated.
Yes, there's an argument that there is very little user benefit from having multiple push notification services. But there's no inherent benefit to having Apple's service be the one-and-only service ever allowed to be used -- that's not an opinion, that's vendor lock-in.
There's an argument that there is benefit in not having multiple different web browsers on a user's phone. But there's no benefit to having Apple's webkit be the one-and-only web browser ever allowed on the phone -- that's not opinion, that's vendor lock-in.
There's nothing inherently wrong with a product holding strong opinions. But vendor lock-in is not the same thing as an opinion -- there is a clear difference between an opinionated product, and a monopolized one - https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....
> Yes, there's an argument that there is very little user benefit from having multiple push notification services. But there's no inherent benefit to having Apple's service be the one-and-only service ever allowed to be used -- that's not an opinion, that's vendor lock-in.
Let's suppose Apple were to open up their APIs to allow other services to send push notifications to their devices. Since they are no longer the intermediary they've given up control on how often a developer's servers are sending notifications via the third party, they've lost a control on throttling how often notifications are sent to devices. What happens if the push service or the developer's backend is compromised (or misconfigured) and attempts to send hundreds of push notifications per second to thousands of phones? Features could be added to the OS to help mitigate this but the phone must still service the incoming traffic. Strictly speaking, this isn't Apple's fault but this won't be a sufficient answer for their customers.
Which isn't even considering that they need to figure out a secure mechanism for allowing third parties to uniquely identify iPhones.
> There's an argument that there is benefit in not having multiple different web browsers on a user's phone. But there's no benefit to having Apple's webkit be the one-and-only web browser ever allowed on the phone -- that's not opinion, that's vendor lock-in.
What happens if Mozilla, Google, etc. release a new browser engine for iOS with all the latest whizz-bang HTML features but at the cost of doubling power consumption? Apple support needs to deal with the customers who suddenly see their battery life plummet when switching to a new browser. 99 customers out of 100 will blame Apple for this. What if a vulnerability allowing RCE is discovered in the JIT code included in the third party browser? Apple has lost control of the patching cycle and their only recourse would be to remotely remove the browsers from their customers' phones if the vendor does not update the app in an acceptable timeframe.
I feel like a lot of Apple's decisions around the iOS ecosystem can be explained by looking at the problems they had with customers running Adobe Flash on the Mac.
> What happens if Mozilla, Google, etc. release a new browser engine for iOS with all the latest whizz-bang HTML features but at the cost of doubling power consumption?
What if I use an email app or notes app or other app that consumes twice the power of Apple's inbuilt app?
I don't see what's special about a web browser. It's just another app.
> They've determined there's very little user benefit from having multiple push notification services, and they don't want to give users a way to shoot themselves in the foot by enabling such a setting that would impact battery life like that.
Well, I'm the user and I've determined that I'd rather not send private data through their servers, that I'd rather be able to do things like run a proper IMAP, XMPP, SSH or SIP client on my device without disconnections, etc. Those seem like pretty major use cases to me, ones which Apple shouldn't be making decisions for the user about.
If I ran an Apple device I couldn't use SIP and I'd be required to pay 4x as much for a phone plan rather than using a cheap data-only tablet plan for example. That seems prohibitive to say the least...
Yup. That's fine. Apple's made an opinionated decision (which IMHO probably suits the masses). If you want to make a different decision and don't want Apple to handle your notifications you can disable push notifications system wide, or switch to another platform.
This is of course ignoring that the user doesn't get much of a say in what push notification delivery mechanism is used - that's up to the developer.
But, to be honest, if you don't trust Apple to handle your push notifications then I doubt you would trust them to do much else, and you should choose another platform.
Most of the time my concern isn't with apps that have a dedicated service backing them, but with apps which don't. I don't want Apple notifying me when something changes on my SSH session because I sent my SSH credentials to some 3rd party server that notified Apple to notify me.
I trust absolutely no one to handle those credentials properly, I need my device to do it. And I need it to do it by interacting directly with the server.
Android solution: You own the server. Your server pushes directly to you.
iOS solution: No ability to maintain SSH connections, instead you need to get a 3rd party app to open an SSH connection for you and send you a push notification via an Apple service when a change occurs.
See the problem? Trusting Apple alone isn't an option - Apple doesn't offer a service to send you a push notification for your SSH session. You need to involve a 3rd party.
That's the way you see it, how about the way I see it?
iOS solution: everything goes through Apple, I generally trust them and know that they try to look out for me.
Android solution: every app goes through someone else's server, every app needs individual vetting because I have no idea what they're doing or how hard they're trying with their privacy. Where is the trying at all. That's the way you see it, how about the way I see it?
iOS solution: everything goes through Apple, I generally trust them and know that they try to look out for me.
Android solution: every app goes through someone else's server, every app needs individual vetting because I have no idea what they're doing or how hard they're trying with their privacy. Or if they're trying at all.
I like the iOS solution. You have it framed for my developer point of you, and I can understand that. But from your point of you, your solution has a lot of potential issues around privacy alone.
Apple looks out for their bottom line. If your interest happens to cross that path, bummer.
Don't just assume a commercial interest 'looks out for you' because they don't. If your needs, or at least your perceived needs (due to effective marketing) fit with a company's strategy you might get the idea that said company does it all for you and your fellow users. This does not imply any causality, the company just does what it thinks is best for its bottom line. As long as a company serves the needs of its users they are in a position to do well. Vendor lock-in serves companies in that they have more freedom to choose their own path without bothering all that much about whether that path coincides with their users' needs as those users face a steep cost if they choose to change vendor. As long as the company keeps the extra costs - in money, limited features or usability - lower than what it would cost a user to switch vendor they stand to gain from this strategy.
I mean, what he said is true. Look how many rogue apps on Android start spamming you with notifications and even worse, apps that push notifications that are purely advertising. Since I switched to iOS this hasn't happened once, and I'm prompted on first use of the app if I want to allow notifications or not.
You honestly believe that Google don't look out for their bottom line either?
You honestly believe that Google don't look out for their bottom line either?
I did not mention Google, nor any other company (other than Apple) for that matter. Instead I used the words 'a commercial interest' to indicate this goes for _any_ company which exists to make money - and that means nearly every company in existence.
But, to get back to your Google example, of course Google looks out for their bottom line. It just so happens that Google is not nearly as aggressive in herding their users into fenced corrals as Apple is. Google moves fast and often discontinues services so it is unwise to base your (company's) future on the existence of any specific Google service. Fortunately Google generally makes it easy to get data out of their services so a viable exit strategy is usually feasible. Apple is not that fast a mover which also implies they don't discontinue services at the rate at which Google does. Where Apple fails miserably is in their support for migrating data out of their services. This, again, fits the description I gave at the start of this sub-thread: Apple wants to raise the cost of leaving their services.
For the most part thought the Android solution matches the iOS solutions there though, devs use GCM. You're however missing the part where app devs have their own servers that have to talk to Apple or Google. You have to trust those 3rd parties too, all Apple or Google does is get notifications from their servers to your phone.
I'm not talking about general push notifications though, nor am I speaking as a developer. I'm speaking as a user, who also wants to connect to ssh, imap, xmpp and sip. The standard Apple/Google model is fine for most push notifications but absolutely not for things like this where a direct connection to a server is something that you as a user want.
That's the part I'm complaining about, not the general push message system, but the system of not being able to keep a persistent connection to a SIP or IMAP server without giving my credentials to a 3rd party so they can handle push and forward that off to Apple or Google.
> I'd rather be able to do things like run a proper IMAP, XMPP, SSH or SIP client on my device without disconnections, etc. Those seem like pretty major use cases to me, ones which Apple shouldn't be making decisions for the user about.
I learned recently that this isn't just a matter about the OS vendor making decisions, but that the OS vendors negotiate with the cell providers for longer timeouts:
"The advantage GCM has is that Google has made agreements with mobile carriers not to timeout connections on those networks. Without those, websocket connection idle timeouts on mobile data connections will be unpredictable, and they tend to be more trigger happy (and also often just silently close without sending an RST)."
So, if you want to run a proper IMAP (IDLE, I assume) or XMPP or anything client, you'll need to negotiate with your cell provider for better timeouts.
> So, if you want to run a proper IMAP (IDLE, I assume) or XMPP or anything client, you'll need to negotiate with your cell provider for better timeouts.
Or just send TCP keepalives and accept worse battery life. I still get enough to get me through a day with my phone almost never sleeping fully due to all the shit I have connected constantly.
Also, note that that comment is completely unsourced - I'm curious if there's any evidence backing that or it's just bunk. It wouldn't surprise me, but I also don't see any references to that anywhere else. Moxie is known to hate the 3rd party app stores and stuff, so it might just be him bullshitting about a possibility.
You can also push notifications to your device in an end-to-end encrypted manner. iOS 10 supports notification extensions so your private app extension can receive the encrypted payload, decrypt it, and then present a normal notification.
You're right. It does make apple more money. I don't even think it's a coincidence.
Because people could use whatever web browser they wanted and tons of people experienced 3-5 hour battery life, I imagine a lot of them would ditch iOS thinking that the iPhone was the problem.
And Apple would lose money.
There are some things Apple does that are very blatantly self-serving. I think there's are VERY reasonable explanations for this one (power usage and security being two).
> You also don't have to use Google Cloud Messaging
Unless you want Signal, which everyone (rightly) recommends. Finally off of almost every Google service, wanna install the latest and greatest encrypted chat app... too bad. But I recently heard Signal is finally working on it (after they closed my Github Issue as wontfix/by-design a year or two ago).
I'm running marshmallow and I use SIP constantly - is this fixed in CM? Because as far as I know I haven't had any issue here, could just be that my phone doesn't Doze for another reason though.
SIP works, but excepting a native app from Doze doesn’t. For example, if an app has its own push notification system, even if it is whitelisted, it will be terminated during doze.
EDIT: Yup, https://romhut.com/versions/cm-13-0-20160508-v8-0 indicates it's been in CM for a while, which is probably why I haven't experienced it. Dianne Hackborn fixed this as far back as November 2015, it might have made it into 6.0.1 on some devices too, though I could be misreading.
They forked Java by cherry picking features and APIs, and are making it increasingly difficult to write portable code across standard Java and Android Java.
Any Java library that depends on Java 7 or 8 standard libraries not available on Android, newly introduced JVM bytecodes, some of the Java 8 language features, annotation processors, ... isn't usable on Android.
Good luck getting Java 9 modules, or eventually Java 10 value types and updated generics when they become available.
Edit: I'm getting down-voted, presumably because people think web apps should have different capabilities than native apps. To those responding this way: why? I can't imagine why you'd prefer the locked-down app distribution channel of the Play Store, in comparison to the open web..
I think there's a distinction between an HTML App like those made with PhoneGap/Cordova and a Web Application like Gmail.com. And I personally don't think that's a bad thing to restrict most of those APIs from Web Applications. Do I want or need a webpage to be able to turn my Camera Flash on and off? Nope Nope Nope.
I think a lot of the newer APIs being exposed to the Web via the Browser are not very well thought out and will eventually be removed because of the risks they present.
Asking ignorantly here -- are you saying that those API's are accessible to Google Chrome and not to other browsers? That Google is playing in an unfair playing field?
are you saying that those API's are accessible to Google Chrome and not to other browsers
Those APIs are available to all Android apps, including other browsers. The only complaints I've heard are about Push-style APIs and power saving essentially forcing you to use Google Services.
Yeah that's actually a good point. There is no assurance that your App's Service component will remain active and GCM is the only way to reliably push to an Android device.
However you can write an App that persists in the App Tray as an icon that could maintain the App's Service component. The drawback there however is the persistent notification.
> The drawback there however is the persistent notification.
Well, the actual drawback is that you end up with over a dozen such notifications, your entire UI is full with them, and there’s no way to get rid of them, even if you developed the apps yourself.
Developers could band together, build one such app that does the communication part and forwards any incoming message to the right destination using intents. (ie what GCM does)
On the phone they could then look if GCM is around (and use it) or if that other notification app is around (and use it) or propose to install said app.
It's negligible in terms of user confusion because people on non-GCM systems likely know what they're getting into (except for those using Amazon Fire).
> ... by controlling the stagnation of web browser tech, they can force developers to implement apps with their high-lock-in native app frameworks.
This is really nonsense.
Native apps in general are testament to the UX failure that is Web standards and browsers. Think about the issues with CSS layout (e.g. Vertically centering) and (still) the relative poor performance of one page Web apps.
I heard someone else call native apps the new bookmarks. I think they're right. Think about the UX of a general purpose browser. You have to launch it then go to a site. That site's page is limited by the lowest common denominator of what a browser can do. It's also (at least) a two step process.
Native apps are generally task specific (e.g. Taking photos) or at least site specific (e.g. Facebook, instagram). This is much easier to use and understand.
That aside, Safari isn't what I'd call browser stagnation, certainly not to the degree Internet Explorer was back in the IE6 days.
What's more, Apple does a pretty good job of keeping users on the latest versions of iOS (compared to the likes of Samsung). The browser stagnation from OS version stagnation is far more damaging imho.
> Its a shame Apple gets away with stifling browser competition and forcing everyone to use Webkit.
It is.
There are also some simpler steps to start with though:
Apple could allow people to change the default browser on iOS. There are plenty alternatives to Safari. Let the people choose.
Apple could expose more WKWebView APIs so that browsers can actually do more interesting things and compete at a feature level. WKWebView is so extremely limited by Apple that the current iOS browser landscape is very boring.
You're right there a ton of things Safari does that others can't. So as you mentioned Apple would have to add all sorts of hooks to the OS and enhancements to the web view to allow people to use alternate brothers as the default even if they were still rendering with Safari internally, let alone some other engine.
Now would most users rather have the time spent on that, or improving Siri to give it more domains like the ones they added last year for third-party apps?
If the choice was between an improved Siri and the existing Chrome app as the default… Would that really be a smart trade off for their time?
( obviously Apple has the money to hire a lot more people, but let's face it that's not going to happen for this kind of thing)
Things are very simple: browser tech, Apple's or anyones else is light years behind the native frameworks and cannot even dream of catching up. Those who think otherwise most likely are not familiar with native SDKs.
BTW, there is competition for Webkit?
BTW, if not for Mobile Safari on the first iPhone we would probably weren't even talking about web apps as an alternative to native. Canvas, CSS transforms/animation and load of other stuff was first implemented by Apple on Mobile Safari.
> by controlling the stagnation of web browser tech, they can force
> developers to implement apps with their high-lock-in native app
> frameworks
Ah, web-developer logic. Always good for a laugh.
Yes, if Google were allowed to distribute their fork of the WebKit engine on iOS then everyone would stop writing iOS apps. Just like no one writes Android apps.
Most apps are not complicated enough to warrant their own native code. Like your Android example, there used to be a time when almost everything was written with Windows APIs. Of course, some apps will always demand native tech, but most of our desktop apps are now delivered with open and standard technologies, and they work on every device or OS with a browser.
I think the mobile world will follow soon. When it does, control of the industry will be released from the two major players, and consumers will benefit from increased competition, just like it has for desktop software. So yeah, web-developer logic can put a smile on everybody's face. :-)
>Of course it's a brilliant move: by controlling the stagnation of web browser tech, they can force developers to implement apps with their high-lock-in native app frameworks.
What "stagnation"? Semi-informed complaints aside whenever someone finds that their favorite desktop JS feature doesnt work on mobile, Webkit has been in the forefront of mobile web capabilities for ages.
Still better than Chrome on Android on several fronts. If it was just Chrome, we'd just have different unimplemented APIs and lower power efficiency.
And there's a much more obvious reason you don't want a competitor to have their own app platform on your platform. After some point they can be too powerful for your good -- the same way that continued support for Microsoft's Office or Adobe Photoshop was crucial for Mac OS/OS X success in the late nineties / early 00s.
Oh, and as somebody mentions elsewhere in this thread, how would an alternative browser implement GPU access (for WebGL APIs), or their JIT? They'd need to be given all kinds of first class access to the device which can be compromised or exploited.
I feel like this is a serious error in Apple's strategy. By enforcing stagnation you risk platform flight, namely Progressive Web AMPs (PWA + AMP) that load instantly (AMP - Accelerated Mobile Pages) and run and behave exactly like a native app (PWA - Progressive Web Apps) that removes all friction and user drop off associated with normal native apps.
I said it before but the #1 threat to all native app vendor is Google Chrome. As it's capabilities break through the native app turf, so will the smartphone user's demand for the most powerful and flexible browser on the market (Google Chrome) and the hardware associated with it (user perception is superficial influenced by marketing).
but yeah as long as celebrities go around with an iPhone, they are going to have that luxury brand tied with it.
Have you seen PWA in production? It is indistinguishable from the native app version. And it's only getting started since being announced last summer. Yes and PWA was indistinguishable for most run of the mill "me-too" native apps that comprises 99% of poorly installed apps on the market. It won't replace popular and dedicated native applications like FB messenger but for the vast majority of people still churning out native apps they are going to face further commoditization which will create a bizarre situation where native apps will result in drive past zero and towards the negative.
There's a reason vast majority of smartphone users install less than one or two apps throughout the year, web apps loading faster (sub second AMP pages) and native app experience (PWA offering add to home screen icons, offline mode, caching) will continue put pressure on the already falling and commoditized native app market.
How have you dreamt up "web apps loading" faster bit?
And if native experience for you is home screen icons, and offline mode… well, we don't have much to talk about here.
I've no idea I don't use it but if that's happening already than it's going to be hard to find justification for a native app moving forward. I was playing the devil's advocate.
AMP specifically disallows JavaScript, so how can AMP "run and behave like a normal app?"
Most of the capabilities of the web are used in a user-hostile way: to annoy, track, or drain the user's battery. PWAs will make the problem worse. AMP is a reaction against this.
AMP will load the PWA in the background. when they interact with the on screen items the PWA will take over. Hence, PWAMPs or Progressive Web AMPs.
as the mobile browser increases in capability it's inevitable we'll see more PWA as it is good enough if not better than native apps in every measurable way unless you absolutely need native app to utilize the full set of hardware on the device or big enough or successful enough that it will be used by millions of people everyday.
So you CAN build your own browser without WebKit, you just won't get any JIT-based Javascript running. There might be a way to directly call JavaScriptCore and bridge it with your web rendering code to use Apple's JIT.
> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
and also
> 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, macOS, or tvOS apps.
So you can't download and execute your own JavaScript, much less anything your user points your browser towards.
There's two cases that may be relevant: the US case and the EU case.
The US's case against Microsoft was that they leveraged a monopoly in one field (OSes) to gain market share in another (web browsers) through unfair licensing terms. Those terms were forcing OEMs like Dell to bundle IE and place it on the home screen.
I think the US case actually paints Google, not Apple, in a bad light. Apple does not license its software to OEMs, so there's no license terms that can be unfair. Indeed, if the point of the case is "OEMs should have more freedom and flexibility" - well, Apple IS the OEM.
But Google does license to OEMs under very strict terms. For example, if I am an OEM and I want to ship Google Maps or the Play Store, I must include all the apps Google asks me to, I must make Google the default search engine for everything, I must tell Google how many devices I sell, I can't sell any other devices with custom Android, etc. This is well beyond what Microsoft did, and is the basis of one of the EU's cases against Google.
The EU case against Microsoft is a little close to Apple, but only a little. Microsoft was accused of creating "disincentives for OEMs to ship third party streaming media players, and harms competition in the market for streaming media players." The concern there was that content providers would be forced to use Microsoft's proprietary media formats.
The analogy to Apple would be very strong if Mobile Safari had lots of proprietary features, like ActiveX. But instead Apple has gone the other way, e.g. by not including Flash. It does not appear that Apple is making a play to control the web through proprietary standards.
More that MS was using their marketshare in operating systems to get the upper hand on the competition in a related area (not sure if that area was web browsers or web servers though, as the whole intranet thing was going on back then).
Now if Apple made it real hard to play any content from ITMS outside of Apple products, that may be cause for concern. And they did get slapped on the wrist about ebook pricing.
There is more than one form of monopoly... horizontal (a single resource controlled by one entity) and vertical (a single entity renders significant control through an entire vertical.
Now, it can be argued that Apple has enough of a vertical stranglehold that anti-trust rules can apply. It doesn't have to be an absolute monopoly to violate anti-trust law.
Yeah, people get overly hung up on the monopoly term. Back when antitrust was formed, it was aimed at trust busting. Meaning that several big names of a market would come together and decide how the market would operate, rather than compete.
And i do believe Apple has gotten a slap or two on the wrist for abusing their hold on content distribution. Ebook pricing for instance.
This argument is often repeated, but I think it's a matter of perspective.
Were all servers, mainframes and dumb terminals counted too? Back in the nineties I'm sure those counted for something compared with PCs.
Apple has a complete monopoly on the iPhone / iPad market and that market is bigger than Microsoft's market in the 90s. You cannot change the OS without changing the hardware. You cannot change the browser without changing the OS. PCs and Windows never had such restrictions.
So what's the difference? If you answer that the PC was an open standard whereas the iPhone is Apple's own toy, I personally don't think that's fair, given that Microsoft too has built the PC market ;-)
> Apple has a complete monopoly on the iPhone / iPad market
?!? Of course they do, just like Nintendo has a monopoly on the 3DS market, and Porsche has a monopoly on the 911 market, but that's just tautological.
If you meant "Apple has a complete monopoly on the smartphone/tablet market" then a 3 second Google search will show you that this is completely false.
Your argument is illogical when you think about it.
Microsoft dominated the Personal Computing market. Apple is dominating the iOS market which is a subset of the Mobile Device market. I can buy a mobile device and experience the social and personal benefits from dozens of players.
And bringing it back to the point at hand. The reason Microsoft got in trouble is not because they had a monopoly. But because they used that monopoly to unfairly attempt to create another monopoly when a new competitor came into the market. Safari always shipped with iOS. There was never any competition to begin with.
Don't forget in the US that they basically dumped IE (in the economic sense) on the market where Netscape Navigator still cost money and had no possible way of competing for free.
Also at the time web browsers were still relatively new. Today basically every device and operating system comes with one, it's expected. No one ever complained that Microsoft with shipping calculator or solitaire.
To whatever degree there might be a case against Apple (which I don't really see) there are some pretty significant differences from the Microsoft case 20 years ago.
You can install other browsers on Chromebooks through the Play store, through Crouton, or by replacing Chrome OS with any OS you like. People generally don't because if they wanted to run other browsers they probably would have bought a non-Chromebook. But unlike Apple, Google gives you plenty of options.
There seems to be an argument here that runs something like this "I've bought a ticket into this walled garden and I don't like the walls, and why do we only get to eat apples?"
Yet, next door is a lovely (by all accounts) meadow where you are free to roam and even plant other fruit trees.
Apple's environment is a walled garden. They don't hide this - in fact they make a virtue of it. And the market is so competitive that there are plenty of viable non-Apple alternatives.
It's one thing to argue the merits or not of a walled garden as a business strategy. However most of the arguments being made here seem... petty?
Why do so many prefer the walled garden? Sure, many will easily dismiss them as "stupid" but this can't surely be the case. iPhone owners make up about 43% of smart phone users according to CNN (Take it for what you will).
I don't have an answer, but I think it's worth asking the question.
Because they produce amazing beautiful hardware that works well with its software, no difficult configuration needed, a best-in-class UX, a high bar for all of its apps to meet (so thus overall UX is quality), an integrated ecosystem, and a marketing machine that makes you feel good and obtain social status for owning it.
You say that as if that's some easy, cheap thing to achieve. Those words are also not concrete at all as to what they mean, exactly. All of these things are designed with purpose and are extremely difficult.
Maybe for YOU, but considering Apple just posted their most revenue ever last quarter, there are billions of reasons to disagree.
(Their products are also not _just_ sexy/trendy, clearly. They basically invented this entire category of modern smartphone despite many previous attempts by others.)
I've met many musicians who actually prefer Beats in the studio for recording. They argue that they don't care for sound quality that much, but they're much more comfortable on their head than any conventional studio monitots. Personally, I found that for DJing, I don't care about sound quality either - it's much more important to be able to quickly move headphones on and off and how comfortable are they on one ear.
Sound quality is not the only important quality headphones can have. Could the same be true for phones as well?
I'd first ask: do people actually prefer the walled garden?
In my opinion, the walled garden has very little impact on the day-to-day experience of most users. Partly, this is because the most popular apps were historically available on iOS first (and perhaps exclusively). More apps gives the impression of more freedom, not less.
This makes the walled garden a non-factor for most people, so purchasing decisions are made based on other qualities: design, hardware, user experience, app selection, familiarity with the platform, brand perception, ecosystem lock-in, etc.
I think that puts the question wrong, the question is actually 'what's the actual downside to the normal person of the walled garden?'
Mobile Safari and the App Store are still gold standards from everything I've seen. Go look at any browser benchmark you want -- Anandtech has a bunch of them in any review article -- and the iPhone running Mobile Safari runs circles around flagship Androids running Chrome (this includes Google's own Octane benchmark). Part of that is the hardware but (1) the magnitude of many benchmarks is larger than the single threaded advantage the hardware gets in say Geekbench and (2) hardware is another walled garden(!!); if the unwalled garden is so much better in theory, why in practice isn't there a single Android phone that can match the iphone in single threaded performance?
I'll tell you why: the ownership experience. I like a lot of things about Android, but the ownership experience is a key differentiator for me.
I've had Nexus phones and iPhones, and I like the software on both. But when I drop my iPhone and crack the screen, as I did several months ago, I can go to one of several Apple stores near me and get a replacement in about 15 minutes from polite, well-trained employees. That service also extends to OS and security updates for many years instead of just one or two.
The new Pixel phones cost more than $600, which puts them roughly in the iPhone price range. I certainly would not pay that much for something that is so important to my daily life if I had to ship it somewhere to get it repaired, possibly being without a phone for several days while I wait for it to come back. It won't run the latest OS after two years, either.
It's the same reason a lot of people buy Lexuses instead of Toyotas -- you are treated better when you need service, you get a nice loaner car instead of a ride home in a minivan shuttle, etc.
In general, as I've gotten older, I have learned that paying for service is just as important as paying for features. I sometimes buy things with features I don't really need in order to access the better service experience.
Since its a status symbol. I recently got a iPad. I initially thought the version was very old since UI looked dated(coming from Android M). Nope it was the latest version. I do not find the UX nor the UI better then Material design of Android. Fantastic hardware though, feels good to hold and has very good battery life.
Because they don't know what computers can and can't do, they never realize the wall is there. Computer course for kids and adults always teach how to write a letter and do a mail merge, not how to use a computer.
Actual walled gardens are very pleasant places to be. It is puzzling that detractors of a thing would analogize it to something that is so nice. Maybe telling? I don't know.
It's more like "I make binoculars, but so many of my potential buyers are in a walled garden that only allows them to see half as far as the rest of them".
My understanding is that the reason Chrome has to use the iOS webkit view is because that's the only way to get JIT javascript compilation working for apps submitted to the app store. Does anyone have a sense of whether it would be possible to switch to Blink and V8 with a locally compiled and sideloaded version of the app? Would there be any benefit?
You're not allowed to provide your own web render engine at all. The JIT issue was solved a couple versions of iOS ago - embedded webviews now get JIT just like Safari.
It's my understanding that only embedded WKWebViews are allowed to enable the JIT compiler, but not UIWebViews (or in-process JavaScriptCore engines). WKWebView is an out-of-process web browser that uses IOSurface [1] to project the image into your embedding application and IPC to send messages.
So WKWebView's dynamically generated code is running safely firewalled in a separate address space controlled by Apple and not accessible to your app, while older UIWebViews run in the address space of your application, and aren't allowed to write to code pages, so their JIT compiler is disabled.
Since it's running in another process, WkWebView's JavaScriptEngine lacks the ability to expose your own Objective C classes to JavaScript so they can be called directly [2], but it does include a less efficient way of adding script message handlers that call back to Objective C code via IPC [3].
> You're not allowed to provide your own web render engine at all.
Is that true? I understand the security argument against JITs, but I don't see why it would be objectionable to run a copy of e.g. Gecko if you excluded the JS JIT component. (Of course you would never actually do that. But I'm trying to tease apart the separate arguments and see if they're actually connected.)
It seems to me that the root cause for this is all the JIT. If the JIT in iOS has to be exposed via IPC for security (as claimed in a sibling comment) it's simply not going to be a win to try to use it in combination with a separate rendering engine, if it's even possible at all.
You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.
So you can maybe ship Gecko + SpiderMonkey, as long as you only run JS that's part of your app. But if you want to run JS from a website (or indeed any code from anywhere), you're not allowed to do that on iOS.
I haven't checked whether it would be OK to ship a browser engine that doesn't support JS at all, but that's a fairly academic question anyway.
But for example, could you ship Gecko with Apple's JS engine in a way that will satisfy Apple's requirements? Of course the answer is no, but it's worth taking a second to think about why that is.
I guess what's bothering me is that there is an unstated assumption underlying this entire discussion which people never bring up: for performance reasons, the rendering engine has to be tied closely to the JS implementation. Specifically, calling over some IPC interface at every entrypoint into the JS interpreter would be a performance nightmare. This is the reason why these can't be disentangled. The connection to the interpreter is really an indirect one.
> You're not allowed to ship a interpreter that interprets code that doesn't come from insider your app.
That is not true. Many apps do this. Games have been doing this for a decade. It is not a problem to do this. Apple has never made a big deal of that. Only if you are trying to build a shadow app store.
Apple does not care. As long as you are operating in the spirit of their App Store.
You know when they care? When you start charging money for those downloads. Via an alternative payment channel. Or when you run an alternative app store from within your app.
If you download assets on demand, and some of those turn out to be executable* code, nobody cares.
* Where executable means 'interpreted' because you cannot run unsigned code. But for games that is fine, they have been doing this with JS, Lua and Python for a decade.
(You can downvote me - but this is based on a decade of experience)
They do care; Apple has shut down (or restricted) several apps over the years that have tried this. But I ultimately agree with you, it's really more about how it's presented rather than how it works under the hood. This might have a lot to do with the review process.
The subject we're talking about here would not fly under their radar.
What you're saying is that Apple is inconsistent in enforcing its officially stated policy. That may be true, but does not change what the official policy is and that they can enforce it any time they want to.
See Microsoft CodePush and React Native for a counterexample: you can certainly publish apps which download code as long as they don't dramatically alter the functionality of the app.
Before iOS 9 (or something) that JIT engine wasn't even exposed in the web view available for apps, so no matter what you did, you couldn't match the performance of Safari.
On iOS browsers like Chrome and Firefox are basically unable to compete in terms of performance, web standards or features like browser plugins. So people that use them do so just to get sync. Of course Safari Mobile is decent nowadays, but that's not the issue.
Not outdated (it's always been the same WebKit version as used by Safari), but security restrictions on iOS (specifically, third-party iOS apps can't JIT-- the OS won't let apps without a specific entitlement execute from a writable section of memory) prevented in-app web views from using the same Javascript engine as Safari.
iOS 9 eliminated that performance penalty-- it introduced a new kind of web view backed by an out-of-process renderer and JS engine, which, since it's Apple-blessed, doesn't have the JIT restriction. Third-party browsers updated to use the new framework can get the same performance as Safari.
Third-party browsers updated to use the new framework can get the same performance as Safari.
But that framework is missing various things, such as content blocking. (That goes a long way to explain why there's both "Focus" and "Firefox" on iOS)
> But that framework is missing various things, such as content blocking
Not really - SFSafariViewController uses content blockers, autofill, etc. There's also WKWebView for those that want to implement their own content blockers and autofill engines.
Curious why you'd want safari's content blockers to run inside chrome or firefox though? That's not how browser plugins work anywhere else, and it seems like if content blockers were forced in to 3rd party browsers there'd be a lot more angst over that decision.
> Curious why you'd want safari's content blockers to run inside chrome or firefox though?
Because WKWebView has such a limited API that it currently is impossible to implement content blocking.
WKWebView is both a blessing and a curse for browsers like Chrome and Firefox.
A blessing because tt works really well inside that square area where content is rendered. It is as fast as Safari, as responsive to touch gestures, supports web APIs pretty well.
A curse because the API that it exposes is completely lacking. No way to intercept network requests, no way to interact with the DOM, no way to interact with JavaScript, no way to customize it fully, no way to do proper session store/restore, no way to interact with its internal caches, no way to set the cookie policy, no way to customize the context menus that it exposes, no way to handle errors better, no way to set headers on requests, no way to use content filters ..
I can go on for a while. You can look at the Chrome and Firefox source code to understand the crazy workaround both browsers had to do to get some pretty basic functionality.
Search for WKWebView on https://bugz.webkit.org to see what people have been asking for, for the past three years.
Not sure why this is downvoted because gcp is correct.
Apple has decided that Content Blocking is a Safari only feature. Apple has made the decision to not expose the private APIs in WKWebView that would allow browsers like Chrome and Firefox to use the same speedy content blocking.
The old WebView, UIWebView, also does not support content blocking. But since it runs completely in the same process as your app, you can replace the HTTP handling with your own and patch content blocking on top of that.
That is what Firefox Focus and Brave do for example. It works, but it is far from ideal. Also, it is likely an API on the way to be deprecated.
> Not really - SFSafariViewController uses content blockers, autofill, etc.
SFSafariViewController is useles for apps like Chrome and Firefox. It is an embedded Safari controller. Not an embedded generic webview controller.
SFSafariViewController has zero API. All it can do is display a webpage. Applications that use it have zero ability to even modify the UI.
That is intentional. It is supposed to be a Safari view. And for security reasons that is probabl good, otherwise it would be a gateway to your browsing data.
SFSafariViewController essentially IS safari. It isn't appropriate for a third-party browser.
While it is technically possible to use content blockers in WKWebView, it can only be done via private APIs, and Apple capriciously bans apps from their appstore that use private APIs.
No. You can't map executable pages in the sandbox. JITs (such as LuaJIT) only work while the debugger is attached (i.e., you open the app by clicking "run" in Xcode).
Opera Mini bypasses this restriction with doing Server Rendering. I wonder why Apple is ok with them (because it'a a big security risk to server render HTTPS IMHO).
And regarding your quesiton: I'm sure you cannot replace their webkit usage with one switch to Blink... I'm sure the iOS internal webview is deeply integrated/
How much is there even left for Chrome to do, once you are building on top of a WKWebView? Seems like Chrome would be a very thin layer on top of it, with WKWebView doing most of the work, and Chrome just implementing a thin layer of user interface widgetry on top of that (next and back button, url bar, etc). Sounds to me like it's just a branded "white label" version of Apple's standard Safari browser.
Well now that it's open source you could in theory remove the things you don't want and keep only the good parts. In practice it's not realistic for a single person to do it and even if it was you'd still have to maintain it.
Chrome on iOS has some neat UI innovations, though-- when you drag down on a page you see three icons; a + sign for a new tab, a refresh icon, and an X to close the current tab. So you can drag straight down to refresh, down then left to add a new tab, etc. I really miss that in safari.
It also syncs history, logins, open tabs, etc, with desktop Chrome.
Which is not as convenient to use on larger phones, one handed, compared to a gesture that works anywhere on the web page. I have a Honor 8 and while overall I'm very satisfied with the apps, speediness of the phone, the lack of gestures in most Android apps compared to iOS gets old very fast, even more so because 99% of all the good android handsets on the market are much bigger than the iPhone 5s I had before.
Saying you can press the back button located on the bottom left side of the screen really doesn't cut it.
I'm in the middle of a trial switch to Safari so that I can utilize this, but man, Safari on the desktop is such a pain compared to Chrome that I think I'm going to have to sacrifice the feature.
I'm not counting Craigslist, though its infrastructure is documented and open source, because you can't just download the engine and run it yourself without a lot of glue. Likewise Pirate Bay. There are probably more marginal cases like that among the top.
And there are open data projects like Stack Exchange and Stack Overflow that essentially publish all their content on open source licenses and offer free download dumps. Both are top 100 sites.
Then there are the news sites available without paywall. Those are just basic blogs with photos, video, and text accessible to the public. They aren't open source; you have to pay to republish their content. But there is essentially no special software you can't match with any open source CMS at CNN or the Washington Post or HuffPo or many, many other top sites.
I'd say the solid majority of the top 100 sites don't have any special closed source software, except for the proprietary search engine projects: Google, Bing, Yahoo, their respective mail and document suite projects, and the like.
Being websites they're a "view source" away? Sure a few might be obfuscated/minimized - but in general not to the point that they are very hard to learn from and experiment with...
Executables are just a hex editor away as well. Facebook.com's source is about as helpful as looking at Chrome.exe when learning to code or learn about them in any detailed way.
Apple is hostile to open source. The Apple store terms of service are incompatible with GPL. And to develop applications you need to be using macOS on apple hardware and you need to purchase a developer license as well.
Apple is not hostile to open source. GPL you get wrong way around. While it is true that you need Mac, you don't need to purchase developer license to develop. Only to distribute through App Store.
Yet almost all apps that I use are open source. OsmAnd, Firefox, Telegram, RedditIsFun, Linux Deploy, AFWall+, AdAway, Barcode Scanner, ConnectBot, Quasseldroid, some games like Lichess and Anuto TD, and a bunch of other tools that I use less frequently. Closed source is what I paid for, so fairly trustworthy as well (Spotify; Es File Explorer and Smart Audiobook Player). There are of course a few remaining ones like Google Play Store (I have F-Droid next to it) and Google Maps for traffic (use it 2-3x a month maybe).
Why don't more people use open source apps? I don't know, it's kind of weird since Android is a much bigger audience than, say, a Linux desktop. (On my laptop I don't think I use a single closed source thing anymore, at least not regularly.) I guess Android has a similar market environment as Windows instead of the open source ecosystem that surrounds Linux desktops.
I suppose it's like asking why websites are almost never open source. Why indeed?
Would this allow for better ad blocking software (no internal vpn tricks, etc), or would Apple likely reject a forked Chrome with adblocking from their app store?
You can have ad blocking, but you can't have the fast JavaScript engine and ad blocking, unless you are Safari. So you can't have a Chrome or Firefox with both, unless Apple fixes their APIs or allows the "real" versions of those browsers.
Not true at all, and also nothing is stopping you from building your own ad-blocking logic in to your browser either - iCab Mobile for example does just that.
Why not? WKWebView has a delegate callback for the policy to load any given URL. You can implement ad blocking that way. Or you can chose to inject CSS rules if that's your fancy.
Are you referring to the `-[WKWebView navigationDelegate]`?
Thats only used for user initiated navigation, not loading of assets.
You could still inject a JavaScript file or CSS file though to help hide pieces of the view. But that would be content blocking after the HTTP requests have been made.
I don’t know of a way to intercept the HTTP requests as they’re being made from a WKWebView like Safari does for content blocking.
The technical issue is that WKWebView does not honor any custom classes registered with NSURLProtocol (`NSURLProtocol registerClass:`) like UIWebView does, so you don't get to intercept/change/deny every request (not just top-level requests) that the browser makes.
You can already do ad blocking natively through Safari Content Blocking extensions. There is also another trick you can do where you can use a VPN that routes known top-level-domains to 0.0.0.0 which would allow for entire Apple System blocking (similar to /etc/hosts).
Passcode. There's always a reason you will lend your iPhone to your closed person. I'd like a feature to lock it down to avoid them using my Google Service & browser history.
If something is crippled in Firefox for iOS, nine out of ten times it is because Apple severely limited the exposed APIs of WKWebView. All browsers that are based on WKWebView are stuck between a rock and a hard place.
I wasn't sure if I read this correctly but does this mean if one compiles it themselves they can use blink on ios? That would be great for all those unsupported ipad 2's out there
The reason for Apple to lock the web browser engine is simple: it prevents you to turn an iphone into your bare platform, as much as you turned AT&T into a bare pipe. They know money comes from services not bare platform.
How does Chrome or Firefox running on iOS, using WKWebView for its backend rather than their own rendering engines, in any way turn the iPhone into a "bare platform"? How would users even know or care that these 3rd party browsers are not using their own rendering engine?
I stopped using Chrome because I didn't want everything I did on the web sent to them. Now that it's open source I'll probably never look at the code. So idk. Probably just gonna stick with Safari.
Does this mean we could see mobile extensions in the future? Not being able to use plugins, userscripts, etc is one of my least favorite things about mobile.
Of course it's a brilliant move: by controlling the stagnation of web browser tech, they can force developers to implement apps with their high-lock-in native app frameworks.
Google does the same thing with Android, but it is not nearly as blatant as Apple's flat-out blocking competitive browser implementations.