Code Push is rejected by Apple again?

[kissmypiss]

I submitted a new update to my app and it is rejected by the 2.5.2 guideline and section 3.3.2 agreement. In particular, they asked me to remove all the classes related to Code Push ...

Does anyone see something like this before? The app on the Apple Store has code push installed ...

[NickToropov]

Hi @kissmypiss, we have several related threads regarding this, you can quickly observe them:

#748
#949
microsoft/code-push#415
microsoft/code-push#486

In short for today we are not aware if any apps were rejected due to code-push usage itself.
We are actively monitoring this and at that moment it turns our that none of these issues were really related to code-push plugin usage.

Also we do not recommend to use update dialog within your app, please take a look at this section for more details.

[kissmypiss]

Here is the reply from Apple @NickToropov and it mentioned code-push usage ...

Guideline 2.5.2 - Performance - Software Requirements

Your app, extension, 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 App Store Review Guideline 2.5.2 and section 3.3.2 of the Apple Developer Program License Agreement.

Specifically, it would be appropriate to remove any and all code updating or feature change-capable features from this app before resubmitting for review including, but not limited to the following classes: CodePushDownloadHandler, CodePushPackage, CodePushUpdateUtils. We look forward to reviewing your revised submission.

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. This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior and/or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.

[atticoos]

Any updates on this @kissmypiss? We're closely following this issue, as we're preparing an upcoming release.

[carloscuesta]

I released an update of an app that uses CodePush last week and had no problems 🤔

[atticoos]

Thanks for sharing @carloscuesta!

[Zakeelm]

@kissmypiss

As @NickToropov pointed out, we've never been aware of any issues where CodePush is the root cause of App Store rejection. We have several apps in the App Store using CodePush that have never had this issue. This is very interesting because CodePush use doesn't violate those guidelines. Can you give us some additional details on your app and how you're using CodePush?

[Zakeelm]

Going to go ahead and close this as i've not heard from you @kissmypiss . No one else seems to be having this issue. Please follow up in this thread if this continues and we can re-open this.

[rodrigoalmeidaee]

Hi @Zakeelm ,

We recently got our app rejected by Apple in a scenario similar to that of @kissmypiss (however I do want to state that we had about 15 previous releases, with code push enabled, approved by apple). Apple complained about 2.5.2 guideline and section 3.3.2 agreement. We replied to them and they responded to us pointing to codepush explicitly, here is the message exchange for reference:

Our response:

Hello,

Thanks for contacting us, but we're unsure on how to proceed about making our app compliant with the guidelines, since we haven't included any major changes since our last approved release.

Regarding the Guideline 2.5.2, our app is built using React Native (currently we're using v0.55) and we use CodePush to deploy small Javascript bug fixes (we haven't updated or changed anything regarding our CodePush usage in the latest release). Our only native code changes were adding a handle to the applicationDidReceiveMemoryWarning event and updating our Intercom SDK version (from 4 to 5). We also have removed an unused UXCam dependency. The third-party libraries (other than the React and React Native dependencies) we're using as of this latest release are:

Amplitude Analytics
Crashlytics
Mixpanel
OneSignal
Sentry
CodePush
Lottie
Realm
React Native Permissions
RN File System
RN Intercom
RN Image Resizer
RN Version Check
RN Linear Gradient
RN Fetch Blob
RN Vector Icons
RN Image Picker
RN Background Timer
RN Splashscreen
RN Zip Archive
RN Document Picker
RN Camera

None of these are new dependencies, however. And since our CodePush usage adheres to the guidelines for downloading interpreted code (the code is downloaded and run by the JavascriptCore, and is not used to enable new features or functionality) we're not sure how we're violating this guideline, and would be grateful if some more information could be provided to help us address this issue.

Thanks

Their follow up:

Hello,

Thank you for your attention to this matter. When reviewing your app, we found a CodePush based download of several megabytes of Javascript code. This included what appears to be major feature code paths. Even if these are currently identical to in-app-bundle content, the sheer breadth of capability is a concern. It would be appropriate to revise the app’s mechanisms for any sort of dynamic code modification or replacement to fall more clearly within the lines you have stated. We look forward to reviewing your revised app.

Best regards,

App Store Review

We are not sure if, as our app got bigger, it ended up triggering some automatic alarm over there, or if we got unlucky and our app was reviewed by someone less prone to allow code push to be used. We will remove codepush from our next release and see how it goes, and may try to reintroduce it in the future as well.

One particular thing that seems hard to deal with is they pointing out that the "sheer breadth of capability is a concern". It is actually true that we could basically wipe out the entire app and push something entirely different there if we wanted. Apple does actually have to trust us that we indeed use it only for bugfixes. There isn't a structured way to plug code push in that would, by design, ensure that only bugfixes and small changes can be shipped, right?

For now, just posting here in case others are having similar issues 🙂

[rodrigoalmeidaee]

Just FYI, Apple approved our app after we removed codepush. The total delay was of about 2 1/2 weeks (this includes the time they took to respond to us on why they rejected our app, since their initial assessment was quite vague, time to strip out codepush out of the app, and time for them to approve the revised version without codepush, which took much longer than usual due to the previous version having been rejected).

We still think the rejection was an isolated incident due to the large number of previous releases which had codepush on them and were approved, but we're not sure we will bring codepush back, since, if rejected again, it could introduce another significant delay in the release process as a whole.

[jackmew]

I use codepush and receive this information..

[kira1928]

Hi @rodrigoalmeidaee ,

Thanks for your information!
I think your reply is very important, but it's ignored because it's under a closed issue.
Could you resend it in a new issue so that more users and code-push developers can notice it?