5 ms·

The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim

by eridius 10y ago

The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim to do without flagrantly violating the guidelines.

empthought 10y ago
It only started to matter when dumbasses started thinking that using Javascript everywhere was A-OK.
- sctb 10y ago
  Please comment civilly and substantively on HN or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
geofft 10y ago
I'm guessing there are two things Apple is worried about. The first is using hot code push to change the purpose of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs. You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls back into pre-existing native code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban the app and the developer if they catch it. It appears that Rollout started using some API that would enable it to do the second, and Apple is preemptively making sure that it doesn't happen. The wording of the rejection is based on passing computed parameters to introspection routines.
- amluto 10y ago
  > The second is using hot code push to violate app store review guidelines, like the use of private APIs. I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?
  - sjwright 10y ago
    Presumably because many private APIs are used behind the scenes by public APIs and the security model must allow applications to run them.
  - Elizzy 10y ago
    Because some of these APIs are useful in an enterprise app setting that aren't distributed via the App Store. Like Disney applications on their turnstile devices at Disney World.
  - marcoperaza 10y ago
    You aren't supposed to call private APIs in your code, but your app is definitely making private API calls all the time since the libraries provided by the platform are running in-process.
  - euyyn 10y ago
    Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.
    - tluyben2 10y ago
      They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?
      - jahewson 10y ago
        Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.
        tluyben2 10y ago
- JohnBooty 10y ago
  > I'm guessing there are two things Apple is worried about. I'm sure it worries about them but there's a much larger, riskier scenario. Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong. 1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secure manner, but the server from which the code is served becomes cot mpromised 3. A malicious employee at an iOS app vendor pushes harmful code out via her company's app Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. Just like Android or MacOS. However, I sympathize with them here. For nearly a decade people have been downloading code from the App Store with the understanding that it is safe to do so. Even I appreciate this much of the time... I'm an engineer but I'm busy. I can't audit every app I download. I wish there were other options, but I find huge value in the fact that I don't have to worry about an App Store app screwing my device. And it's a big reason why I recommend iOS despite its flaws to older family members.
  - jsjohnst 10y ago
    > Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. This exists today and has for a long time, it just costs you money for this "privilege".
    - praseodym 10y ago
      You can compile and run apps on your own devices without a paid developer membership: https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sideload-ios-apps-for-free/amp/ https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-...
      - gergles 10y ago
        They've nerfed this so that the app will only run for a week before you must push another build.

by eridius 10y ago

empthought 10y ago

It only started to matter when dumbasses started thinking that using Javascript everywhere was A-OK.

sctb 10y ago
Please comment civilly and substantively on HN or not at all. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

geofft 10y ago

I'm guessing there are two things Apple is worried about. The first is using hot code push to change the purpose of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs. You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls back into pre-existing native code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban the app and the developer if they catch it. It appears that Rollout started using some API that would enable it to do the second, and Apple is preemptively making sure that it doesn't happen. The wording of the rejection is based on passing computed parameters to introspection routines.

amluto 10y ago
> The second is using hot code push to violate app store review guidelines, like the use of private APIs. I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?
- sjwright 10y ago
  Presumably because many private APIs are used behind the scenes by public APIs and the security model must allow applications to run them.
- Elizzy 10y ago
  Because some of these APIs are useful in an enterprise app setting that aren't distributed via the App Store. Like Disney applications on their turnstile devices at Disney World.
- marcoperaza 10y ago
  You aren't supposed to call private APIs in your code, but your app is definitely making private API calls all the time since the libraries provided by the platform are running in-process.
- euyyn 10y ago
  Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.
  - tluyben2 10y ago
    They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?
    - jahewson 10y ago
      Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.
      - tluyben2 10y ago
JohnBooty 10y ago
> I'm guessing there are two things Apple is worried about. I'm sure it worries about them but there's a much larger, riskier scenario. Once you start downloading and executing binary code from untrusted sources (i.e., not the App Store) anything can go wrong. 1. An iOS app doesn't care about security, and it hot-loads code from some non-https source and gets man-in-the-middle'd 2. An iOS app hot-loads code in a secure manner, but the server from which the code is served becomes cot mpromised 3. A malicious employee at an iOS app vendor pushes harmful code out via her company's app Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. Just like Android or MacOS. However, I sympathize with them here. For nearly a decade people have been downloading code from the App Store with the understanding that it is safe to do so. Even I appreciate this much of the time... I'm an engineer but I'm busy. I can't audit every app I download. I wish there were other options, but I find huge value in the fact that I don't have to worry about an App Store app screwing my device. And it's a big reason why I recommend iOS despite its flaws to older family members.
- jsjohnst 10y ago
  > Now, I'm not a fan of Apple's policies. I think there should be a "guys, I know what I'm doing" mode where I'm allowed to download code from untrusted sources. This exists today and has for a long time, it just costs you money for this "privilege".
  - praseodym 10y ago
    You can compile and run apps on your own devices without a paid developer membership: https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-allows-anyone-to-download-build-and-sideload-ios-apps-for-free/amp/ https://www.google.com/amp/s/9to5mac.com/2015/06/10/xcode-7-...
    - gergles 10y ago
      They've nerfed this so that the app will only run for a week before you must push another build.