5 ms·

It's not a restriction on JITs that's the problem (though certainly it would be a limitation), it's this: “Apps that browse the web must use the iOS WebKit fram

It's not a restriction on JITs that's the problem (though certainly it would be a limitation), it's this: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.”

shmerl 10y ago
A bit more elaborate than this. They don't allow using iOS SDK for building applications which download and execute dynamic code. I was thinking about a legal workaround for it. What if someone has a non Apple SDK for iOS? Then building will become legal. Though they probabaly can put in a restriction, that they accept only usage of official SDK for their store. Either way, it's a very slimy anti-competitive restriction masked under pretense of security concerns.
- yoklov 10y ago
  > They don't allow using iOS SDK for building applications which download and execute dynamic code While this is true, it's also explicitly that "Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript" Regarding a non-apple iOS SDK: "Apps may only use public APIs". this forbids anybody from making an alternative SDK.
  - shmerl 10y ago
    > Regarding a non-apple iOS SDK: "Apps may only use public APIs". this forbids anybody from making an alternative SDK. What stops any alternative SDK from being public?
    - TD-Linux 10y ago
      Nothing, but iPhones only load software signed by Apple (on the app store), so said alternative SDK would be useless as Apple won't sign software made with it (and regardless, they won't sign an alternative browser engine as a matter of policy regardless of which SDK with was made with).
    - yoklov 10y ago
      Nothing, but you couldn't implement an alternative SDK using the public APIs, since, well, the public APIs are the current SDK.
      - shmerl 10y ago
        Not sure what you mean exactly. Let's say someone comes along, and re-implements all same APIs from scratch as open source. They'll be public, right? But as TD-Linux said, Apple simply will refuse to accept it anyway.
        yoklov 10y ago
        Right, but you can't implement a lot of the APIs without calling into private kernel functions.
bartread 10y ago
Whether the restriction is a problem or not very much depends on your point of view. Apple never comment publicly on these things but I imagine their argument hinges on two points: 1) Performance (and by implication UX) 2) Battery life These are exactly the points Steve Jobs raised in his "Thoughts on Flash" missive from 2010: http://www.apple.com/hotnews/thoughts-on-flash/ http://www.apple.com/hotnews/thoughts-on-flash/. And this is the same issue: Flash was a runtime, just like third party JS runtimes. Frankly, I'm with Apple on this one. Jeff Atwood's post on Android JS performance might be getting bit long in the tooth ("The State of JavaScript on Android in 2015 is… poor" - https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/244 https://meta.discourse.org/t/the-state-of-javascript-on-andr...) but, as recently as November 2016, he posted to the discussion indicating that performance still lags. I can verify this myself. My 3 year old iPhone 5S equals or betters the performance of my one year old OnePlus Two, which I use for testing (and maybe I should blog on this topic). If you dig through Jeff's thread (warning: it's grown really long) you'll see that I wouldn't be having a much better time if I upgraded to a OnePlus Three. So, do I want Google to be allowed to run a version of Chrome on iOS that uses other than Apple's JS runtime? No, not really. Do I want Firefox to be allowed to do that? Hell no. There are bound to be data points that contradict this but my experience is that Firefox on the desktop lags Chrome, Safari (OSX, obviously), Internet Explorer 11 and Edge in terms of performance and framerate. (Again, I should post about this, with numbers.) My extremely limited exposure to Firefox OS back in 2013 suggested it was slow as hell and not worth the bother of developing applications for (too many compromises required) - doubtless not helped by low spec hardware. Apple pour huge resources into making their iOS JIT run like the wind on a hardware platform that they know inside out. Nobody else is going to be able to do that. IANAL but I don't think the monopoly argument (think it's in the parent post) holds water simply because Apple doesn't, and is never likely to have, a monopoly in the phone market. If people don't like Apple devices, or iOS as a platform, they have a choice: they can buy an Android or Windows Phone device, and run all the apps they need (particularly on the former). That wasn't the case in the late 1990s with Microsoft and Windows. If you were a nerd you could run Linux, and you could tolerate the limitations of Star Office or KOffice compared with MS Office, and Apple were just getting back off the ropes, so maybe you'd run a Mac at home. But if you were a non-techy and/or you wanted to get serious work done and be able to easily collaborate and cooperate with other people you were probably running windows. At one point Microsoft's market share was something like 97%. 97%! In Q2 2016 Apple's worldwide smartphone market share had fallen to 12.9% (source: https://9to5mac.com/2016/08/18/android-ios-smartphone-market-share/ https://9to5mac.com/2016/08/18/android-ios-smartphone-market...). That's not a monopoly. It's not even within hailing distance of a monopoly. Going back to my original point, iDevices and iOS are Apple's platform, and I do not object to them restricting what can run on those devices in terms of runtimes and JITs because I care about performance, UX, and having a decent battery life. Some people aren't going to like, but then they can choose one of the alternatives.

