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 i

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

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 3

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 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.