JavaScriptCore executes javascript embedded in the app, it's not like a webview that would download an arbitrary webpage/script, so it wouldn't conflict with the guidelines

Yeah thats how the Groups app works now, but I was referring to his forward thinking "server-side run native apps". Thats way different.

They just need to send the UI "state" (and after that just the state diff would do it). I think it's actually much like HTML for a browser.

The executable code limitation is likely geared toward security. For all other purposes, it's just data.

Well yeah, both are for security. But if you had a native "app server", that just fed JS to a shell of an app that had ReactNative in it....you could completely change the app, remotely. Not just styling too, but actual functionality. Its the promise of "real" native A/B testing, but clearly violates app store review guidelines.

We submitted an app a while back (mid 2012 I think) that ran a dynamically interpreted language developed in-house. The objective-c codebase was fairly small, nearly the entire app was written in this language stored in external files. Right before submission we decided not to risk being rejected for the reasons cited, and instead baked-in the scripting files, but clearly kept open possibility of remote load for future submissions. We got accepted without issue, but that app ended up being decommissioned and we haven't revisited the approach. Sometimes I wonder if Apple would have let our original submission through if we remote loaded the code instead.