CODEWITHSUNDEEP
iosios6udid
Tyson
Tyson

Reputation: 14734

Using UDID in pre-iOS6 apps (and IDFA for 6.0+)

The new IDFA features of iOS6 work fine for conversion tracking for users that are running iOS6. However if an app has a minimum supported version less than iOS 6, what is the accepted approach to handle when running on a pre-iOS6 device?

Jumptap mentions that you are still allowed to use UDID on pre-iOS6 devices:

The Identifier for Advertising (IDFA) was introduced in iOS 6. It's used by advertisers for tracking conversions and advanced targeting, among other things. On devices using iOS 6 (or higher), IDFA is intended to replace UDID as the device identifier. On devices using iOS 5 (or lower), Apple will continue to support the use of the UDID as the device identifier.

That doesn't sit well with me though. iOS version checks are a runtime thing, meaning your code will always statically link to the deprecated UDID accessor, and only at runtime decide whether to read it or not. Surely Apple's review process is going to see the static link to UDID and reject the app. They're not going to decompile the code and confirm your logic is correct, or try to do a 100% code coverage test to confirm it is never read when running in iOS6., are they?!?!

Also, AppsFlyer mention that UDID's can be enabled in their SDK, with this note:

*UDID details: Some ad-networks (e.g. Tapjoy) require UDID to run CPI campaigns. In the above mentioned case, you need to enable UDID and update your app Terms & Conditions with a clear Privacy statement notifying your users about collecting their private information.

Which seems to imply UDID is still allowed to be read as long as you inform the user. However I cannot find any mention of this in official Apple documentation.

Upvotes: 3

Views: 3540

Answers (2)

John Stack
John Stack

Reputation: 628

UDID now fails verification. Go OpenUDID.

Upvotes: 1

user529758
user529758

Reputation:

Most probably they aren't, but they should. But see, Apple's goal is not to please the developer; their goal is to please themselves (i. e. make loads of money).

If you're afraid that this incident will eventually happen to you (which is a quite reasonable fear), then you can try obfuscating the call to that particular message (and call it only on iOS 5 and older in order not to violate the TOS). Example:

NSString *str1 = @"ueId";
NSString *str2 = @"uniq";
NSString *sel = [NSString stringWithFormat:@"%@%@ent%cfi%s", str2, str1, 'i', "er"];
SEL msg = NSSelectorFromString(sel);
if (iOS_5_or_older) {
    deviceID = [[UIDevice currentDevice] performSelector:msg];
}

This is quite weak an "obfuscation", but may be enough to get through the static analysis part of the story if Apple really get lazy and/or decide do b*dger you.

Upvotes: 2

Related Questions