https://devforums.apple.com/thread/34908?start=0&tstart=0

maybe after reading your blog? ;)

But, seems some app is still being rejected

http://www.drahtwerk.biz/EN/Blog.aspx/Submitted-Rejected-and-Approved/?newsID=44

why some apps using UIGetScreenImage() (e.g. redLaser, ShopSavvy, GoodGuide) are approved, but some are not?

It all goes down to risk management: you can save time and effort (read – money) by skipping research part of how to replicate built-in functionality and just use it via private API, but doing so you are risking to get rejected by the reviewers. And when it does happen why not the person who took the risk takes the blame? If you want your app into the store, you know what to do, so what’s the problem?

The no private API rule is perfectly clear. And it makes sense too as the transition to 3.0 has shown, when lots of apps got suddenly broken ’cause they used private API calls which were no longer there. Of course, if you are in for a quick cache you don’t want to be bothered by such things as continuous user support and long development cycle. Then yes, Apple reviewers are bad.

In the end I want to say that Apple won’t change this rule. The whole software development in the company follows this model: introduce private APIs and test them. Due to the dynamic nature of objective c there can’t be ‘private’ API per se, all methods are too easy to spot. But the undocumented API is subject to change and not guaranteed to work, it is there just for internal testing purposes. So, using this API developer puts the future wellbeing of his app at risk – any update could be fatal. Not the best practice for software development? Maybe. But it works well for Apple. They’ve no reason to change it.

P.S. If you want to see a real draconian review process, check out other mobile platforms.

I understand the distinction you are trying to make. Despite that, anything that does not appear in the headers distributed with the SDK is private. It doesn’t matter whether the symbol appears in UIKit or one of the private frameworks. Your claim is effectively means that so long as you need to don’t need to link against private frameworks then anything you do is public, just “undocumented.” Follow that to the logical conclusion: If you really believe that then you can just run nm against UIKit and call any symbol you see, and Apple has to support that. Do you really think -[EmojiScrollView initWithFrame:] is something you should call? After all it, is in UIKit and not in a private category, so it is just “undocumented.”

It is a bogus argument, and it weakens what is an otherwise good post about capabilities you could use if Apple exposed them.