But here’s the current reality, one that has been accurate for awhile. Apple has a very, very strong influence over what standards get adopted and what standards do not. Partly it’s market share, partly it’s developer bias (see, for example, how other vendors eventually felt forced to start supporting the webkit prefix due to vendor prefix abuse).
Apple simply does not play well with other vendors when it comes to standardization. The same sort of things we once criticized Microsoft for doing long ago, we give Apple a pass on today. They’re very content to play in their own little sandbox all too often.
All this specifically pertaining to the Touch Events/Pointer Events dichotomy. The latter is superior, but Apple refuses to support it, while the former couldn’t be adopted because of patent threats from Apple. So, Pointer Events is now finalised, but Apple will not implement it.
They’re not the only ones to blame for yet another childish, nonsensical, anti-consumer spat in web standardisation – Google is just as much to blame. This is what a Google engineer has to say on the matter:
No argument that PE is more elegant. If we had a path to universal input that all supported, we would be great with that, but not all browsers will support PE. If we had Apple on board with PE, we’d still be on board too.
Android is the biggest mobile platform, and Chrome is the most popular desktop browser. Had Google the stones, they’d implement Pointer Events and help paint Apple in a corner. They refuse to do so, thereby contributing just as much to this nonsense as Apple.
All this reeks of specifically wanting to hurt the web just because these companies are competitors elsewhere. Bunch of children.
Actually, there’s no need to implement anything, because Microsoft contributed the code to WebKit before the Blink fork.
Apple never enabled the code, while Google dropped the support from Blink at some point…
What Google engineer said doesn’t make sense at all. Google is all too aware of their leverage on web standards and i’m sure they know they can wrestle Apple to ground.
Playing the conspiracy card here, i would point to a hidden Google-Apple agreement of some kind.
Will Apple Embrace the Web? No.
http://www.osnews.com/story/23378/Will_Apple_Embrace_the_Web_No_ – Kroc, May 2010
Agreed.
My feeling would be that Google will come around eventually now it’s a standard.
For everything else there is Mastercard… euh, I mean Pointer Events Polyfill ( PEP ):
https://github.com/jquery/PEP
http://blog.jquery.com/2015/02/24/getting-on-point/
Since WebKit is LGPL, is there anybody releasing drop-in replacement builds of WebKit that includes features that Apple doesn’t ship enabled?
That won’t going to help. Apple ban any alternative browsers on iOS effectively controlling the browser there. That’s the problem. I think they should be attacked on the antitrust grounds, then their unhealthy level of control will drop down. This particular example of Apple having too much influence will help such antitrust case.
Edited 2015-02-25 18:27 UTC
Do they? I have Google’s Chrome browser on my iPad.
It’s using Apple’s engine. So it’s the same browser underneath. They don’t formally ban browsers, they ban any application that can download and execute code at runtime, which means any JavaScript engine, which means any modern browser engine, which means any browser not built with Apple’s engine (they permit an exception for theirs).
It’s a blatant anti competitive restriction in iOS SDK which Apple got away with until now.
Note, they don’t just forbid that in their store, the license of the SDK forbids even to build such application!
In your opinion what specific competitive business advantage does Apple gain by doing this?
Controlling the browser on the massive installation base (all iOS devices) and through it controlling Web standards themselves, like above.
Such control they can use for whatever is related. For example it helps them keeping their patents active (like on the above mentioned touch events). If patent free alternatives become universally accepted, Apple’s patents will become irrelevant and they neither will be able to sell them to other trolls nor require anyone to pay for them (because no one would need them anyway).
Edited 2015-02-25 23:17 UTC
I still can’t see what unfair competitive advantage preventing other browser engines running under iOS brings to Apple’s handsets in relation to competing handsets. What specific unfair advantage do Apple products gain and what specific unfair disadvantage do competing product suffer because of Apple impeding the use of third party browser engines?
All you seem to be talking about is patent related stuff, which frankly seems to be a bit of a rather weak red herring. Do you think Apple makes much money from patent related income?
Looking at data on Apple’s finances I would say that in it’s iOS device business, where the bower engine block operates, Apple makes pretty much all its revenue from actuating selling devices, and that given I have never seen it referenced in any detailed breakdown of Apple financial reports by third party analyst, its probable that Apple’s patent related income would make up a vanishingly small fraction of its revenues. I confess I have not looked deeply into Apple’s patent related income so any data you have on actual Apple patent related income would be appreciated.
If you had argued that Apple did what did in relation to Pointer Events because it was concerned about the security or stability issues resulting from allowing other JavaScript engines to run freely on it’s devices, or that Apple thought that letting in alternative JavaScript engines would weaken it’s control of it’s own platform, then I would have found that far more plausible. Of course none of those motivations could be construed as being anti-competitive, merely very controlling of the technology that is contained in its devices, something which Apple is open about aspiring to.
It prevents other software developers from using non-Apple frameworks on iOS hardware. For example applications written for XULRunner (a Mozilla UI framework) are blocked from running on iOS devices. Since they have quite a dominant position most developers have no choice than use Apple’s software stack.
What advantage does this bring them? A platform is really the apps that run there. By preventing competing platform technologies access they prevent apps from easily supporting other platforms. This gives their own stack a competitive advantage. Pretty close to what Microsoft did in the 90’s. And so far they killed Flash on mobiles with it, so it certainly works!
Not that I cry over the death of flash, but that’s a different story.
Apple have always been explicitly committed to maintaining control over their platform and that means control over the development framework on their platform. Apple is also committed to continuous, rapid and significant development of the iOS platform and to rolling out platform development to as many of its several hundred million users as quickly and extensively as it can. The two things are intimately connected.
Apple understands two things very clearly. One is that developing iOS and iOS connected services (HealthKit, HomeKit, CarKit, Apple Pay, etc) is a crucial differentiator for it’s device offerings and an important way to add value to its products. The second thing it understands is that if third party development frameworks became prevalent on iOS then it could no longer guaranteed that it could indeed rollout continuous, rapid and significant development of the iOS platform, and might well be thwarted in its platform ambitions. That’s not an unfounded fear as it is precisely what happened on the Mac back in the day.
Apple’s near death experience taught it many lessons and one is that it should never lose control of the development framework of its own platform ever again. Although I can see how that stance my irritate some people but I personally cannot see how that can be construed as being anti-competitive. Apple are a minority player in the smart phone market and they say this is our platform and this is how it works and we won’t let anyone tamper with that. Seems fair enough to me.
Except of course the key difference between the situation with Windows compared to the situation with iOS is that iOS does not dominate 90% of all smart phones and therefore Apple’s actions are not an abuse of a monopoly market position.
[q]And so far they killed Flash on mobiles with it, so it certainly works!]
I think that perhaps the fact that Flash was so poorly suited to mobile deployment that it essentially crippled mobile devices had more to do with its demise in mobile than Apple’s actions. If Flash ran great on mobile, didn’t eat battery power and CPU cycles and was secure, I am sure it would still in widespread use today. Apple just happened to be the company that said the emperor had no clothes, the emperor was already naked.
Exactly how does 3rd party executables prevent Apple from updating their frameworks? What we are talking about here is Apple banning 3rd party apps from JIT’ing code – something that Apple allow themselves to do. This double standard is exactly what makes them like MS in the 90’s.
I have actually used the Carbon API (which Thom so kindly educated me works back to Macs from 1665) and I saw nothing that supports this claim.
In any case, the step from classic Mac to OS X was not significantly more complicated than moving from Windows 3.x (16 bit far pointers *shudder*) to Windows 95 (32 bit, completely new platform API). I don’t know enough of the history of early Apple to say why they derailed, but I find it far more likely they stagnated because nobody had the balls to do the move Jobs did when he moved OS X from PowerPC to Intel. Staying on obsolete technology is like pissing in the pants in the long run and MS did kind of have preemptive multitasking and 32 bit for 5 years while Apple did nothing.
You asked what advantage it gave Apple to block other browsers. Forcing developers to use their own tech is that advantage. Is it anti-competitive? (or “unfair”) That depends on who you ask, but they certainly do it to serve their own interests – I’m sure we can agree on that at least.
Yes, and that is about the only difference. Still, from a developers point of view, you do not really have a choice of not supporting Apple if you want to target mobile. Their market position is large enough for that.
Impossible to say for sure because Apple’s policy effectively told Adobe that they had to rewrite their entire platform if they wanted to stay in the market. Changing your entire flash runtime to compile to native code is not something you do over night.
Adobe chose instead to effectively drop Flash – I guess someone there hated Flash as much as the rest of us.
Flash is pretty much alive on mobiles, as you can generate native code nowadays.
http://www.adobe.com/devnet/air/native-extensions-for-air.html
And the solution runs worse than it could have because they can’t do intelligent re-jitting that dynamic languages like Javascript often need. Blocked by Apple’s silly policy.
However my point was more that they pushed back multiple competing framework technologies for years as they forced them all to spend significant time rewriting core functionality. Which is exactly what Apple wanted to happen.
It would work with Apple laptops and desktops, though.
Apple’s Magic Trackpad seems fairly popular.
I suspect their impact on this issue is way smaller than impact of the mobile browser.
Edited 2015-02-25 21:44 UTC
It’s a start. The mere existence of a patched version of WebKit might be the kick in the pants that Apple needs. Apple’s dominance relies heavily on perception, and a patched, “Improved” version of Safari could alter their perception.
Alternatively, somebody could potentially make it an ADA issue: What if there’s a website that accommodates disabled people via the published, open standard on pointer input, but Apple purposely disables the feature in their own browsers? I know the ADA doesn’t require open standards be followed, but it doesn’t seem far fetched to make Apple enable a standard when the work has already been done, if the situation presents itself correctly.
That would be fun.
Edited 2015-02-25 22:26 UTC
Same level of lameness as their excuse of why they dropped support for XMPP – “others didn’t go along”. Grow up Google, and do the right thing instead of blaming others for dong the wrong one yourself.
Edited 2015-02-25 18:08 UTC
google im implements xmpp just fine, i’m using it all the time. it’s xmpp federation that they dropped.
I’m not convinced Google could force Apple to change; Apple has too much power in important markets.
I’d read Google’s decision as saying that a unified standard is better than having two conflicting standards that everyone must support. I think that’s a reasonable conclusion – making compromises is part of the standardization process.
Key words – too much. There is antitrust law for that.
Except there can be no such thing if Apple sabotages the proposal for such unified standard and Google uses that as an excuse for not implementing it either.
Edited 2015-02-25 19:56 UTC
Well, a prime example of the same thing happening before is something we saw during HTML5 video codec-game.
When some vendors preferred and pushed open-source implementations (WebM = VP8|VP9 + Vorbis|Opus), then others preferred patent-encumbered and non-free ones (and said they never will implement anything else). Mozilla, Google and Opera were in the first team and Apple in the other one. And Microsoft somewhere in between.
Then the same happened again in WebRTC standardization.
Quite some years (and a Cisco offer) have passed (and Google has encoded all Youtube content to both VP8 and VP9) and it still is a mess – there is no common implementation for HTML5 video and WebRTC.
Different parties are now developing the next generation of video codecs and the same seems to be happening again (and actually this time there will be 2 new opensource videocodecs: Daala and VP10). I have no idea how Apple will stand in that case.
The same situation is also in the choice of future picture-codecs. Open-source WebP (and a possible alternative by Mozilla) against BPG (where patent-status is unclear).
Edited 2015-02-25 20:13 UTC
For pictures, Daala will offer something good: https://people.xiph.org/~xiphmont/demo/daala/update1.shtml
BPG too :
http://bellard.org/bpg/
http://bellard.org/bpg/lena.html
http://xooyoozoo.github.io/yolo-octo-bugfixes/
BPG is a patent minefield. Not going to happen.
Patents…
Er… Nihil sub sole novi, you meant. Right? 🙂
I find your negative comments laughable at best. And guess what. My oppinions and comments are just as laughable. So no, I haven’t forgotten that four fingers point back to me when one is pointed at you.
I’m not referring to any one particular person but the whole of the negative comments.
If you don’t like something, build your own. To try to dictate what Apple or Google should do just because _you_ demand it because their view of how things should be doesn’t fit you, well, that I find laughable.
Apple didn’t sit down and roll dice and just pull Touch Events out of their posterior. There is an article out there that said that Apple created over 50 different versions of effects for iOS before they settled on Touch Events because there were effects that they wanted which couldn’t be done as efficiently and elegantly with Pointer Events.
Now as to whether you agree that this or that is important to you. That’s just it. That’s your opinion and there is a saying about everything having an opinion and something else. Most of the time both stink. Not yours specifically but everyone’s including mine.
If you don’t like Apple’s business practices, or Google’s, or Microsoft’s, I’m not going to argue with you. That is a totally different subject. But if there are so many of you that hate Touch Events, and keep in mind that this is OS News and not People Magazine, so a lot higher section of readers here are programmers … get your act together, work together, create your own mobile OS and then load it on whatever hardware you like (if it isn’t locked down) and stop buying M$, Google, and Apple devices. Then guess what would happen.
If there are enough people that really like your design and aesthetics compared to the big two, Google (volume sales) or Apple (90+% of mobile profits) will have to stop and pay attention to you because you would be taking sales away from them.
The only question left really is, who is going to step up and _lead_?
– The best leaders appear to have to be jack asses
– The best leaders have to have a VERY clear vision
– The best leaders have to admit when they are wrong when there is compelling evidence that they are.
– The best leaders know the difference between someone else _thinking_ they are right and what is really right.
There are very few real leaders in the world compared to most of the rest of us who aren’t. Not at that scale at least.