I wonder if this is going to hit non native code push solutions like React Native? Or if Apple are going to start cracking down on apps like Facebook, Twitter or Pinterest that do a lot of A/B testing.
To date, Apple's Developer Program Guidelines states (in Section 3.3.2):
> Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
Personally, I think that Cordova hybrid apps will continue to be okay, but I don't know about something like React Native...
That actually makes it sound like it's OK to hot-deploy arbitrary new JS code to cordova/ionic apps like bug fixes and new features as long as you don't pull a bait and switch and turn your todo list into a camera or something.
Code push doesn't push Native code. I think Rollout uses swizzling to send native code over the air to your app and then uses JavaScriptCore to inject it into your app at runtime. This always seemed pretty sketchy to me and I could see why Apple would be annoyed by it (it allows you to push changes which can call private objective c apis).
React Native code push does not push any native code, just JavaScript. Out of the box it does not allow you to push code that can call private API calls at runtime.
This was my immediate question too. Microsoft offers a service called CodePush (https://microsoft.github.io/code-push/) for React Native and Cordova apps that presumedly could get caught by this. I don't have enough mobile dev knowledge to know whether or not it uses the same APIs that were mentioned in Apple's rejection letter, though.
Yep. I use code push in several apps. It's gonna be fun times next time I need to submit an app. I think it might be safe because it doesn't push native code and rollout is all about pushing native changes.
PM on the CodePush team here. The rejection notice seems to explicitly call out the native methods that are a cause of the issue. CodePush cannot inject private frameworks or expose any methods that React Native already exposes.
I would also recommend not using CodePush to completely what an app does.
Correct me if I am totally wrong here, but isn't the issue not with introducing new private frameworks or exposing new methods but with changing the behavior of the interpreted code that interacts with already exposed frameworks/methods? The relevant language seems to suggest that you could still be in violation of Apple's TOS if your script(s):
>change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
I believe the guidelines allow Js functionality like this as long as the functionality does not change. This seems like they are doing this for security reasons so I'd think React Native is different. Not sure though, someone else might know more.
Sure but a lot of React Native people use code push. I assume React Native is not affected as code push is just pushing JavaScript and not using JavaScript core to swizzle native code into your application like rollout does.
Can it call arbitrary native code? I think that's our probably going to be an issue if it can (I.e. If it can do loadFramework("baz").getClass("foo").callMethod("bar"))
I think in these instances the code is pushed in a build, and then toggled server-side. Enabling features server-side isn't against the ToS, but pushing new app code is.
