4 ms·

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 Ap

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.

abalone 10y ago
> 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] [1] https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ https://developer.apple.com/library/content/documentation/Ge... [2] http://www.imore.com/our-full-transcript-talk-show-wwdc-2016-phil-schiller-and-craig-federighi http://www.imore.com/our-full-transcript-talk-show-wwdc-2016...
- autoconfig 10y ago
  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.
  - griffinmb 10y ago
    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.
    - quesera 10y ago
      Anything that makes jailbreaking simpler also makes it easier for the device and data to be compromised. Apple might have walled garden motives, but the security story is compelling on its own.
- aboodman 10y ago
  > 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)
coldtea 10y ago
>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. Not so much with web apps.
- yoz-y 10y ago
  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.
- sametmax 10y ago
  Yeah na. Facebook app have been a power hog for years and they allowed it because it's popular. Let's face it, Apple just does whatever Apple wants.
  - NTripleOne 10y ago
    And they get away with it because they're Apple. See also: removal of the headphone jack, massive backlash, everyone still bought the fucking thing
    - sametmax 10y ago
      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.
  - leppr 10y ago
    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.

abalone 10y ago

> 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] [1] https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/ https://developer.apple.com/library/content/documentation/Ge... [2] http://www.imore.com/our-full-transcript-talk-show-wwdc-2016-phil-schiller-and-craig-federighi http://www.imore.com/our-full-transcript-talk-show-wwdc-2016...

autoconfig 10y ago
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.
- griffinmb 10y ago
  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.
  - quesera 10y ago
    Anything that makes jailbreaking simpler also makes it easier for the device and data to be compromised. Apple might have walled garden motives, but the security story is compelling on its own.
aboodman 10y ago
> 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)

coldtea 10y ago

>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. Not so much with web apps.

yoz-y 10y ago
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.
sametmax 10y ago
Yeah na. Facebook app have been a power hog for years and they allowed it because it's popular. Let's face it, Apple just does whatever Apple wants.
- NTripleOne 10y ago
  And they get away with it because they're Apple. See also: removal of the headphone jack, massive backlash, everyone still bought the fucking thing
  - sametmax 10y ago
    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.
- leppr 10y ago
  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.