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