Apple Store Review information request


#104

Rejected again. I spoke with Kelly @ Apple, and she basically refused to tell me which code is failing, but she did say that if you, Trigger folks, call them, they can work with you on specifics. They’re saying code was “disabled but not removed”, and “… we want developers to go through their own code to ensure they’re in compliance.” But again, wouldn’t tell me WHICH code. Useless, if you ask me, but hey… if Trigger folks call and speak to Apple reps directly, maybe this will resolve. At this point, I’ve had to pull my app and now my customers are screwed. My code is so stupid simple, I just don’t see how it could be anything I’ve written. But they wouldn’t even tell me that.

I’m seriously about ready to just pull the app not only out of the Apple App Store, but out of the Google Play Store and do everything via the site and let my customers’ complaints pile up in the corner.

Thoroughly disgusted with the whole damned app store process at this point.

Contact Kelly Hawley 408-974-1301 or App Dev general at apple at 408-996-1010

Good luck. I’m walking away from this pile of angst for a few days.


#105

Latest communique…

Hello Chris,

Thank you for your time during our call today.

As we discussed, your app was found to be out of compliance with App Store Review Guidelines 2.5.2.

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. It would be appropriate to review any third-party items that you have included in your app as well.

Please ensure that any code, frameworks, or SDKs that related to this issue are fully removed from the app and not just disabled.

We hope that you will consider making the appropriate revisions to your app and resubmit.

For code-level assistance, please consult with Apple Developer Technical Support. Based on your app, please be sure to include any symbolicated crash logs, screenshots, or steps to reproduce the issues encountered.

If you have any questions about this information, please feel free to contact me at 1-408-974-1301 M-F between 7a-4p Pacific timezone.

Best regards,

Kelley Hawley
App Store Review

Reference: CT 1655631


#106

I like how Apple’s answer is “just remove the sdk and resubmit”… like that’s even remotely feasible here in the real world, well away from the Apple Reality Distortion Field Effect.

(( sigh ))


#107

Based on the information in my post above ( Apple Store Review information request - paltform v2.5.2 ), we’ve submitted about 60 apps on Friday. They just went into review this morning and about half of it already got accepted. We had two rejections already, however they were not related to the code issues at all - so no concern here.

For us the issue seems to be resolved. Hope everyone else is seeing similar results soon! /cc @antoinevg


#108

Thank you so much for keeping us in the loop, having a phone number and name is absolute gold! I’ll be following up with Ms Kelley and see if I can’t get any more specifics out of her.

I’m almost 100% sure the problem doesn’t lie with your code Chris, if there were issues in your HTML/CSS/JS they wouldn’t be referring to native API’s.

Another piece of interesting information is that she said “code was disabled but not removed” - this doesn’t make a whole lot of sense if the problem is Reload as it was, indeed, removed entirely with v2.5.3.

That said, if the problem is not Reload, v2.5.3 did still contain a runtime safety check which may be why she’s still seeing a false positive. We removed this safety check in v2.5.4 and it may be worth trying to rebuild & resubmit your app with this version of the platform.

Of course, none of this explains why other apps are being accepted, but that’s Apple for you.

I’ve also prepared a general statement which goes into the technical details of the Trigger.IO platform and goes through a step-by-step refutation of each allegation made in the rejection notice:

It may be worth copying & pasting this statement in reply to the rejection message on iTunesConnect before submitting your new app binary.


#109

At this point I’m being pressured to rewrite the app in native code, which I am loathe to do for a few reasons: 1) time, 2) Objective-C is an abortive piece of garbage in terms of modern programming, and 3) supporting multiple code bases. I can write it in Swift, I suppose, but the underlying garbage that is IOS programming still exists.

Apple did a lot of people - customers and developers - quite a disservice by making this change with no clear resolution path already documented.


#110

PS… what version should I build on, right now today, to ensure that the reload and other arbitrary code exec stuff is removed from the Trigger.IO framework. Looks like the 2.5.5 reintroduces Reload…?


#111

v2.5.4 is probably the safest build to work with:

  • Reload has been removed entirely from the code.
  • Removed a safety check that uses respondsToSelector which might be responsible for triggering a rejection.

v2.5.5 is identical to v2.5.4 with the only difference being that it re-enables Reload for customers who aren’t having their apps rejected.


#112

Awesome, thanks. I’m also going to try to pare down any other frameworks.


#113

Submitted… here we go. #wishmeluck


#114

I just got off the phone with Kelley @ Apple:

  • She was ambiguous at best, claiming that they “have not determined whether the problem is with the customer’s code or ours.”
  • When I pointed out to her that the customer code is HTML/CSS/JS and does not contain any native portion she took my number and said that she will talk with the technical support team and see “if they would like to take a look at the Trigger.IO code”

So now we wait… we’re holding thumbs that your app goes through Chris!


#115

I know this may be anecdotal, but our other app was approved over the weekend, this was built on 2.5.2 with reload disabled… the only difference was that we used the tabs module with auth enabled… not sure if it’s the official branch or somthing @prudent crated as I saw he branched a few anyhow this seemed to work for us but again
. This is one massive mystery

I would say though the advances tabs may be somthing to look at because this can be vulnerable to man in the middle as advanced tabs allow js code to execute inside the window… the warning is on the docs I know but this may be somthing to look into


#116

My app was pulled into review already. :astonished:


#117

Given Apple’s “… disabled but not removed…” comment, I went with .4 assuming whatever they flag as bad won’t even be there. ## crossing fingers ##


#118

Wanted to also point out that I sent along the link to the document as part of the notes on this latest submission. Here’s hoping that helps. :slight_smile:

I really like the Trigger platform, and I really do NOT want to rewrite this app in native code for a lot of reasons, not the least of which is… there’s just too damned much on my plate to take on two new code bases ( IOS & Android, or IOS and maintaining the Trigger code solely for Android ). Really hoping Apple gets to the heart of the rejections and either ponies up REAL and useful information, or figures out that if Reload isn’t enabled, then it’s a total non-issue.


#119

:astonished: :astonished: :astonished:

holy. crap.

They just approved it. Nice. 2.5.4, including a link to Antionne’s web doc to apple.


#120

I know this is how I felt… but in all honesty, this whole thing made no sense, I feel you pain!


#121

FWIW, I’ve now had two approvals in as many days using Trigger 2.5.4, and the normal array of modules for a simple app with Pushwoosh notifications.

I attribute this to Antoine’s vigilance with Apple, his text / links to include in submissions, and the community keeping at Apple to get some real attention.

Thank you all for the assistance, and thank you Antoine for doing what you do.


#122

I’m not using Reload at all, so what’s the plan going forward to ensure that Reload isn’t / shouldn’t-be an issue with Apple. Will you provide parallel versions for people to use who want to steer clear?

Again, thanks!!!


#123

Given that a lot of folk aren’t having issues with rejections when submitting reload-enabled builds I’m pretty certain that Reload is not a problem in the longer term.

For now we’ll maintain both the v2.5.4 (without reload) and v2.5.5 (with reload) releases to be safe though.