Static Analysis Rejection?
Mobile Orchard pointed to a post by Joe Hewitt (developer of the Facebook iPhone app) where he mentions that Apple may be using a static analyzer to help review app submissions. If that’s the case, it might explain our recent rejections. Here’s the boilerplate response that we’ve (unfortunately) come to expect each time we submit an app. This is from a recent rejection:
Thank you for submitting 3D Camera & 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, 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>.
While we haven’t announced anything on our site yet, we’ve been waiting for Apple to review a brand new Juicy Bits app that also happens to use the camera, and guess what? It was rejected for exactly the same reason (same text, except for the app name).
Funny thing is, neither 3D Camera, 3D Camera Lite, nor the yet-to-be-approved app use any undocumented APIs at all! As a matter of fact, all three apps have been built using 3.1.x SDKs, and they all use the new official camera APIs to implement their overlays. For astute readers, yes, this is exactly what Apple recommends that we do in the last paragraph of their rejection e-mail!
The nuance is that while we’ve compiled these apps using 3.1.x SDKs, we’ve set the minimum iPhone OS Deployment Target to 3.0 so that the apps will run on older devices (read the section titled Specifying the Runtime Environment in Apple’s Running Applications documentation for a good explanation). We still have a lot of users running 3.0.x devices, and we want to make sure they can upgrade and use our apps.
In the code, we check to see if the app is running on a 3.1.x device before calling any of the new 3.1.x APIs (like the camera overlay). If the app is running on an older 3.0.x device, we don’t use the new APIs and the standard built-in camera controls are used. This is exactly what Apple’s documentation says we should do.
For 3D Camera and 3D Camera Lite, Apple asked that we set the minimum OS to 3.1 and re-submit. Presumably, this is because the reviewer saw the camera overlay and also noticed that the app would run on a 3.0.x device. Our guess is that the reviewer never tried the apps on a 3.0.x device to see that the camera overlay feature is disabled. Because so many of our users are still running a 3.0.x device, we chose to ignore this advice and instead tried to explain the situation to Apple. After a very slow and non-interactive e-mail exchange, 3D Camera and 3D Camera Lite were both approved.
So, we weren’t surprised when our yet-to-be-approved app was rejected for the same reason, since it uses identical camera overlay code and logic and runs on 3.0.x devices. Thus begins the very slow e-mail “conversation” to re-explain the same situation all over again. It’s frustrating, because we’re doing exactly what Apple wants us to do, yet we’re paying for it with very long delays.
We’re now wondering if the static analysis tool sees the 3.1.x API call in our app, notices that it runs on 3.0.x devices (that don’t support the new APIs), and flags or rejects it as a result. This would actually make sense! The only problem is that the tool appears to be ignoring the code where we check the device version before making that call, and that may be the nuance that’s causing all of our delays.
Of course, we’re only speculating about the static analysis rejection, because we don’t know how Apple reviews apps for the App Store. Like others, we try to reverse engineer the black box that is the approval process, and also like others, we wait.
Nov 07, 2009
You may be able to use that “Demo Account” field on iTunes Connect for this kind of thing. If your app keeps running into the same issues, you may find that describing how you address them in that field will get you through the gauntlet. For example, one of my apps has been rejected for using encryption without having gone through export controls, but pointing out that I’m using the pre-approved ones in libSystem gets me through.
Nov 07, 2009
Thanks for the tip, Brent. When we re-submitted our latest app, we added an explanation to the “Demo Account” field. Glad to hear it works for you. There’s hope!
Nov 17, 2009
[...] key thing about Juicy Bits experience is that both apps eventually got accepted, which strongly supports their interpretation of why they were REALLY [...]
Nov 20, 2009
[...] automated process is already creating stories of apps being rejected for use of private APIs which developers are [...]
Nov 20, 2009
We basically did the same thing as you, calling the new api’s only for 3.1 and using older compatibility stuff for 3.0. Even after talking to apple over the phone about what we were doing they still made us only support 3.1 and pull all of our older code out before approval. Of course it doesn’t make a lot of sense since the old 3.0 builds will always work since apple doesn’t modify 3.0 builds anymore. So it really only hurts the users that don’t want to upgrade. It is nice that users can leave scathing reviews because it won’t work with 3.0 anymore even though it is not our choice to stop supporting those users but apple’s. But I guess that’s what we must deal with to sell in the app store.
I wish apple would use there own public api for developing all of their apps on the phone. It would basically solve all the problems we encounter. The public api has a lot of bugs that wouldn’t exist if apple used it to develop their own apps.
Nov 30, 2009
[...] not sure where to begin, so we’ll pick up the story from our last post: Static Analysis Rejection? That post has been referenced in a number of other articles about App Store rejections by [...]