Are performSelector and respondsToSelector banned by App Store?

Question

My latest build was accepted into the Apple app store, but I got the notice quoted below a couple of days later.

My app also uses Rollout.io, and I asked explicitly if this was the problem. No response yet.

If respondsToSelector or performSelector are banned, are there any replacements?

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.

EDIT: Apple forum mentions this: https://forums.developer.apple.com/thread/73640

Answer 1

It is not respondsToSelector:, performSelector: that are banned. The ban is on putting dynamic content as a parameter to this method. For example, this is not banned:

if([self.delegate respondsToSelector: @selector(myDelegateMethod)]) {
   [self.delegate performSelector: @selector(myDelegateMethod)];
}

However, this code might be banned:

NSString *remotelyLoadedString = .... (download from your backend)
[self performSelector: NSSelectorFromString(remotelyLoadedString)];

Answer 2

On March 8th 2017, Apple warned all the developers of JS injection. This includes libraries like:

• JSPatch
• Rollout.io
• AMapFoundation as it includes JSPatch [edit: they now provide a new version without it]
• Bugly as it includes JSPatch [edit: they now provide a new version without it]
• GTSDK as it includes JSPatch [edit: they now provide a new version without it]
• ...

If you are directly using a service like JSPatch or Rollout.io, you should stop using it.

If you are using a third-party that was depending on JSPatch indirectly, you should request an updated version of your third-party that does not include JSPatch anymore.

Answer 3

dlopen

dlsym

respondsToSelector

performSelector

method_exchangeImplementations

Sometimes some people used to think all above methods are banned but the exact issue is, those methods are restricted to use parameters that are generated at runtime. For example,

when we use,

SEL selector = NSSelectorFromString(@"stopProgress");

Its allowed, but

when we use,

SEL selector = NSSelectorFromString(@"%@", runtimeFunction);

Its not allowed!

Answer 4

The app store notice told you exactly what the situation is.

The functions in question are not banned. What is banned is using those functions to circumvent the app store review process and do things like call private APIs or download and execute code. App store apps are required to have all of the code that they run compiled into them. They are also not allowed to use private APIs from iOS. If an API isn't documented, it's off limits.

My guess is that you know exactly what they are talking about, and you are trying to bypass the rules.

If you are not calling private APIs, downloading scripts and using performSelector to call them, then you should submit an appeal to the app review board, explaining what you are doing, in detail, and how it is not a violation of the app store guidelines. If you're truly not breaking the rules and have a legitimate reason for what you're doing then you will very likely be able to get your rejection overturned, but you will need to offer full disclosure and a compelling argument as to why what you are doing is not breaking Apple's rules.

Their field, their ball, their rules. If you're not willing to play by Apple's rules your only real alternative is to try to distribute your app for jailbroken devices, but that will likely cost you your developer program membership.

EDIT:

Based on your comment below, it sounds like the problem is that the framework Rollout.io that you're using is doing js injection, which Apple now bans. I suggest searching on "Rollout.io iOS app store ban" or similar.