It’s always frustrating when your app is rejected in the iTunes App Store approval process. Today we noted a new twist on the reason for rejection which we hadn’t encountered before.
We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines. The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change. We found the following non-public API/s in your app: appName setAppName: multitaskingSupported If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged in future submissions. Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application. If you do not have access to the library's source, you may be able to search the compiled binary using "strings" or "otool" command line tools. The "strings" tool can output a list of the methods that the library calls and "otool -ov" will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
This seems to be a new change in the implementation of Apple’s policy, as we’ve submitted apps including this code several times in the past. Other people are also hitting this issue in the last couple of days We’ve investigated the issue, and the problem seems to lie in two third-party libraries which we use: Appirater (for encouraging users to rate your app) and Flurry (Analytics).
Updating to the latest version of Appirater solves the problem with the use of the multitaskingSupported API. To check if you need to upgrade, check for the presence of the string “multitaskingSupported” in your Appirater.m file. If it’s there, you need to update.
Updating to the v3 of the Flurry SDK also solves the problem with the use of the appName and setAppName API. To check if you need to upgrade, check if your Flurry header file is called FlurryAPI.h (v2) or FlurryAnalytics.h (v3).
strings libFlurry.a | grep setAppName
returns reults, showing that there’s a method named setAppName used in the v2 SDK
strings libFlurryAnalytics.a | grep setAppName
returns empty, showing that this method is removed in the v3 SDK
The new libraries should be a simple drop-in replacement, but be sure to retest the functionality of your app before re-submitting! Of course it’s good practice to regularly check for new updates/patches to any third-party libraries you may be using in your app.
We’ve also heard of an app using ASIHTTPRequest being rejected, possibly for similar reasons. If you have any other information on this issue, do let us know in the comments.