by sunny » Sat Jan 02, 2010 8:41 pm
for example you could want disable scrolling of your webview programmatically instead of doing that in html, in this case you would loop though webview subviews and get private Apple's subview which is responsible for scrolling and call method which disable's scrolling. The information on what method to call is private and not available in documentation, however if you are a little hacker it's pretty easy to obtain the list of those methods (so called, private APIs), and then call needed method (let's assume it's called "setScrollingDisabled") which will cause your application to be rejected. As long as you use documented APIs your application can not be rejected, to check that you can search for every method in your code if it is available in documentation, if it's there it means everything is ok.
Also there is another way to get rejected due to private APIs, let's assume you have no idea about names of private APIs and you write your own method which has only clean documented code. If somehow the name of your method will be the same as name of any private API your application will be rejected. This happens because Objective-C architecture, you can not know what object method was sent to, that's why Apple's bans everything. I once got into trouble because of this, many programmers would name method "setParameters" if they need to set parameters in that object and then they get rejected (?!), one of Apple's private APIs names also setParameters and there is no way to know if I'm using my own method or private API, ofc Apple would not bother investigating deeper, so they just reject. After this I always name my methods with product specific codes like "NK", so setParameters became setNKParameters and so on.
