Apple Store Review information request


I should note: I have a stupid-simple application that literally just fetches a couple URLs, and formats data in some spiffy DIVs for display to the user. Uses the following modules, and has been quickly and easily approved previously:

Latest platform, etc., yada yada yada. :frowning:


Interesting, this is a new variation of Apple’s communication on this topic that we haven’t seen before.

This is good because it reinforces the theory that the root cause is due to a false-positive rather than anything intrinsic to Trigger.IO’s code.

We certainly don’t take Javascript and turn it into native code and our architecture is designed from the ground up to protect against access to any possibility for native code access which is not already compiled into the submitted app.


PS… I’ve also engage the Pushwoosh folks, hoping to get a clear answer from them that they’re not doing anything that Apple considers a violation. I’m actually kind of thinking of removing Pushwoosh and notifications altogether and submitting again if this latest one gets rejected, just to see and satisfy my own curiosities.

Here’s the latest from Pushwoosh on my request:

Ivan Dedov (Pushwoosh)
Mar 15, 21:07 BDT

Hello Chris,

Thank you for contacting us!

Please note that I have passed your query to our developers responsible for Trigger module and will get back to you as soon as they respond!

I look forward to hearing from you soon!

Kind regards,
Ivan Dedov
Pushwoosh Team


Not sure if it helps or not but I have some old apps that had the parse module and they got flagged as well


5 posts were merged into an existing topic: Migrating To The Open Source Parse Server


I received the same message as chornbe after submitting Antoine’s recommended message.

Thank you for your response.
The code referenced in our initial rejection message is designed explicitly with the capability to change your app’s behavior or functionality after it has been approved to the App Store. 
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 is considered not appropriate and needs to be removed from your app’s binary. Even if the code is not intended to be malicious, the security risks it poses to users is significant.
To ensure your users are protected, perform an in-depth review of your app and remove any code, frameworks, or SDKs that facilitate the functionality outlined above. Specifically, it would be appropriate to remove any features or functionality which takes javascript script and turns it into native code. This is especially true if the script-to-native-code feature can occur using remote scripts sent in after an app's review is completed. 
We look forward to reviewing this app once the feature change framework is removed.
Best regards,
App Store Review


Well, then building with the new platform with reload removed should work…


And I got this back from Ivan @ Pushwoosh…

Hello Chris,

I have just heard back from our developers. It would appear that Apple have toughened their security policy not so long ago, for it is a first time we encountered an issue like that.

We have found a couple of spots to check up on and are investigating further at this very moment. I will personally notify you as soon as there are any news.

I look forward to hearing from you soon!

Kind regards,
Ivan Dedov
Pushwoosh Team


Thanks. Very interesting update

Could it look like something this

  1. Apple found a problem with apps built with
    => All apps built with are FLAGGED red and receive the mail (the 9 or 10 March)

  2. Apple fine tune the detection and point to the Pushwoosh plugin.
    => Apps with without Pushwoosh are Unflagged (sunday), like my apps (using Parse)
    And review is ok for next release like I did (tuesday)

=> Apps with Pushwoosh still have problems

I don’t know if it’s so simple.


While I would love for this to be true, I have apps that used granted old but the original parse module that were flagged and some that use pushwoosh and we’re not flagged…

I’m going to build against the new release and hopefully it passes fingers crossed


Our apps, besides content loaded in an iframe, are identical. We’ve re-submitted about 10 of them, some with pushwoosh included, some without. All on v2.5.2. Some have been accepted and some have not, there seems to be no connection to the presense of the pushwoosh module or not. It appears arbitrary.


Thats the scarry part… when a company arbitrarily enforces policy that is, from what we can tell a false positive with no insight into what is causing it is frightening…

I mean I get it, we all have privacy policies and the like but to be at the whim of apples iron fist is not fun and having grovel at an appeal is ridiculous!


So this is a little odd but if you resubmit, while its waiting for review it appears to remove the warning… not sure if it’s just a display bug or what but as soon as I submitted for review the flag went away…


