iOS Apps Using Private APIs
I'm actually very surprised this hasn't happened years ago.  The power of Objective-C's runtime has always made this pretty straightforward.Apple can defend against unauthorized calls to even runtime-composed method names though.  I can think of a few ways.They could move as much "private" functionality as possible outside of Objective-C objects entirely, which requires that you know the C function name and makes it obvious when you've linked to it.  This should probably be done for at least the really big things like obtaining a device ID or listing processes.Even if they stick with Objective-C, they could have an obfuscation process internal to Apple that generates names for private methods.  Their own developers could use something stable and sane to refer to the methods but each minor iOS update could aggressively change the names.  If the methods are regularly breaking with each release and they're much harder to find in the first place, that may be a sufficient deterrent to other developers.They could make it so that the methods are not even callable outside of certain framework binaries, or they could examine the call stack to require certain parent APIs.  At least that way, if you want to call a private API, you have to somehow trick a public API into doing it for you.And, I think Apple does say somewhere that developers shouldn't use leading underscores for their own APIs.  They could hack NSSelectorFromString(), etc. to refuse to return selectors that match certain Apple-reserved patterns in all circumstances.