8 ms·

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically in

"Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo. Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute native code such as the dlopen() function that Apple mentioned in that message. We also haven't received any messages from Apple about Expo, nor have we heard of any Expo developers receiving the same." - Exponent Team

deleted 10y ago
[deleted]
dylanpyle 10y ago
Though the security justification here is limited to private APIs & native code pushing, the first few sentences of the rejection definitely seem like the "spirit" of the terms includes any significant functionality pushing at all. Wouldn't be surprised if they ramp up enforcement on that.
jeswin 10y ago
The problem with Apple that you and your customers need to be aware of (or concerned about), is that once a number of your customers sidestep Apple policies w.r.t. pushing or changing features via JavaScript, Apple will change their policies to close that loophole. It's only a matter of time before companies take advantage of this path to sidestep app store approvals.
- Twisell 10y ago
  As a client I'm pretty baffled that some developer had specifically bypassed something that I see as a security measure. If an app is modified on the fly to use an undocumented and maybe "forbidden by apple" method in order to bypass security features or worse spy on me I'm clearly not ok. Do you really think the apple ecosystem work because clients see AppStore as a evil cage and that the external developers are all angels with good intentions?
  - K0SM0S 10y ago
    It's actually a double-edged security sword. By not allowing developers to patch their app 'on the fly', directly, without going through a new version in the app store (which is a very lengthy process, almost forever in security terms), Apple effectively protects their iOS users from malicious code (not from the dev, which is probably to be trusted if the app is already installed, but from MITM attacks and the likes). However at the same time they deny very hasty security patches, which may compromise the device and all associated data and accounts entirely. So there's no best world but undoubtingly many aspects to consider. Anecdotally I find that it's often better to trust the developers of an app to maintain their own thing; the OS only being a facilitator, provided the user has control (UAC on Windows, Permissions on mobile, etc.) [note: obviously you trust the OS vendor to patch said OS, it's just a particular kind of app] edit: wording
    - Twisell 10y ago
      I believe carefully crafted update should mostly mitigate that risk. Also current policy don't prevent app developers to implement a "kill switch" that will prompt user to update (or wait for update) at splash screen and abort loading the malfunctioning version.
    - deleted 10y ago
      [deleted]
    - deleted 10y ago
      [deleted]
teknologist 10y ago
This appears to affect apps using JSPatch which is not pushing Objective-C but JavaScript. Source: https://github.com/bang590/JSPatch/issues/746 https://github.com/bang590/JSPatch/issues/746 (in Chinese)
- jameside 10y ago
  The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Objective-C methods that are callable from JavaScript, and within your Objective-C methods you write regular Objective-C that is statically checked by Xcode and Apple.
  - teknologist 10y ago
    I'm not sure why people are concerned about React Native being targeted by this new enforcement of the rule. It is not the same thing at all.
    - je42 10y ago
      it shares some components. like javascriptcore. difference is the js - native bridge. for react native it is fixed bridge, that can only change with a change in the binary. for rollout they can execute any native code with an update of the JS.
    - batmansmk 10y ago
      The main reason for React Native to not be impacted is that Facebook + Instagram + Airbnb + Soundcloud + ... are using it and Apple cannot justify to their userbase to not accept those favorite apps for a technical reason.
      - matthewmacleod 10y ago
jameside 10y ago
Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning. React Native is different from those libraries because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs. Technically it is possible for a WebView app or a React Native app also to contain code that exposes uncontrolled access to native APIs. This could happen unintentionally; someone using React Native might also use Rollout. But this isn't something specific to or systemic about React Native nor WebViews anyway. One nice thing about Expo, which uses React Native, is that we don't expose uncontrolled or dynamic access to native APIs and take care of this issue for you if your project is written only in JS. We do a lot of React Native work and are really involved in the community and haven't heard of anyone using Expo or React Native alone having this issue.
- santiagobasulto 10y ago
  James, do you know if they're going to go agains the Exponent app per-se?
  - jameside 10y ago
    Oh, no, I don't have reason to believe so.
- chj 10y ago
  How can you ship an app with access to private APIs? There is a private API usage scanning before you can submit for review.
  - 0x0 10y ago

deleted 10y ago

[deleted]

