There is no way to answer the question "will Apple allow it?" You have to pick your risk tolerance and submit. Personally, I stay away from things that are undocumented. But in the cases that I do enhance my programs with things on the edge (generally undocumented things that are not actually private), I try to make my program resilient to changes.
One major way to do this is to check whether the thing you're about to link to or function you're about to call exists. For methods, you can use -respondsToSelector:
before calling it. For functions, you can test whether the function exists:
extern void SomeFunction() __attribute__((weak_import));
if (SomeFunction != NULL) {
SomeFunction();
}
(You'll need to test that out on iPhone; I use it on Mac, and weak_import
should be portable since iPhone uses GCC4. See Ensuring Backward Compatibility. So far, I've always been able to find some trick to avoid actually needing this on iPhone.)
The key to all of this is to make sure your program functions without the undocumented feature. That way, even if Apple rejects it, pulling it out is trivial.
That said, for me this is a last resort for things I've spent a lot of time trying to do in a documented way, for things that provide a significant improvement to the user experience, and don't violate Apple's basic intent. For instance, running in the background, even if you can get it to work, is a clear violation of the spirit of Apple's rules; other things are private just because they haven't been made public, like the internal views of UI elements.
Changing the screen brightness in a way that persists outside your app would seem a violation of the basic rules of play (stay in your sandbox). Getting the current screen brightness doesn't sound like that (though I'm not sure what you would do with it.)