Status Update: 16 March 2017 15h45 GMT

It’s now Day 8 since this blew up and I know we’re all starting to despair a little at the utterly random behaviour we’re seeing from Apple’s review process.

That said, here are two reasons for optimism:

  1. It’s become clear, beyond a shadow of doubt, that there exists no pattern as to whether apps will be accepted or rejected. If there was a problem with either the Forge platform or customer code then multiple apps with identical native configurations and customer code would ALL be rejected, but this is not the case.
  2. We’ve received the first confirmation that Apple are aware of our repeated attempts at communication.

Following a a long phone conversation with Apple Developer Program support last night (Tx @mknox81!) we received this email today:

It’s a pretty typical Apple communication, acknowledging your feelings without responding to any of your concerns, but after we decode it with our SecretSteveDecoderRing™ it basically reads:

  • Apple acknowledge that we have made multiple attempts to talk with them.
  • Apple confirm that there is a formal review in progress.

This is good.


When you talked to them on the phone, did they say anything of value? I submitted a build with reload removed so we will… just wondering if they had anything of value to add…


So I submitted my app again, with the 2.5.3 and it went into review and then after like 2 hours I got a message of rejection again, this time with a little different response

  1. 5 Performance: Software Requirements (iOS)

Thank you for your follow up questions.

We have re-reviewed this app and found that it contains features which are able to change its behavior after review due to a hotpatching framework embedded within it. It would be appropriate to remove this framework entirely in the next resubmission.

Additionally, our re-review uncovered private API abuse located in this app’s hackishlyFoundBrowserView method which checks for a non-public selector, which is considered a 2.5.1 compliance concern. It would be appropriate to remove all “hackishly” classes and methods from this app before resubmitting for review.

We hope you will consider making the necessary changes to be in compliance with the App Store Review Guidelines. Thank you in advance for your cooperation and we look forward to reviewing your revised app.

Best regards,

App Store Review

There is the new item of hackishly, I have no clue what that is, anyone else see that?

As far as a hotpush framework… I have no idea what they are talking about!


This is great, we can work with this!

v2.5.3 completely removes our Reload implementation from the platform so Apple are in error when they say there is any kind of hot-patching framework embedded in it.

There also isn’t a hackishlyFoundBrowserView method anywhere in our platform code or any of our public modules.

Do you have any private modules enabled for your app?

Can you please send the following to

  1. The src/config.json file used for the build you submitted
  2. The src/identity.json for your app
  3. The ipa file you submitted for your app



I just sent the data to you. The only private module I had was ionic_keyboard but I only call this if its android but maybe it has something in the binary?

Also, something that I found kind of odd… I had another app that I submitted and went into review yesterday, as usual they rejected it with the same 2.5.1 issue, this was built with platform 2.5.2, but they said that my app required a login and sent me a screenshot and it was the wrong app, I replied back to them that the screenshot was the wrong app but have not gotten a response. I guess the part that is concerning is that what if they are reviewing the wrong app all these times, I mean sounds crazy but yah was a screenshot from some app called unit4 expenses anyhow maybe something maybe nothing…



I did a scan and the offending module is indeed ionic_keyboard.

The Ionic team also ran into this issue last year:

It looks like they fixed it here:

Are you using Andres’s port of the ionic module?

It looks like there’s already an open pull request on the module which integrates the upstream changes:

Either way, I’m dying to hear what happens if you remove it and resubmit!


I don’t know if it’s the reason of our problems, but 10 days ago, when mess begins with our apps, someone post this on Apple dev forum :

“I had my app rejected because of ipv6 compatibility. However the app that Apple reviewed was NOT the app I submitted. They reviewed some other app and even included screen shots of the other app to show where it crashed”

Maybe users still impacted with rejected could ask screenshot in reply to App rejection. Could be a way to understand if the app rejected is really the good app…

Just an idea. I say this because it seem quite random and still unclear