As alluded to in a previous article, I have created an app with augmented reality capabilities, using Apple’s new camera overlay API calls which were first introduced in the OS3.1 SDK beta.
Given that “augmented reality” has caused such a buzz, I was of course keen to try to get it published as soon as possible. I noted that a number of other developers had already submitted apps which used camera overlays and yet were OS3.0 apps, and that some of them had been accepted into the app store, despite the widespread suspicions that such apps must be using private API calls to achieve this – something that Apple explicitly forbids.
But I didn’t want to risk raising the ire of Apple by trying to sneak through the cracks of the review process. After all, I depend on them for my living, and on the whole they have been very supportive of my efforts – for example by featuring Oz Weather prominently and repeatedly over the course of many months, which has kept it in the top 20 paid apps in Australia for much of the time.
So having more or less completed the app some time ago using the OS 3.1 beta, I dutifully waited for the final release of OS3.1 SDK, which upon arrival I promptly downloaded, verified that my app worked correctly with it, and then re-built and submitted it via iTunes Connect. That app submission was on 10th September.
Of course, as usual, I then had to sit back and wait for my app to reach the front of the queue and be reviewed by Apple’s team. The first and only sign you get that this has happened is to get an email either approving or rejecting your app. This arrived on 23rd September ie. 13 days later. And of course it was a rejection.
The Reason for Apple’s Rejection
Although I have previously made at least a dozen app submissions (new and updates), only one had ever been rejected, and that was due to a crash that occurred during Apple testing, so a fully understandable rejection. But this rejection was different. The reason given was as follows.
Thank you for submitting [redacted] to the App Store. Unfortunately it cannot be added to the App Store because it is modifying or extending an undocumented API, which as outlined in the iPhone Developer Program License Agreement section 3.3.1 is prohibited:
“3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.”
There is no documentation for the custom subclasses or self-contained views of UIImagePickerController in iPhone OS 3.0.1. This includes PLCameraView and its custom subclasses (PLImageTile, PLRotationView, PLImageScroller, PLImageView, PLCropOverlay, PLCropLCDLayer, TPBottomDualButtonBar, TPPushButton and TPCameraPushButton).
Additional Camera APIs are now available in iPhone OS 3.1. Please review these new APIs to see if they meet your needs. If any additional APIs are desired, please file an enhancement request via the Bug Reporter, <http://bugreport.apple.com>.
So apparently they were rejecting it because they believed I was using UIImagePickerController in an illegal manner under OS3.o. Huh?
Well of course the app was doing no such thing. I had gone to considerable effort to ensure that I was conforming fully with Apple’s rules, and the app was compiled with OS3.1 as its base SDK. But… I am guessing that my “mistake” was to try to ensure backward compatibility, with a graceful and minor degradation of capability for those still running OS3.0.
What I had done was to set the deployment SDK target to OS3.0, so that the app could also run on devices with the older OS3.0, but avoiding any use of the UIImagePickerController in that case. The reasons for doing so were
- The camera overlay view is not essential for the app to be useful – the OS3.0 view with a plain background still gives a good 3-D “augmented reality” perspective which is more than adequate for the type of data being presented by the app.
- If users upgrade from OS3.0 to 3.1 (a free upgrade anyway), then the camera view will become available to them without needing to obtain a new or upgraded app, so it should serve simply to encourage the OS upgrade.
So to re-iterate – the app was NOT using any private API calls, under ANY circumstances.
I can only assume that the tester/s jumped to the erroneous conclusion that it did so because they did not read or understand my app description (in which I explained the app’s difference in behaviour on OS 3.0), and/or that they did not test it on OS3.0 as well as on OS3.1.
The above is essentially exactly what I explained to Apple in my emailed response to their rejection notice, and I asked them for confirmation as to whether or not they were maintaining their rejection, and if so whether recompile the app to run on OS3.1 only would be required.
Apple’s Further Response
I am pleased to say that it was less than 24 hours before I heard from Apple again – this time via a phone call from the USA. However, the bad news was that Apple was requesting me to resubmit the app for deployment only on OS3.1. Of course I queried why this was necessary, given that I was not using any private APIs, and the (polite) response I got was that, for the sake of the approval process, it would simply be necessary for me to make this change. With hindsight, I should have pushed for a more detailed justification, but being on a crowded and noisy bus, and not sensing that any negotiation might be possible, I agreed to make the change and resubmit.
The Status Quo
So, despite the fact that Apple’s rejection was justified with spurious reasons, the situation now is that I have resubmitted the app for deployment only on OS3.1.
The main question I have now, of course, is whether or not I have gone to the back of the queue once more, and will likely therefore have another two week wait. I’m not holding my breath – I’m betting on at least another two weeks.😦
The saddest part of this story, of course, is that it is just one of many weird and wonderful rejection stories. I’m not going to dump on Apple, because there are some great upsides to working with them, but I have now joined the ranks (throngs?) of those who find whole app approval process somewhat arbitrary and disempowering.
If Apple does have any formal rules and guidelines, why can’t they let developers know what they are? Why can’t they have an arbitration or escalation process for those who rejections appear to be based on dubious grounds. And why oh why can’t we know exactly where our apps are in the queue?