Update Flurry, Appirater now to avoid rejection from iTunes App Store

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).

Verification:

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.

Matt Mayer

Matt Mayer is a founder at ReignDesign. Matt is from the UK and was based in Shanghai for ten years. He is now living in Bangkok, Thailand.