苹果在iOS6中禁用了[UIDevice uniqueIdentifier]，在iOS7中又把mac地址的获取给堵上了。没办法，毕竟人家是老大，说不让你用，你也没办法。
在这边总结一下现有的一部分UDID获取方法（有苹果推荐的，也有第三方的），目的在于抛砖，没有切实的说明哪种方法好用。用哪种方法，完全由大家自己根据需要来决定。
iOS2~iOS7目前已有的技术方案
方案提供方实现方法用途及使用情况传统UDID苹果APIUIDevice的实例方法uniqueIdentifier直接可获取●获取设备的唯一识别码
●在iOS5及之前的版本中，基本上使用该方法来获取UDID。MAC+MD5UNIX系统调用使用UNIX API获取设备的MAC地址，再使用MD5加密算法生成一个字符串●由于苹果在iOS6后停用了UDID方案，所以大部分应用都开始使用这种方案来生成设备的唯一识别码CFUUID/NSUUID苹果API通过唯一标识设备的一个值(通常是以太网硬件地址)和一个时间值来生成一个唯一标识串● 苹果建议基于CFUUID来生成一个UDID，然后将其存在程序中使用IDFV苹果APIUIDevice的实例方法identifierForVendor● 用于标识供应商ADID苹果APIASIdentifierManager的实例方法advertisingIdentifier●用于广告服务OpenUDID第三方开源代码以CFUUID为基础生成一个串，并同时存储于系统剪切板和程序的沙盒(NSUserDefault)中，应用程序从这两个地方之一获取UDID●在苹果宣布禁用传统UDID方案后，这是目前使用较为广泛的开源方案，包括友盟在内的很多开发商都使用这一方案。SecureUDID第三方开源代码以CFUUID为基础生成一个串，并同时存储于程序剪切板中，程序可以从该剪切板中获取UDID●在苹果宣布禁用传统UDID方案后，部分应用也采用了该方案(目前github上数据显示该方案下载量仅次于OpenUDID，具体使用情况未知)
系统支持情况
苹果在iOS6以后，已禁用了UIDevice的uniqueIdentifier方法，所以传统的UDID方法在iOS6以后已不能使用；而从iOS7开始，获取MAC地址的方法统一返回02:00:00:00:00:00，所以使用MAC+MD5方法已无意义。
方案
iOS 2
iOS 3
iOS 4
iOS 5
iOS 6
iOS 7
UDID
√
√
√
√
×
×
MAC+MD5
√
√
√
√
√
×
CFUUID
√
√
√
√
√
√
NSUUID
×
×
×
×
√
√
IDFV
×
×
×
×
√
√
Ad ID
×
×
×
×
√
√
OpenUDID
?
√
√
√
√
√
SecureUDID
?
√
√
√
√
√
持久化情况
启动程序
从后台返回
重置广告标识
重新安装程序
系统重启
系统还原设置
升级系统
重装系统
传统UDID
√
√
√
√
√
√
√
√
MAC+MD5
√
√
√
√
√
√
√
√
CFUUID/NSUUID
×
×
×
×
×
×
×
×
IDFV
√
√
√
×
√
×
？√
？×
ADID
√
√
×
√
√
×
？√
？×
OpenUDID
√
√
√
√
√
×
？√
？×
SecureUDID
√
√
√
×
√
×
？√
？×
注：
√表示能够保证UDID的持久化，
×表示该情况下UDID可能会丢失改变，?表示该种情况没有实际验证过，纯属猜测(毕竟升级系统什么的太麻烦)
优缺点
优点
缺点
CFUUID/NSUUID
● 删除程序再安装时，会生成新的UDID
IDFV
● 对于运行于同一设备上的同一供应商的所有程序，该值都是相同的。
● 对于同一设备上不同供应商的程序，该值是不同的
● 所谓同一供应商是由CFBundleIdentifier中的反转DNS前两部分来确定，如com.test1和com.test2即认为不是同一供应商
● 用户如果删除同一供应商的所有程序，再安装该供应商的程序时，该值会改变。
● 该值在程序运行于后台时，或用户在重启系统后第一次解锁设备可能返回nil值。
ADID
● 该值由系统持久化
● 即使用户限制广告跟踪，也可以使用该值来统计用户数量、安全等方面的操作
● 该值对于所有的供应商都是一样的
● 只能用于广告服务的程序访问一个唯一标识
● 如果用户还原所有系统设置或还原广告标识符时，可能重置该值。
● 该值在程序运行于后台时，或用户在重启系统后第一次解锁设备可能返回nil值。
OpenUDID
●同一台设备上使用OpenUDID的所有程序其获取到的UDID都是相同的
● 没有用到取MAC地址等可能被苹果禁用的API
● 在系统恢复设置或刷机的情况下会丢失
● 非苹果原生API
SecureUDID
●对于运行于同一设备上的同一供应商的所有程序，该值都是相同的(供应商自己控制)。这样防止因一个程序外泄UDID，而导致设备的UDID外泄
● 与硬件设备无关
● 不能确保不同设备上的UDID不同
● 用户可以选择阻止SecureUDID收集UDID信息
● 如果用户备份A设备系统并将其恢复到B设备，则B设备将得到A设备的UDID
● 删除程序并清空剪切板可能会导致丢失
● 非苹果原生的API
在 iOS 5 中， 可以获取到系统的 UDID(Unique Device Identifier) ，后来被 Apple 禁止掉了。
于是，在 iOS 6 中，大家开始使用 MAC 地址 MAC(Medium/Media Access Control) ，后来又被 Apple 禁止掉了。
同样的，OpenUDID 也不能用了：
OpenUDID doesn’t work on iOS 7。UDID is dead,OpenUDID is deprecated,long live advertisingIdentifier!在 iOS 7 中，Apple 推荐使用广告标识符advertisingIdentifier来获取系统的唯一标识符。但是，用户如果重置了系统，广告标识符会重新生成。这就达不到 “唯一标识符” 的作用。
于是，在 iOS 7 中，程序员们发明了 “钥匙串保存” 方法，将这个唯一标识符保存在钥匙串中，安装了 App 后读取这个标识符即可。参见这里：ios 利用钥匙串保存密码和获取密码和Simple iPhone Keychain Access。
一、iOS不用版本获取UDID的方法比较
1）iOS 5.0
iOS 2.0版本以后UIDevice提供一个获取设备唯一标识符的方法uniqueIdentifier，通过该方法我们可以获取设备的序列号，这个也是目前为止唯一可以确认唯一的标示符。好景不长，因为该唯一标识符与手机一一对应，苹果觉得可能会泄露用户隐私，所以在 iOS 5.0之后该方法就被废弃掉了。
而且苹果做的更狠，今年5月份以后提交App Store的产品都不允许再用uniqueIdentifier接口，甚至有些朋友因为代码中有UDID还被打回来，看来这条路是被封死了。
2）iOS 6.0
iOS 6.0系统新增了两个用于替换uniqueIdentifier的接口，分别是：identifierForVendor，advertisingIdentifier。
identifierForVendor接口的官方文档介绍如下:
The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors,and for apps on different devices regardless of vendor.
The value of this property may be nil if the app is running in the background,before the user has unlocked the device the first time after the device has been restarted. If the value is nil,wait and get the value again later.
The value in this property remains the same while the app (or another app from the same vendor) is installed on the iOS device. The value changes when the user deletes all of that vendor’s apps from the device and subsequently reinstalls one or more of them. Therefore,if your app stores the value of this property anywhere,you should gracefully handle situations where the identifier changes.
大概意思就是“同一开发商的APP在指定机器上都会获得同一个ID。当我们删除了某一个设备上某个开发商的所有APP之后，下次获取将会获取到不同的ID。”也就是说我们通过该接口不能获取用来唯一标识设备的ID，问题总是难不倒聪明的程序员，于是大家想到了使用WiFi的mac地址来取代已经废弃了的uniqueIdentifier方法。具体的方法晚上有很多，大家感兴趣的可以自己找找，这儿提供一个网址:http://stackoverflow.com/questions/677530/how-can-i-programmatically-get-the-mac-address-of-an-iphone
3）iOS 7.0
iOS 7中苹果再一次无情的封杀mac地址，使用之前的方法获取到的mac地址全部都变成了02:00:00:00:00:00。有问题总的解决啊，于是四处查资料，终于有了思路是否可以使用KeyChain来保存获取到的唯一标示符呢，这样以后即使APP删了再装回来，也可以从KeyChain中读取回来。有了方向以后就开始做，看关于KeyChain的官方文档，看官方使用KeyChain的Demo，大概花了一下午时间，问题终于解决了。
二、KeyChain介绍
我们搞iOS开发，一定都知道OS X里面的KeyChain(钥匙串)，通常要乡镇及调试的话，都得安装证书之类的，这些证书就是保存在KeyChain中，还有我们平时浏览网页记录的账号密码也都是记录在KeyChain中。iOS中的KeyChain相比OS X比较简单，整个系统只有一个KeyChain，每个程序都可以往KeyChain中记录数据，而且只能读取到自己程序记录在KeyChain中的数据。iOS中Security.framework框架提供了四个主要的方法来操作KeyChain:
// 查询
OSStatus SecItemCopyMatching(CFDictionaryRef query,CFTypeRef *result);
// 添加
OSStatus SecItemAdd(CFDictionaryRef attributes,CFTypeRef *result);
// 更新KeyChain中的Item
OSStatus SecItemUpdate(CFDictionaryRef query,CFDictionaryRef attributesToUpdate);
// 删除KeyChain中的Item
OSStatus SecItemDelete(CFDictionaryRef query)
这四个方法参数比较复杂，一旦传错就会导致操作KeyChain失败，这块儿文档中介绍的比较详细，大家可以查查官方文档Keychain Services Reference。
前面提到了每个APP只允许访问自己在KeyChain中记录的数据，那么是不是就没有别的办法访问其他APP存在KeyChain的数据了？
苹果提供了一个方法允许同一个发商的多个APP访问各APP之间的途径，即在调SecItemAdd添加数据的时候指定AccessGroup，即访问组。一个APP可以属于同事属于多个分组，添加KeyChain数据访问组需要做一下两件事情:
a、在APP target的bulibSetting里面设置Code Signing Entitlements，指向包含AceessGroup的分组信息的plist文件。该文件必须和工程文件在同一个目录下，我在添加访问分组的时候就因为plist文件位置问题，操作KeyChain失败，查找这个问题还花了好久的时间。
b、在工程目录下新建一个KeychainAccessGroups.plist文件，该文件的结构中最顶层的节点必须是一个名为“keychain-access-groups”的Array，并且该Array中每一项都是一个描述分组的NSString。对于String的格式也有相应要求，格式为:"AppIdentifier.com.***"，其中APPIdentifier就是你的开发者帐号对应的ID。
c、在代码中往KeyChain中Add数据的时候，设置kSecAttrAccessGroup，代码如下:
NSString *accessGroup = [NSString stringWithUTF8String:"APPIdentifier.com.cnblogs.smileEvday"];
if (accessGroup != nil)
{
#if TARGET_IPHONE_SIMULATOR
// Ignore the access group if running on the iPhone simulator.
//
// Apps that are built for the simulator aren't signed,so there's no keychain access group
// for the simulator to check. This means that all apps can see all keychain items when run
// on the simulator.
//
// If a SecItem contains an access group attribute,SecItemAdd and SecItemUpdate on the
// simulator will return -25243 (errSecNoAccessForItem).
#else
[dictForQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup];
#endif
}
这段代码是从官方的Demo中直接拷贝过来的，根据注释我们可以看到，模拟器是不支持AccessGroup的，所以才行了预编译宏来选择性添加。
注：appIdentifer就是开发者帐号的那一串标识，如下图所示：
打开xcode的Organizer，选择Device选项卡，连接设备就可以看到设备上安装的开发者账号描述文件列表，其中第五列最开始的10个字符即为App Identifier，这块儿前面写的不是很清楚，好多朋友加我qq问我，今天特地补上。
三、使用KeyChain保存和获取UDID
说了这么多终于进入正题了，如何在iOS 7上面获取到不变的UDID。我们将第二部分所讲的知识直接应用进来就可以了轻松达到我们要的效果了，下面我们先看看往如何将获取到的identifierForVendor添加到KeyChain中的代码。
+ (BOOL)settUDIDToKeyChain:(NSString*)udid
{
NSMutableDictionary *dictForAdd = [[NSMutableDictionary alloc] init];
[dictForAdd setValue:(id)kSecClassGenericPassword forKey:(id)kSecClass];
[dictForAdd setValue:[NSString stringWithUTF8String:kKeychainUDIDItemIdentifier] forKey:kSecAttrDescription];
[dictForAdd setValue:@"UUID" forKey:(id)kSecAttrGeneric];
// Default attributes for keychain item.
[dictForAdd setObject:@"" forKey:(id)kSecAttrAccount];
[dictForAdd setObject:@"" forKey:(id)kSecAttrLabel];
// The keychain access group attribute determines if this item can be shared
// amongst multiple apps whose code signing entitlements contain the same keychain access group.
NSString *accessGroup = [NSString stringWithUTF8String:kKeyChainUDIDAccessGroup];
if (accessGroup != nil)
{
#if TARGET_IPHONE_SIMULATOR
// Ignore the access group if running on the iPhone simulator.
//
// Apps that are built for the simulator aren't signed,SecItemAdd and SecItemUpdate on the
// simulator will return -25243 (errSecNoAccessForItem).
#else
[dictForAdd setObject:accessGroup forKey:(id)kSecAttrAccessGroup];
#endif
}
const char *udidStr = [udid UTF8String];
NSData *keyChainItemValue = [NSData dataWithBytes:udidStr length:strlen(udidStr)];
[dictForAdd setValue:keyChainItemValue forKey:(id)kSecValueData];
OSStatus writeErr = noErr;
if ([SvUDIDTools getUDIDFromKeyChain]) { // there is item in keychain
[SvUDIDTools updateUDIDInKeyChain:udid];
[dictForAdd release];
return YES;
}
else { // add item to keychain
writeErr = SecItemAdd((CFDictionaryRef)dictForAdd,NULL);
if (writeErr != errSecSuccess) {
NSLog(@"Add KeyChain Item Error!!! Error Code:%ld",writeErr);
[dictForAdd release];
return NO;
}
else {
NSLog(@"Add KeyChain Item Success!!!");
[dictForAdd release];
return YES;
}
}
[dictForAdd release];
return NO;
}
上面代码中，首先构建一个要添加到KeyChain中数据的Dictionary，包含一些基本的KeyChain Item的数据类型，描述，访问分组以及最重要的数据等信息，最后通过调用SecItemAdd方法将我们需要保存的UUID保存到KeyChain中。
获取KeyChain中相应数据的代码如下:
+ (NSString*)getUDIDFromKeyChain
{
NSMutableDictionary *dictForQuery = [[NSMutableDictionary alloc] init];
[dictForQuery setValue:(id)kSecClassGenericPassword forKey:(id)kSecClass];
// set Attr Description for query
[dictForQuery setValue:[NSString stringWithUTF8String:kKeychainUDIDItemIdentifier]
forKey:kSecAttrDescription];
// set Attr Identity for query
NSData *keychainItemID = [NSData dataWithBytes:kKeychainUDIDItemIdentifier
length:strlen(kKeychainUDIDItemIdentifier)];
[dictForQuery setObject:keychainItemID forKey:(id)kSecAttrGeneric];
// The keychain access group attribute determines if this item can be shared
// amongst multiple apps whose code signing entitlements contain the same keychain access group.
NSString *accessGroup = [NSString stringWithUTF8String:kKeyChainUDIDAccessGroup];
if (accessGroup != nil)
{
#if TARGET_IPHONE_SIMULATOR
// Ignore the access group if running on the iPhone simulator.
//
// Apps that are built for the simulator aren't signed,SecItemAdd and SecItemUpdate on the
// simulator will return -25243 (errSecNoAccessForItem).
#else
[dictForQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup];
#endif
}
[dictForQuery setValue:(id)kCFBooleanTrue forKey:(id)kSecMatchCaseInsensitive];
[dictForQuery setValue:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit];
[dictForQuery setValue:(id)kCFBooleanTrue forKey:(id)kSecReturnData];
OSStatus queryErr = noErr;
NSData *udidValue = nil;
NSString *udid = nil;
queryErr = SecItemCopyMatching((CFDictionaryRef)dictForQuery,(CFTypeRef*)&udidValue);
NSMutableDictionary *dict = nil;
[dictForQuery setValue:(id)kCFBooleanTrue forKey:(id)kSecReturnAttributes];
queryErr = SecItemCopyMatching((CFDictionaryRef)dictForQuery,(CFTypeRef*)&dict);
if (queryErr == errSecItemNotFound) {
NSLog(@"KeyChain Item: %@ not found!!!",[NSString stringWithUTF8String:kKeychainUDIDItemIdentifier]);
}
else if (queryErr != errSecSuccess) {
NSLog(@"KeyChain Item query Error!!! Error code:%ld",queryErr);
}
if (queryErr == errSecSuccess) {
NSLog(@"KeyChain Item: %@",udidValue);
if (udidValue) {
udid = [NSString stringWithUTF8String:udidValue.bytes];
}
}
[dictForQuery release];
return udid;
}
上面代码的流程也差不多一样，首先创建一个Dictionary，其中设置一下查找条件，然后通过SecItemCopyMatching方法获取到我们之前保存到KeyChain中的数据。
四、总结
本文介绍了使用KeyChain实现APP删除后依然可以获取到相同的UDID信息的解决方法。
你可能有疑问，如果系统升级以后，是否仍然可以获取到之前记录的UDID数据？
答案是肯定的，这一点我专门做了测试。就算我们程序删除掉，系统经过升级以后再安装回来，依旧可以获取到与之前一致的UDID。但是当我们把整个系统还原以后是否还能获取到之前记录的UDID，这一点我觉得应该不行，不过手机里面数据太多，没有测试，如果大家有兴趣可以测试一下，验证一下我的猜想。
完整代码地址:https://github.com/smileEvday/SvUDID
大家如果要在真机运行时，需要替换两个地方:
第一个地方是plist文件中的accessGroup中的APPIdentifier。
第二个地方是SvUDIDTools.m中的kKeyChainUDIDAccessGroup的APPIdentity为你所使用的profile的APPIdentifier。
下面的内容转自：网易杭州 QA Team
——– 以下为转载 ——–
英文原文：In iOS 7 and later,if you ask for the MAC address of an iOS device,the system returns the value 02:00:00:00:00:00. If you need to identify the device,use the identifierForVendor property of UIDevice instead. (Apps that need an identifier for their own advertising purposes should consider using the advertisingIdentifier property of ASIdentifierManager instead.)
翻译：从iOS7及更高版本往后，如果你向ios设备请求获取mac地址，系统将返回一个固定值“02:00:00:00:00:00”，如果你需要识别设备的 唯一性，请使用UIDevice的identifierForVendor属性。（因广告目的而需要识别设备的应用，请考虑使用 ASIdentifierManager的advertisingIdentifier属性作为替代）
这个MAC地址是指什么？有什么用？
MAC(Medium/Media Access Control)地址，用来表示互联网上每一个站点的标识符，采用十六进制数表示，共六个字节（48位）。其中，前三个字节是由IEEE的注册管理机构 RA负责给不同厂家分配的代码(高位24位)，也称为“编制上唯一的标识符” （Organizationally Unique Identifier)，后三个字节(低位24位)由各厂家自行指派给生产的适配器接口，称为扩展标识符（唯一性）。
MAC地址在网络上用来区分设备的唯一性，接入网络的设备都有一个MAC地址，他们肯定都是不同的，是唯一的。一部iPhone上可能有多个MAC地址，包括WIFI的、SIM的等，但是iTouch和iPad上就有一个WIFI的，因此只需获取WIFI的MAC地址就好了，也就是en0的地址。
形象的说，MAC地址就如同我们身份证上的身份证号码，具有全球唯一性。这样就可以非常好的标识设备唯一性，类似与苹果设备的UDID号，通常的用途有：1）用于一些统计与分析目的，利用用户的操作习惯和数据更好的规划产品；2）作为用户ID来唯一识别用户，可以用游客身份使用app又能在服务器端保存相应的信息，省去用户名、密码等注册过程。
那么，如何使用Mac地址生成设备的唯一标识呢？主要分三种：
直接使用“MAC Address”使用“MD5(MAC Address)”使用“MD5(Mac Address+bundle_id)”获得“机器＋应用”的唯一标识（bundle_id 是应用的唯一标识）iOS7之前，因为Mac地址是唯一的， 一般app开发者会采取第3种方式来识别安装对应app的设备。为什么会使用它？在iOS5之前，都是使用UDID的，后来被禁用。苹果推荐使用UUID 但是也有诸多问题，从而使用MAC地址。而MAC地址跟UDID一样，存在隐私问题，现在苹果新发布的iOS7上，如果请求Mac地址都会返回一个固定 值，那么Mac Address+bundle_id这个值大家的设备都变成一致的啦，跟UDID一样相当于被禁用。那么，要怎么标识设备唯一呢？
在iOS系统中，获取设备唯一标识的方法有很多：
一.UDID(Unique Device Identifier)
二.UUID(Universally Unique Identifier)
三.MAC Address
四.OPEN UDID
五.广告标示符（IDFA-identifierForIdentifier）
六.Vendor标示符 (IDFV-identifierForVendor)
七.推送token＋bundle_id
UDID的全称是Unique Device Identifier，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成（越狱的设备通过某些工具可以改变设备的UDID）。移动网络可利用UDID来识别移动设备，但是，从IOS5.0（2011年8月份）开始，苹果宣布将不再支持用uniqueIdentifier方法获取设备的UDID，iOS5以下是可以用的。在2013年3月21日苹果已经通知开发者：从2013年5月1日起，访问UIDIDs的程序将不再被审核通过，替代的方案是开发者应该使用“在iOS 6中介绍的Vendor或Advertising标示符”。所以UDID是绝对不能用啦。
OPEN UDID，没有用到MAC地址，同时能保证同一台设备上的不同应用使用同一个OpenUDID，只要用户设备上有一个使用了OpenUDID的应用存在时，其他后续安装的应用如果获取OpenUDID，都将会获得第一个应用生成的那个。但是根据贡献者的代码和方法，和一些开发者的经验，如果把使用了OpenUDID方案的应用全部都删除，再重新获取OpenUDID，此时的OpenUDID就跟以前的不一样。可见，这种方法还是不保险。
广告标示符，是iOS 6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -> 通用 -> 还原 -> 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广 告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。
Vendor标示符，也是在iOS 6中新增的，跟advertisingIdentifier一样，该方法返回的是一个 NSUUID对象，可以获得一个UUID。如果满足条件“相同的一个程序里面-相同的vendor-相同的设备”，那么获取到的这个属性值就不会变。如果是“相同的程序-相同的设备-不同的vendor，或者是相同的程序-不同的设备-无论是否相同的vendor”这样的情况，那么这个值是不会相同的。
推送token＋bundle_id的方法：
应用中增加推送用来获取token获取应用bundle_id根据token+bundle_id进行散列运算apple push token保证设备唯一，但必须有网络情况下才能工作，该方法不依赖于设备本身，但依赖于apple push，而苹果push有时候会抽风的。
UUID是Universally Unique Identifier的缩写，中文意思是通用唯一识别码。它是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。这样，每个人都可以建立不与其它人冲突的 UUID。在此情况下，就不需考虑数据库建立时的名称重复问题。苹果公司建议使用UUID为应用生成唯一标识字符串。
iOS中获取UUID的代码如下:
-(NSString*) uuid {
CFUUIDRef puuid = CFUUIDCreate( nil );
CFStringRef uuidString = CFUUIDCreateString( nil,puuid );
NSString * result = (NSString *)CFStringCreateCopy( NULL,uuidString);
CFRelease(puuid);
CFRelease(uuidString);
return [result autorelease];
}
开发者可以在应用第一次启动时调用一 次，然后将该串存储起来，以便以后替代UDID来使用。但是，如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备。这就需要各路高手想出各种解决方案。所以，之前很多应用就采用MAC Address。但是现在如果用户升级到iOS7（及其以后的苹果系统）后，他们机子的MAC Address就是一样的，没办法做区分，只能弃用此方法，重新使用UUID来标识。如果使用UUID，就要考虑应用被删除后再重新安装时的处理。
一个解决的办法是：UUID一般只生成一次，保存在iOS系统里面，如果应用删除了，重装应用之后它的UUID还是一样的，除非系统重置 。但是不能保证在以后的系统升级后还能用（如果系统保存了该信息就能用）。
