You don’t have to look very hard in the Objective-C Runtime Reference to figure out how to do things like get a list of all the registered classes, get all the methods for a given class, etc. From that you can generate a list of all methods. The runtime doesn’t care about which methods are documented, though, so in order to pick out the undocumented methods you’d also need to build a list of the documented methods, perhaps by scanning through the header files, and then compare the two lists.

I could see how all that might be useful if you wanted to build a tool that would warn you if you used an undocumented method in your own code. But then, if you don’t go snooping around in the runtime, the chance that might use an undocumented method in your code by accident is pretty small, so I’m not sure it’s worth all the bother.

Since, selectors are independent from the class you’re messaging, even
if my custom class defines -setOrientation: irrelevant to UIDevice,
there will be a possbility of being rejected.

There’s no prohibition on using methods with the same names as undocumented methods of Apple-supplied classes. What you’re not allowed to do is to call undocumented methods of Apple-supplied classes. The reason your app was rejected, presumably, was that you sent -setOrientation: to an instance of UIDevice. If you had instead sent that message to a class of your own creation, I don’t believe you’d have been rejected. I don’t have any inside knowledge, but I feel reasonably certain that Apple doesn’t detect the use of undocumented methods by simply listing the selectors used in your app.