App Rejections

According to Apple reviewers, the word “deprecated” (which usually has a specific technical meaning) is now a synonym for “private” (which usually has an entirely distinct meaning):

games being rejected based on “a private API”, which is funny because its actually an Apple OS API function that has merely been deprecated – they just like those words at the moment it seems.

From the apple docs :
“The copyPath:toPath:handler:, movePath:toPath:handler:, removeFileAtPath:handler:, and linkPath:toPath:handler: methods have all been deprecated as of Mac OS X v10.5.”

That from the Torque 2D iPhone project (I think; as opposed to the iPhone version of Torque. Yes, it’s a bit confusing. Go ask Garage Games, don’t ask me).

The developers of Telnet Meter report a similar experience as users of Google Toolbox for Mac (which is also intended for use on iPhone) – but I can’t find *any* official mention of this in the GTM bugtracker or mailing lists. I checked their source code, and they’re using the deprecated methods in many, many places, so it seems likely they’re affected too.

And yes, today we got another rejection letter from Apple – this time stating we used another non-public API (removeFileAtPath:handler:), this time introduced by the Google Toolbox library. Why-o-why couldn’t they (=Apple) report the Google-Toolbox-non-public-API the previous time? This costs us yet another 2 weeks of approval time. Is it so hard for Apple to report all non-public APIs in 1 go? Can’t they release the static analyzer they use, in order for us – developers – to check this prior to submission – gaining time for us and them? As more an more libraries become available, it gets harder and harder to make sure no ‘illegal’ API calls are used within those 3rd party libraries.

So, fashion-fans: for this Winter 2009 season, Deprecated is the new Private.

Developer thoughts

For all you non-developers, the specific technical meaning of Deprecated is, roughly:

Deprecated: this code STILL WORKS, but we would PREFER that you stop using it. We reserve the right to REMOVE/DISABLE it in a future official release, but until that time it is VALID and ACCEPTABLE.

(or, to quote from Google’s “define: deprecated” … “a construct in a computing language considered obsolete but still available”)

Deprecation is about saying: we told you to use this method, and promised it would work. We mustn’t renege on that promise, but we’ve made a better version that is a 100% replacement – please switch over. If that’s OK with you, Mr Developer? It’s not critical that you change, although it costs us extra support – so, at some time in the distant future, we might change this from “deprecated” to simply “removed/disabled”, and force you to change. But not yet. For now, that would be overkill.

It’s usually used when a platform owner / API write finds they made a really big mistake in their API design, and yet they’ve seen a way to fix that mistake without BIG changes to the applications (but *some* change is going to be required – perhaps an extra parameter will be needed, for instance).

Where even asking the developer to make these “small” changes won’t be enough, the API / platform owner (Apple) would normally be forced to write “cleverer” internal code … or create an entire new alternative library, and support both libraries for a while.

So … overall … it’s almost impossible to believe that Apple really means that the “Deprecated” methods are rejection-fodder for being “private”. I’m guessing that these calls are duplicated (by Apple) somewhere? I did a quick search of Apple’s docs myself, and all I could find were the official, Apple-sanctioned calls – marked deprecated as of OS X 10.5 (iPhone OS not mentioned).

Anyone able to shed more light on this one?