Apple Store Review information request


Hi! I’ve received the information request from Apple Store Review:

Feb 17, 2017 at 7:54 PM
From Apple
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

Any thoughts what all this means and what they suppose we should do?
Obviously they do not like that using platform we can update our app without getting them know…


This is the first time we’ve ever seen this for a Trigger.IO app!

Apple explicitly allow for updating HTML/JS content over the air so it’s highly unlikely that reload is causing the rejection.

What bothers me in particular is that they now consider respondsToSelector to be a “banned” method.

If they’re serious about that there are going to be a lot of folk rewriting their apps in the next few months as it’s always been the best way to figure out what features are supported on a given iOS release!

Either way, if you zip up your app’s src/ directory and send it to us at we’ll be happy to take a look and see if there are any obvious problems.


Hello, Antoine!
Just sent the zip you requested to you at

wasn’t some updates appeared by the topic meanwhile?

thanks for your help!


It looks like this issue has now gone live for folk in the wider iOS development community:

From the reports it looks like the only other apps affected are ones that have linked the library which specifically enables hot-swapping of native Swift and Objective-C code.

There are no reports of problems from folk using the reload functionality from Cordova/Ionic/ReactNative/etc. which gives me confidence that Apple are still honouring Section 3.3.2 of their Developer Program Guidelines that allow for the pushing of JS/HTML/CSS updates:

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.


This is good news as it means the problem is unlikely to be related to our platform or reload code and more likely to be a false-positive on the part of Apple’s rejection scripts.

We are still waiting for confirmation but our best theory at this time is that we had a call to performSelectorOnMainThread buried in an (unused) section of the code that was intended to provide support for Apple’s WKWebView and which is now triggering Apple’s rejection scripts.

I’ve pushed a new platform version to Staging that removes this call and was able to successfully submit a test app.

For now, if you’re affected, can you please try rebuilding your app against v2.5.2 of the platform and resubmitting.

If it’s still being rejected the problem might be in one of the 3rd-party libraries used by a native module.

In this case, can everyone affected please send me your app’s src/config.json files to so that we can start triangulating for common vectors?


I just received the same email.

You say you was able to submit the app successfully. You think the binary uploader step is what let you think it’s ok ? Or is it a human review that was success ?



Frustratingly, our test app did pass both the upload checks and review.


Status update: 10 March 07H00 UTC

  • We’re hearing mixed reports from customers with multiple apps where some apps are being accepted but others being rejected.
  • This supports a theory that the cause may be buried inside a 3rd party library used by one or more of the native modules.
  • We’re trying to triangulate the root cause by looking for patterns in app configurations but it’s a slow process as the rejection notice is only triggered after review and not submission.
  • We’ve reached out to Apple but are still waiting for a reply.

I’d like to thank everyone who is affected for their extraordinary patience and will keep posting updates as we learn more.


I just uploaded you the config.json of the .ipa that was active since the 2 Feb 2017 and for which we receive the notification problem this morning.

I hope it will help to triangulate the problem


Status update: 10 March 12H00 UTC

We’ve just heard from the first customer to be affected that they have successfully passed review after rebuilding their app against platform version v2.5.2

We’re still not 100% certain that the problem has been resolved for everyone but it does represent significant progress.


Mine is Waiting for Review. Binary upload was ok.


We have submitted a previously rejected application on v2.5.2 and have been rejected again for the same reason. Sending our config.json to support but happy to provide any other detrails here, too. Thank you


If I understand :

  • Your received a mail for your app on 2.5.1 telling you there is a problem
  • You submitted the same app on 2.5.2
  • BInary upload was OK
  • You reach the “Waiting For Review”, then “In Review”, then “Rejected” for the exact same reason than in the original mail ?

Another question : did you leave the “Reload” functionnality enabled (just for information, i know it should not be that)


Status update: 11 March 04H51 UTC

  • Apple are not only targeting new app submissions but are also removing existing apps from the store. This is the first time we’ve seen something like this happen in the entire history of the App Store.

  • Can customers who do not have active Trigger.IO subscriptions and who have had existing apps removed from the App Store please contact me at Once we’ve resolved the issue we’ll be making available a temporary “Go MakeItRight” plan that can be used to resubmit your apps free of charge.

  • We’re making slow but steady progress with Apple and have managed to persuade them to escalate the issue to a “Technical Investigation Request.”

  • At the moment resubmitting after a rebuild against v2.5.2 seems to be a coin toss with some apps being accepted and others rejected.

Can all affected customers please also send me the “Apple ID” [1] of their app to so that I can attach your app to the investigation?

[1] You can find your app’s Apple ID by logging into iTunesConnect and navigating as follows:

  1. Click on My Apps
  2. Click on your App
  3. Look under “General Information”, for example:


I also came across this thred on github with some other analysis

All signs seem to point to it being a code push related issue, but may be a false positive from IOS? Here is another thread talking about the same things, this one mentions how uses private function calls to do thing… I don’t think does that correct?


Great links, it’s good to have more data points from the wider iOS developer community, thank you!

The current consensus does match ours, that:

  • There is a problem with apps that use frameworks like and JSPatch and this is due to their ability to make runtime modifications to native iOS method calls after app submission.
  • There is not a problem with services such as Trigger.IO reload and their React/Cordova/Meteor/Microsoft/etc. equivalents as we only allow changes to the Javascript code and explicitly prevent modification of native iOS method calls.



So the app we resubmitted got rejected with the same response, would disabling reload help you think?


Thank you for letting us know.

It’s unlikely that it will make a difference as there are no reports of reload-like functionality from other hybrid app platforms being rejected and we have customers whose apps have been accepted despite having reload enabled.

Until Apple respond to our repeated requests for information we are in the uncomfortable position of still not having any idea of what the Trigger.IO platform is doing wrong.

That said, it can’t hurt to try and do a resubmission without reload.

In the meantime, can you please send me your app’s src/config.json and Apple ID to so we can add it to our case with Apple support?


I sent the app I’d yesturday, and I just sent the json


The app I submitted 48 hours ago and that is still “Waiting For Review” is with Reload disabled (I never use it, so I disabled it. I was enabled before).

I will tell you the result when I will have the review result

But as Antoine said, I don’t think it’s related to reload. I think about a false positive