Warnings on the use of jsPatch

Hi,

We’ve noticed that many iOS developers received warnings (as cited below) from Apple on March 8. We’d love to know which actions may cause such warnings. And will these actions cause app rejection or removal?


About our app, we are planning to use the open source software jsPatch as a bug fixing tool by downloading js files online, which won’t bring any changes to the original app functions. (The working mechanism of jsPatch is downloading js files online and running by loading the JavascriptCore in the app. Its official website: jspatch.com). Meanwhile, all the file transmissions are made via https. To ensure our app security and integrity, the files are signed at the sever side and signature verification is needed for loading at client side. Is our current method in compliance with Apple’s policies? Is there any possibility that our app may got removed from App Store or rejected by App Review?

Runtime methods like respondsToSelector:, performSelector:, method_exchangeImplementations, class_replaceMethod and class_addMethod are all provided by Apple, which are largely used in many current apps and third-party libraries. Is the calling of the above methods allowed by Apple? Is there any possibility that our app may be removed from App Store or got rejected by App Review because of using them?

About open source development framework like ReactNative and Weex, they are both operated by downloading js files and operating with JAVAScriptCore. Does Apple allow the using of these frameworks? Will it cause the rejection or removal of our apps?

Thanks in advance.

Ref: The warning mail we saw online


Dear Developer,

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

Please perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review.

Best regards,
App Store Review

Replies

You may have to wait to find out if your particular implementation will be suspect. Watch your email.


From the 'net:


"hot code push", a feature that allows developers to continuously deploy changes to their mobile apps and have those changes reflect in their apps instantly. This allowed developers to make quick changes to their apps without having to resubmit the new iteration and get approval from the Apple Store review team. But that's changing now. In response to a developer's query, Apple confirmed that it no longer permits "hot code push."