dylanpyle 10y ago

Though the security justification here is limited to private APIs & native code pushing, the first few sentences of the rejection definitely seem like the "spirit" of the terms includes any significant functionality pushing at all. Wouldn't be surprised if they ramp up enforcement on that.

jeswin 10y ago

The problem with Apple that you and your customers need to be aware of (or concerned about), is that once a number of your customers sidestep Apple policies w.r.t. pushing or changing features via JavaScript, Apple will change their policies to close that loophole. It's only a matter of time before companies take advantage of this path to sidestep app store approvals.

Twisell 10y ago
As a client I'm pretty baffled that some developer had specifically bypassed something that I see as a security measure. If an app is modified on the fly to use an undocumented and maybe "forbidden by apple" method in order to bypass security features or worse spy on me I'm clearly not ok. Do you really think the apple ecosystem work because clients see AppStore as a evil cage and that the external developers are all angels with good intentions?
- K0SM0S 10y ago
  It's actually a double-edged security sword. By not allowing developers to patch their app 'on the fly', directly, without going through a new version in the app store (which is a very lengthy process, almost forever in security terms), Apple effectively protects their iOS users from malicious code (not from the dev, which is probably to be trusted if the app is already installed, but from MITM attacks and the likes). However at the same time they deny very hasty security patches, which may compromise the device and all associated data and accounts entirely. So there's no best world but undoubtingly many aspects to consider. Anecdotally I find that it's often better to trust the developers of an app to maintain their own thing; the OS only being a facilitator, provided the user has control (UAC on Windows, Permissions on mobile, etc.) [note: obviously you trust the OS vendor to patch said OS, it's just a particular kind of app] edit: wording
  - Twisell 10y ago
    I believe carefully crafted update should mostly mitigate that risk. Also current policy don't prevent app developers to implement a "kill switch" that will prompt user to update (or wait for update) at splash screen and abort loading the malfunctioning version.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]

teknologist 10y ago

This appears to affect apps using JSPatch which is not pushing Objective-C but JavaScript. Source: https://github.com/bang590/JSPatch/issues/746 https://github.com/bang590/JSPatch/issues/746 (in Chinese)

jameside 10y ago
The key part of JSPatch is that it exposes arbitrary, uncontrolled access to native APIs. You could use it to call private APIs even because Objective-C doesn't distinguish between public and private APIs at runtime, so Xcode's compiler checks and Apple's static analysis can't anticipate which APIs are possibly called. In contrast, React Native doesn't expose uncontrolled access to native APIs. You write regular Objective-C methods that are callable from JavaScript, and within your Objective-C methods you write regular Objective-C that is statically checked by Xcode and Apple.
- teknologist 10y ago
  I'm not sure why people are concerned about React Native being targeted by this new enforcement of the rule. It is not the same thing at all.
  - je42 10y ago
    it shares some components. like javascriptcore. difference is the js - native bridge. for react native it is fixed bridge, that can only change with a change in the binary. for rollout they can execute any native code with an update of the JS.
  - batmansmk 10y ago
    The main reason for React Native to not be impacted is that Facebook + Instagram + Airbnb + Soundcloud + ... are using it and Apple cannot justify to their userbase to not accept those favorite apps for a technical reason.
    - matthewmacleod 10y ago

jameside 10y ago

Hi, I work on Expo (YC S16) and also am a core contributor to React Native. Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning. React Native is different from those libraries because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs. Technically it is possible for a WebView app or a React Native app also to contain code that exposes uncontrolled access to native APIs. This could happen unintentionally; someone using React Native might also use Rollout. But this isn't something specific to or systemic about React Native nor WebViews anyway. One nice thing about Expo, which uses React Native, is that we don't expose uncontrolled or dynamic access to native APIs and take care of this issue for you if your project is written only in JS. We do a lot of React Native work and are really involved in the community and haven't heard of anyone using Expo or React Native alone having this issue.

santiagobasulto 10y ago
James, do you know if they're going to go agains the Exponent app per-se?
- jameside 10y ago
  Oh, no, I don't have reason to believe so.
chj 10y ago
How can you ship an app with access to private APIs? There is a private API usage scanning before you can submit for review.
- 0x0 10y ago