Apple Store Review information request


#64

I think I’m using that one, I only use it for android but it must still be in the binary so they flagged it… I’ll remove it an try again, although I’m still not sure on the hotpatch issue.

It’s like beating a dead horse, you tell them the sky is blue but they are lIke no, it’s green… but no really it’s blue… but no my script says it’s green see…

Anyhow I’ll see how this one goes!


#65

I just spoke to the support team on the phone and they are going to recommend it be reviewed again based on the wrong image. Hopefully I will hear something soon and it will be approved but we will see


#66

Status Update: Saturday, 18 March 07h38 GMT

  • We’ve received a response to our appeal from Apple which provides a new fragment of information around the permissible uses of respondsToSelector and performSelector:

  • If our interpretation of it is correct I’ll provide a more in-depth analysis later but the short version is there’s a slim possibility that an integrity check performed by our Javascript/Native bridge to protect against the exact behaviours Apple are trying to prevent may be responsible for the rejections.
  • I’ve pushed a new platform version v2.5.4 to Production which removes this check.

Current Recommendation

  • If your app does not use the pushwoosh module, custom native modules developed in-house or reload, can you please resubmit your app for review after rebuilding it against Forge Platform Version v2.5.4 and let us know what happens?

#67

What is the significance of pushwoosh?


#68

There might be an issue with the pushwoosh module. Their team is busy investigating.


#69

Wouldn’t you expect others to have the same issue then?

Also from what I have read here both apps with pushwoosh and without have been rejected…

Just a question, do you feel this will get resolved soon? I have apps that need to go up, otherwise it’s going to cost me so I’m just trying to prepare.


#70

No that is helps but the latest reply from apple when I asked if there is any way to provide more information about what might be causing it was

Hello,

Thank you for your reply.

It would be appropriate to remove any features which are capable of changing an app’s behavior after review. We can offer no more additional detail at this time.

Please make any changes you see needed to bring this app into compliance with the App Review Guidelines, then resubmit your app for review.

We appreciate your cooperation and look forward to reviewing your revised app.

Best regards,

So basically, we don’t know whats causing it, but hey remove it… Ohh ok. :weary:


#71

Not to spam stuff but here is another message, this was from a different app, mentions the same thing though

Performance - 2.5.2

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

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.

Next Steps

Perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above and resubmit your app’s binary for review.

We look forward to your resubmission.

Best regards,

App Store Review

Seems like there is a little more detail… anyhow, could this be related to pushwoosh? I mean I have apps that used parse that were rejected as well but they were older apps that had facebook parse so who knows, anyhow this was with 2.5.3 so no reload was enabled.


#72

With just that short and strange response from Apple, Reload seem to be completely forbidden… As it can completely change the application from the ground.

The “We can offer no more additional detail at this time” is quite difficult to listen because it mean “we know what is not correct on your app, but we will not tell you”…


#73

The odd part is, reload was removed with 2.5.3, this is what I built with this last go around. Next to is to try removing pushwoosh and build with 2.5.4 and give it another go… It is very frustrating though as apple seem not give two flying things about this.

But what is it with trigger.io that would cause this vs say cordova, I mean that is the hard part is that they don’t seem to be having the issue and react nave code push is similar to reload and does not have any issues that I have seen so this leaves it at something in how trigger.io works OR its a module… anyhow I’ll keep trying…


#74

could it be that Cordova is “whitelisted” on Apple side (because open source is known by them)…
Antoine proposed them to access code, but you know them. It takes time.
So complex situation…


#75

Hey Antoine, I removed pushwoosh and put in parse and have resubmitted with this version, ill let you know what happens


#76

Just to add a little more, seeing some other forum post about a similar issues

This is with react native…

One interesting this is the mention of javascript code being converted into native… that was from 9ne of apples response…


#77

Status Update: Monday, 20 March 19h30 GMT

  • Our test app built against Forge v2.5.4 is still waiting for review.
  • We’ve heard back from one customer who has resubmitted using v2.5.4 and had their app rejected after review.
  • There was no new information in the rejection notice and I’m adjusting our current recommendation to temporarily exclude any modules that rely on 3rd-party code outside of Trigger.IO’s control.

Current Recommendation

  • If your app has been rejected after resubmitting with v2.5.4 and contains any of the following modules:

  • apptentive

  • barcode

  • bolts

  • facebook

  • flurry

  • kumulos

  • parse

  • pushwoosh

  • segmentio

  • urbanairship

  • Any custom modules which are not listed on the official module catalog at: https://trigger.io/modules/_/all/

  • Please remove these modules (temporarily!) from your app’s configuration and rebuild before resubmitting.

  • Even if removing the modules breaks your app it will tell us a lot if a subsequent rejection notice complained about broken app functionality rather than the “Performance - 2.5.2” rejection.


#78

Did the customer who got rejected use those modules listed? The forum post from rn reads similar to our discussion, some approved others rejected with complete bewilderment from the community and a silent apple…

So here is a question. Have you been able to get a vanilla trigger.io app approved? It might be faster to just build a few basic apps, then submit all of them at the same time each with x modules. At least that way you are getting more test scenarios in there


#79

Oh wow, I’d just come across this and was going to post it when the forum software warned me that you’d beat me to it :slight_smile:

The developer is using a pile of 3rd-party libraries that could be causing the rejection so it’s a bit early to tell if this is linked to our issue or not.

That said, we’re going to be keeping a very close eye on the conversation!


#80

Some of them: bolts, parse & facebook.

Very few folk were directly affected by the rollout.io/JSPatch issue but a LOT of people are still way spooked by the viciousness of Apple’s response even though what those libraries were doing was really stupid and dangerous. (See, for example: https://iosdevweekly.com/issues/291#start)

Our test app has a few versions, including a vanilla one. Apart from the first approval (which got rejected with the next update) they have either all been rejected or are still waiting for review.

I can’t begin to tell you how much everyone’s willingness to share their configs is helping us narrow the search space!


#81

Yah, I’m scanning the net trying to find anything I can :grin:

So just a quick questi9n, your code review showed no calls to the ‘said’ function apple listed, but did that only include modules from trigger.io?

Also, from your list you have barcode… is that not a module created by you?


#82

We did a full review of all 3rd-party libraries used by our modules as well but at this stage of the process I want to focus only on code which we wrote and understand 100% what it’s doing.

After we can reliably pass review within those constraints we’ll start extending the search space again.

It makes use of https://github.com/TheLevelUp/ZXingObjC for barcode image processing.


#83

What is interesting is that your first app got approved but updating it was rejected… was anything really changed?

I noticed that some of the new apps with no updates did not get flagged while updated apps do get flagged. Not sure if that means anything… anyhow I’ll report back on how the re iew goes when it happens…