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]
[1] https://webkit.org/blog/7122/introducing-riptide-webkits-ret...
[2] https://developer.apple.com/library/prerelease/content/relea...
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.
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]
[1] https://developer.apple.com/library/content/documentation/Ge...
[2] http://www.imore.com/our-full-transcript-talk-show-wwdc-2016...
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.
Apple might have walled garden motives, but the security story is compelling on its own.
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 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.
Not so much with web apps.
See also: removal of the headphone jack, massive backlash, everyone still bought the fucking thing
[1] http://www.techrepublic.com/article/browser-wars-is-chrome-o...
[2] http://www.theverge.com/2015/4/10/8381447/chrome-macbook-bat...
[3] https://www.extremetech.com/computing/230583-microsoft-claim...
Google web apps (gmail, google maps, etc.) seem to be a particular offender.
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...
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.
get off my lawn etc.
Not buying it.
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.
That fact that localstorage doesnt work in private mode is 1 example.
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.
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.)
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.
Private mode means deleting the data, not disabling the functionality. Chrome and the rest handle it correctly.
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.
Service workers are another example of a feature that is missing in Safari. And an important one for offline support.
Its absence is a crippling limitation.
Yeah, the kind of "IE6" that beat Chrome and Firefox last year to be the first to fully support ES6 for example.
https://twitter.com/webkit/status/728643624464883712
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.
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
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.
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.
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).
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.
I'm looking at you Pokémon GO.
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.
That's my best guess anyway
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.
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.
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.)
Have you used WebKit? I'm running into issues with bugs that were reported 2+ years ago.
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.
It would be great if there was competition so that other browser developers could try to improve power efficiency even more.
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.
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.
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.
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....
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 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.
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...
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.
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.
iOS solution: everything goes through Apple,
I generally trust them...
and know that they try to look out for me.
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.
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?
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.
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 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:
https://github.com/WhisperSystems/Signal-Android/issues/1000...
"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.
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.
https://developer.apple.com/reference/callkit
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.
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).
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).
That doesn’t work in Marshmallow, due to a bug, even if the user opts out, it will still disable the app during Doze.
The bug has been fixed in later versions, but you as a dev obviously can’t just leave a huge share of your users without working push notifications.
Surely another constant connection like SIP would also be terminated, no? I don't see how that would differ from another push notification system.
edit: to be clear I'm using a 3rd party SIP client (Bria), which I have indeed excepted via this method.
This was fixed at https://android-review.googlesource.com/#/c/221708/ and probably merged into many custom roms generated since. It also only occurred under fairly specific circumstances.
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.
This leads to the problem that you, as a dev, either have to leave a huge amount of users without working push notifications, or use GCM anyway.
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.
https://developer.android.com/about/versions/marshmallow/and...
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 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.
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.
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.
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.
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).
I, for example, develop an app connecting to servers that the users self-host.
I can’t modify the server, nor can I easily get it to send notifications.
But I want to be able to show notifications.
Luckily I can open a port to it and wait for them.
It’s impossible to solve with GCM.
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.
please... SPAs are pretty darn fast and they can be placed on your homescreen to open via single tap, at least in Android.
Check out https://events.google.com/io2016/
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.
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)
> by controlling the stagnation of web browser tech, they can force
> developers to implement apps with their high-lock-in native app
> frameworks
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.
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. :-)
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 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.
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.
Now your web app even gets it's own icon in your home screen along with other native apps and it works offline too just like other native apps.
You are right, there's not much to talk about when native apps are facing an existential crisis.
Aren't there people using the web version of that because the app is so bloated?
Those same users also use a fixed set of web sites.
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.
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.
> 2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.
> 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.
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.
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.
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.
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.
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 ;-)
?!? 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.
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.
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.
Stop whining.
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.