Apple Rejecting Apps With UDID

03/27/13

Avoid App Store Rejection Of Your App

What You Need To Do Before May 1

You may have already read the latest announcement from Apple that all apps submitted to the app store that access the Universal Device ID (UDID) will be rejected starting May 1.

We’ve previously stated our opinions on why the deprecation of the UDID is a good thing for both users and the mobile app advertising industry at large.  We’ve also shared our thoughts on what we think Apple should do next in order to ensure the success of the new, improved AdvertisingIdentifier (also called IDFA or sometimes IFA) for IOS6.

There are some actions that you needs to if submitting your app to Apple’s App store after May 1st to comply with the revised policy.

Changes You’ll Need to Make:

1) Remove calls using uniqueIdentifier method to access the UDID on new app submissions. Apsalar accesses the UDID on all versions of 4.1.1 or older, and U versions v4.1.2 or higher.  The most recent SDK version of an app can be found at https://apsalar.com/app/apengage/management/applications/index/ in your account.

2)  The other change to Apple’s guidelines is that Apple will require all iPhone apps to support a 4-inch screen size and IOS devices with Retina displays in general, also starting May 5.  You’ll want to make the appropriate changes to your app if you don’t want future versions to be rejected.

We’d also like to address some commonly asked questions and concerns we’ve heard out there in the market:

What % of sessions are on iOS 6 or greater which uses the advertiserIdentifier?

81% of Apsalar user sessions are on iOS 6.0+, 15% are on iOS 5.x, and the remaining 4% on iOS3.x and 4.x.  This means that 81% of device use supports the IDFA, with only 19% where UDID is the primary identifier used for marketing.

 

iOS UDID Sessions

Will Apple be removing apps using the UDID that were previously approved and already in the app store?

Apple has not released any official statement regarding whether or not they’ll be removing previously approved apps (pre-May 1) that track with UDID from the store.  Our hypothesis is that they won’t (since it would take a lot of effort, and the UDID will phase itself out eventually as more users upgrade to newer devices in the next year or two), but you can never be too sure.

How will this affect my reporting and analytics in Apsalar?

For any apps using Apsalar iOS SDK v4.1.2 or higher, there is no expected impact to your reporting or analytics.  If you are converting from Apsalar iOS SDK v4.1.1 or lower there is a small chance of double counting as Apsalar will no longer be using UDID as the primary identifier for devices.

How will this affect advertising campaigns I’m running that use the UDID for targeting purposes?

Campaigns you’re currently running most likely won’t be affected, as long as the network/DSP you’re running campaigns with can support both IDFA and UDID and is prepared for the transition on iOS.  There is also still a legacy pool of users being tracked via UDID (from the existing apps already in the app store and using the UDID, pre-May 1).

Changes You’ll Need to Make If You’re Using Apsalar:

To comply with Apple’s App Store policy you will need to upgrade to Apsalar SDK 5.0.0 if you use:

-Apsalar SDK v 4.1.1 or older

-v 4.1.2 “U” or higher (“U” versions access both UDID and IDFA)

The current version of the Apsalar iOS SDK, 5.0.0 “non-U”, does not access the UDID and and provides you with other benefits, such as automated revenue detection and reporting and marketing attribution analytics (which allows you to measure the ROI of all your campaigns).

Click here to login to your account and download the latest version of the Apsalar SDK for iOS, which you’ll need to drop into your iOS apps prior to May 1.

Not currently using Apsalar?  Sign up here to access our platform of tools for mobile app marketers today!


Share Button