Hacker News Reader

Comment by ourcat | Hacker News Reader

Didn't Apple start rejecting apps recently which do 'hot code' pushes to update apps remotely? (As the video on the Expo.io site says)

View on HN

I believe that was only for apps that could talk to Objective C API's natively, in other words, essentially bypassing the native code review process. React Native can only do hot updates of JavaScript (which may call existing Objective C API wrappers, but not create new ones).

It's exactly the same in the case of Rollout, they were also only updating JS using JavaScriptCore, not using new native APIs.

Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using Objective-C's reflection capabilities), while React Native and Ionic/Cordova WebViews require you to explicitly bridge your own native methods. That was one of the key differences in Apple's concern.

Implementations already exist, such as react-native-invoke, that enable similar functionality. The jump from "need to explicitly bridge" and "explicitly bridge the runtime API" is very small, opening the possibility of exactly the same features as Rollout.

The clause of the app store guidelines is not just about code; it also forbids gaming the review process for adding features or changing the app purpose without an explicit review. This is regardless of the language used to write the app.

About react-native-invoke: https://medium.com/@talkol/invoke-any-native-api-directly-fr...

The GitHub page has been set to private for ... reasons I can't divulge, but the NPM package is still public.

I'm confused what the point of your comment is. If you can do it natively you can do it with React Native. "The jump" for any app from not including Rollout-style invocations to including them is the same if it's a React Native app or a normal native app, and these can all be determined by static analysis by Apple during the review process.

The point is, saying "RN apps only push JS" is disingenuous. The exact same technology is used to push JS, and that JS can do things that Apple does not like, RN or not. It appears everyone working in the RN ecosystem is hellbent to distance themselves from Rollout, but the gap is very small between the two technologies.

I make a library that pre-generates all of the native apple library bridges. Isn't that equivalent, but your 'explicitly bridg[ing] your own native methods'?

Could you provide a link to your library?

Seems like they now do : https://apple.slashdot.org/story/17/03/08/1355246/apple-begi...

"Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app's behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app's behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes."

Apple was concerns about dynamic execution of arbitrary native APIs (including private ones), which neither Expo nor React Native do (nor Cordova WebViews for that matter, they're all in the same family in this context). See https://news.ycombinator.com/item?id=13817957 and "A warning from Apple [resolved, not about React Native]": https://github.com/facebook/react-native/issues/12778

I think it was just apps that pushed updates for native code, and javascript updates are still fine (for now).

Reply on news.ycombinator.com