Of all the strange and convoluted restrictions facing developers, the use of private APIs is perhaps the least contentious. Private APIs are programming functions that Apple does not document because they’re not considered “stable”—the way they work may change in future releases of the iPhone SDK, for example, or they may disappear altogether. Developers are urged not to rely on these interfaces for key functionality of their products, which makes sense for the most part—you want to build your house on a solid foundation, not a pool of quicksand.

And yet, exceptions have long existed. Google Mobile App was one of the first to slip into the store despite its private API use: the app can trigger its search-by-voice function when you hold the phone up to your ear, thanks to information gathered by the iPhone’s proximity and ambient light sensors. But despite Google’s admission of its transgression more than a year ago, the app is still in the store—in fact it got updated just this week.

But on to a far more curious case. Vimov, the developer behind iSimulate, submitted an update to its program recently, and Apple approved it even though it contained a private API. Vimov posted Apple’s e-mail response on its blog and, while it starts off like so many of the App Store rejections we’ve seen in the past, there’s a surprise ending that you won’t see coming. (Well, you’ll see it now that I’ve told you.)

Thank you for submitting your update to iSimulate to the App Store. During our review of your application we found it is using a private API, which is in violation of the iPhone Developer Program License Agreement section 3.3.1; “3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.” While your application has not been rejected, it would be appropriate to resolve this issue in your next update.

The non-public API that is included in your application is UITouch._touchFlags.

Please resolve this issue in your next update to iSimulate.

Clemency? From an App Store reviewer? It’s a Christmas miracle!

It may seem like a small change, but it’s a significant one. As Vimov points out, not rejecting the app has a very real benefit: instead of having to once again go through the review process, tacking on what’s likely to be another couple of weeks of waiting, the developers can simply fix the oversight in the next update they submit. In this case, the API in question was included in old code that was supposed to have been removed, which Vimov has now done.

It remains to be seen if this is a wide-reaching policy change, but as the old journalistic axe says: one is a fluke, two is a coincidence, and three is a trend. If the times are a-changin’, I hope this reasonable leniency extends to other situations as well.