3 ms·

Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using Objective-C's reflection capabilities), while React Native and Ionic/Cordova WebViews req

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.

LeoNatan25 10y ago
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-from-pure-javascript-in-react-native-1fb6afcdf57d#.60pyo15vg 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.
- brentvatne 10y ago
  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.
  - LeoNatan25 10y ago
    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.
mahyarm 10y ago
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'?
- leonatan 10y ago
  Could you provide a link to your library?

LeoNatan25 10y ago

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-from-pure-javascript-in-react-native-1fb6afcdf57d#.60pyo15vg 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.

brentvatne 10y ago
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.
- LeoNatan25 10y ago
  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.

mahyarm 10y ago

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'?

leonatan 10y ago
Could you provide a link to your library?