It's not a restriction on JITs that's the problem (though certainly it would be a limitation), it's this: “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript.”

shmerl 10y ago

A bit more elaborate than this. They don't allow using iOS SDK for building applications which download and execute dynamic code. I was thinking about a legal workaround for it. What if someone has a non Apple SDK for iOS? Then building will become legal. Though they probabaly can put in a restriction, that they accept only usage of official SDK for their store. Either way, it's a very slimy anti-competitive restriction masked under pretense of security concerns.

yoklov 10y ago
> They don't allow using iOS SDK for building applications which download and execute dynamic code While this is true, it's also explicitly that "Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript" Regarding a non-apple iOS SDK: "Apps may only use public APIs". this forbids anybody from making an alternative SDK.
- shmerl 10y ago
  > Regarding a non-apple iOS SDK: "Apps may only use public APIs". this forbids anybody from making an alternative SDK. What stops any alternative SDK from being public?
  - TD-Linux 10y ago
    Nothing, but iPhones only load software signed by Apple (on the app store), so said alternative SDK would be useless as Apple won't sign software made with it (and regardless, they won't sign an alternative browser engine as a matter of policy regardless of which SDK with was made with).
  - yoklov 10y ago
    Nothing, but you couldn't implement an alternative SDK using the public APIs, since, well, the public APIs are the current SDK.
    - shmerl 10y ago
      Not sure what you mean exactly. Let's say someone comes along, and re-implements all same APIs from scratch as open source. They'll be public, right? But as TD-Linux said, Apple simply will refuse to accept it anyway.
      - yoklov 10y ago
        Right, but you can't implement a lot of the APIs without calling into private kernel functions.

bartread 10y ago

Whether the restriction is a problem or not very much depends on your point of view. Apple never comment publicly on these things but I imagine their argument hinges on two points: 1) Performance (and by implication UX) 2) Battery life These are exactly the points Steve Jobs raised in his "Thoughts on Flash" missive from 2010: http://www.apple.com/hotnews/thoughts-on-flash/ http://www.apple.com/hotnews/thoughts-on-flash/. And this is the same issue: Flash was a runtime, just like third party JS runtimes. Frankly, I'm with Apple on this one. Jeff Atwood's post on Android JS performance might be getting bit long in the tooth ("The State of JavaScript on Android in 2015 is… poor" - https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889/244 https://meta.discourse.org/t/the-state-of-javascript-on-andr...) but, as recently as November 2016, he posted to the discussion indicating that performance still lags. I can verify this myself. My 3 year old iPhone 5S equals or betters the performance of my one year old OnePlus Two, which I use for testing (and maybe I should blog on this topic). If you dig through Jeff's thread (warning: it's grown really long) you'll see that I wouldn't be having a much better time if I upgraded to a OnePlus Three. So, do I want Google to be allowed to run a version of Chrome on iOS that uses other than Apple's JS runtime? No, not really. Do I want Firefox to be allowed to do that? Hell no. There are bound to be data points that contradict this but my experience is that Firefox on the desktop lags Chrome, Safari (OSX, obviously), Internet Explorer 11 and Edge in terms of performance and framerate. (Again, I should post about this, with numbers.) My extremely limited exposure to Firefox OS back in 2013 suggested it was slow as hell and not worth the bother of developing applications for (too many compromises required) - doubtless not helped by low spec hardware. Apple pour huge resources into making their iOS JIT run like the wind on a hardware platform that they know inside out. Nobody else is going to be able to do that. IANAL but I don't think the monopoly argument (think it's in the parent post) holds water simply because Apple doesn't, and is never likely to have, a monopoly in the phone market. If people don't like Apple devices, or iOS as a platform, they have a choice: they can buy an Android or Windows Phone device, and run all the apps they need (particularly on the former). That wasn't the case in the late 1990s with Microsoft and Windows. If you were a nerd you could run Linux, and you could tolerate the limitations of Star Office or KOffice compared with MS Office, and Apple were just getting back off the ropes, so maybe you'd run a Mac at home. But if you were a non-techy and/or you wanted to get serious work done and be able to easily collaborate and cooperate with other people you were probably running windows. At one point Microsoft's market share was something like 97%. 97%! In Q2 2016 Apple's worldwide smartphone market share had fallen to 12.9% (source: https://9to5mac.com/2016/08/18/android-ios-smartphone-market-share/ https://9to5mac.com/2016/08/18/android-ios-smartphone-market...). That's not a monopoly. It's not even within hailing distance of a monopoly. Going back to my original point, iDevices and iOS are Apple's platform, and I do not object to them restricting what can run on those devices in terms of runtimes and JITs because I care about performance, UX, and having a decent battery life. Some people aren't going to like, but then they can choose one of the alternatives.