App Rejections

This time: for real … Previously, Apple rejected 3D Camera Lite [] apparently for following Apple’s own instructions. That time, the authors eventually got it approved – situation explained, problem solved! Or … is it? It would seem that Apple reviewers are playing silly games again:

we submitted an update to our existing free app, 3D Camera Lite, on November 20th. It’s a very minor update that adds frequently-requested “Save to Album” and “Send to Facebook” features. While there were no changes at all to the camera functionality from the version that is currently available in the App Store, it was rejected today. You’ll never guess the reason:

…well, can you guess it? Hmm, could it be …

Thank you for submitting 3D Camera Lite to the App Store. Unfortunately it cannot be added to the App Store because it is modifying or extending an undocumented API
…
There is no documentation for creating custom subclasses of UIImagePickerController, the organization or layout of the view hierarchy managed by UIImagePickerController, and any of the custom classes managed by UIImagePickerController in iPhone OS 3.0.1.
…
Camera APIs are available in the iPhone OS 3.1 SDK that allow applications to take pictures, provide camera view overlays, and add custom camera controls. Please review these APIs to determine if they provide the functionality you require in your product.

Oh, yes. Yes it is. Rejected for the same thing they rejected on before. But … since the authors have *already* persuaded Apple it was a false positive (on Apple’s side) … surely Apple would remember that, and not make the same mistake twice? Hmm.

Thoughts

The first time was ridiculous. I don’t have access to Juicy Bits’ source code, so I can’t authoritatively say that they really did what they claimed … but since Apple eventually accepted both apps last time around, I’m going to assume JB have got it right.

This time around, there’s a nice, detailed … boilerplate, auto-response … rejection message.

*That* is unusual. Apple will often reject an app “on principle” with a short message (sometimes incorrectly) – usually based on a quick observation, or the infamous(ly broken) static-analysis tool. They also (sometimes) engage in deeper analysis, and then eventually reject an app with a detailed message explaining why.

But here we have a combination: a detailed, carefully planned message … which seems to have been fired off without any real thought or effort…

Static Analyser screw-up?

Given the context, this seems unlikely to be the static analyser alone – unless it’s specifically been coded to reject PUBLIC API’s whenever they’re used in apps that claim to be backwards compatible. That would be a screw-up of such monumental proportions that I struggle to believe it’s the case here. It would generate an enormous number of false positives.

(To be clear: if that were the case, then every single app that includes any feature-backwards-compatibility (it uses “new” API’s which don’t exist on older iPhones) … would *always* get rejected).

What I think actually happened …

IMHO, it’s much more likely that some human has decided – based on personal opinion and gut feeling – that the developer’s claims to backwards compatibility are incorrect or malicious:

1. Developer is lieing – this app does NOT work on old phones
2. Developer is stupid – as per above, but they actually believe it works, they just haven’t tested it
3. Developer is using private API’s – …to make “new” features work on “old” phones

Of course, the other two possibilities seem to have been ignored. These are the possibilities based on the assumption that the developer is smart and skilled and probably knows more about iPhone development than the reviewer:

1. Developer has worked out a way of making the App work even without the new APIs
2. Developer has provided a friendly error message explaining that the app is missing some functionality when used on old phones

How bad is this?

If that’s correct, then the problem here isn’t that Apple is failing to record the rejection/appeal history of individual Apps (although that *is* a failing – and would be easy to fix).

The problem isn’t that the static analyser is buggy (although we know that it *is* buggy).

The problem is … an app reviewer at Apple is imposing personal views on “what is possible, if you were a highly skilled programmer”, without – apparently – actually *being* a highly skilled programmer themself.

If that’s the case … this is a really really hard problem to fix. The other problems are problems of process and documentation: they can be fixed easily. This is a problem of culture and mindset, and requires changing the mental attitudes of the people involved. That’s a much much harder problem (for Apple). Which means it probably won’t get solved…

So, here’s hoping I’m wrong, and that this rejection is just some utterly random one-off incident…