iosopenudid過濾

『壹』 ios應用可以根據哪些數據識別設備

凡是接觸過iOS的開發者都清楚每一台iOS設備都有一個唯一的識別號：UDID，這個40位的字元串是你的設備區別於其他任何一台設備的唯一標識。
這個字元串用處非常大，我們可以把它作為用戶的唯一ID，跳過用戶登陸這一步，直接有效並且安全地與資料庫中的用戶記錄進行綁定。
雖然UDID本身並不含有任何用戶信息，但是由於應用開發者可以將UDID與伺服器上用戶信息進行綁定，從而帶來了諸多隱私泄漏等問題，所以蘋果最終還是拒絕開發者訪問UDID的官方介面，建議開發者使用CFUUID來代替UDID。CFUUID有很多問題，如果從一台設備將系統備份到另一個設備，兩個設備就會擁有相同的CFUUID，如果從臨時文件中備份系統，就會出現一個設備中出現不同的CFUUID，但是盡管如此，CFUUID還是所有UDID替代品中最靠譜的一個。
除此之外，一些第三方開發者也基於CFUUID包裝了對用戶更友好的類，OpenUDID是開發者使用的比較廣泛的一個。
對於AIR開發者來說，僅此還是不夠的。今天我給大家開放一個基於OpenUDID的ANE，使用它可以在AIR項目中通過ActionScript介面來獲得設備的OpenUDID。
AS類OpenUDID是一個靜態類，它只有一個靜態屬性UDID，使用方法用一行代碼表示如下：
var id:String = OpenUDID.UDID;

就這么簡單。

『貳』 ios怎麼獲取openudid

查看IOS固件驗證關閉的方法：1、使用itunes刷機時會提示3194錯誤，代表當前固件驗證已經關閉。2、檢查刷入固件的版本是否為最新的，若固件版本為IOS8.1，而蘋果推出的最新固件為IOS8.1.1，則IOS8.1的固件肯定被關閉。3、使用第三方刷機助手，檢測SHSH是否已經無法獲取，無法獲取表明固件已經關閉驗證。

『叄』 ios 第三方分享組件 哪個最好

網路通信
1、ASIHTTPRequest
這是一個經典的老庫，功能完全而強大，但已經停止更新很久了(iOS5.0停止更新，但是我最近看github上這個項目有新改動)。在不同iOS版本上略微有一些小問題(提醒顯示上的)，所以用的時候還是稍微修改一下比較好。
下載地址：https://github.com/pokeb/asi-http-request

2、AFNetworking
輕量級的通訊類庫，使用非常簡單。
下載地址：https://github.com/AFNetworking/AFNetworking
3、MKNetworkKit
最近做的不錯的一個通訊類庫，具有AFNetworking和ASIHTTPRequest雙方的優點，甚至功能更豐富一些，但是本人還沒有使用過。
下載地址：https://github.com/MugunthKumar/MKNetworkKit
Socket
1、CocoaAsyncSocket
CocoaAsyncSocket是用的最廣泛的socket開發庫，省略了程序員與CFNetwork接觸的時間，延長了程序員壽命。
下載地址：https://github.com/robbiehanson/CocoaAsyncSocket
2、SocketRocket
SocketRocket是Square開發的一個實現webSocket的庫，可以輕松的實現即時通信。
下載地址：https://github.com/square/SocketRocket
數據解析
1、SBJSON
SBJson的解析速度其實是比較慢的，但是不知道為什麼它卻是用的最廣的。
下載地址：

2、JSONKit
JSONKit解析速度上最接近iOS原生解析類，當然iOS5.0才開始支持原生解析，所以選擇一個庫還是很必要的。
下載地址：https://github.com/johnezang/JSONKit

3、TouchJSON
TouchJSON用的也比較廣泛.
下載地址：https://github.com/TouchCode/TouchJSON

4、json-framework
沒有用過。
下載地址：https://github.com/stig/json-framework
5、TBXML
TBXML是一套輕量級的DOM方式的XML解析類庫，有很好的性能和低內存佔用，不過它不對XML格式進行校驗，不支持XPath，並且只支持解析，不支持對XML進行修改。
下載地址：https://github.com/71squared/TBXML

6、TouchXML
TouchXML這也是一套DOM方式的XML解析類庫，支持XPath，不支持XML的修改。
下載地址：https://github.com/TouchCode/TouchXML

7、KissXML
KissXML這是一套基於TouchXML的XML解析類庫，只不過實現了支持XML的修改。
下載地址：https://github.com/robbiehanson/KissXML

8、GDataXML
GDataXML是Google開發的DOM方式XML解析類庫，支持讀取和修改XML文檔，支持XPath方式查詢。
下載地址：

第三方管理
1、fmdb
fmdb是一個資料庫管理庫，封裝了sqlite相關的sql語句，簡化資料庫操作。
下載地址：https://github.com/ccgus/fmdb
2、ssziparchive
ssziparchive與sstoolkit是同一個作者，這哥們兒簡直是個天才。
https://github.com/soffes/ssziparchive
3、ZipArchive
ZipArchive同樣是minizip的封裝。
https://github.com/mattconnolly/ZipArchive
4、Objective-Zip
Objective-Zip將Zlib和MiniZip用Objective-C進行了封裝，使用起來非常簡單。
https://github.com/flyingdolphinstudio/Objective-Zip
5、zxing
zxing是一個開源Java類庫用於解析多種格式的1D/2D條形碼。目標是能夠對QR編碼、DataMatrix、UPC的1D條形碼進行解碼。 其提供了多種平台下的客戶端。
https://github.com/zxing/zxing
6、ZBar
ZBar 是款桌面電腦用條形碼/二維碼掃描工具，支持攝像頭及圖片掃描，支持多平台包括 iPhone 手機。同時 ZBar提供了二維碼掃描的 API 開發包。
https://github.com/ZBar/ZBar
7、ObjQREncoder
ObjQREncoder 是 Objective-C 的二維碼的編碼器，用於生成二維碼圖像。
https://github.com/jverkoey/ObjQREncoder
8、OpenUDID
OpenUDID是iOS禁止使用系統UDID之後的新解決方法。
https://github.com/ylechelle/OpenUDID
9、RegexKitLite
RegexKitLite 是一個輕量級的 Objective-C 的正則表達式庫，支持 Mac OS X 和 iOS，使用ICU 庫開發。
https://github.com/wezm/RegexKitLite
10、STUtils
STUtils是一系列的工具集，包含了很多對於iOS原生類的擴展，當然也包含一個用於安全保存用戶密碼STKeyChain。
https://github.com/ldandersen/STUtils
11、scifihifi-iphone
scifihifi-iphone用於安全保存用戶密碼到keychain中。
https://github.com/ldandersen/scifihifi-iphone
12、sskeychain
sskeychain同scifihifi-iphone一樣，不過屬於輕量級。
https://github.com/soffes/sskeychain
13、SDWebImage
SDWebImage調用網站上的圖片，跟本地調用內置在應用包里的圖片一樣簡單。操作也很簡單。
https://github.com/rs/SDWebImage
14、umeng
umeng既有統計分析，也有社會化組件。但是統計分析的用戶數似乎明顯多於其社會化組件的用戶。
http://dev.umeng.com/analytics/ios/sdk-download

第三方UI
1、appirater
appirater是一個可以直接使用到任何iPhone應用中的開源類，用於提醒用戶在打開App時，對應用進行評論或打分。
下載地址：https://github.com/arashpayan/appirater
2、FDStatusBarNotifierView
FDStatusBarNotifierView 實現了在狀態欄中顯示自定義提醒信息的功能。
下載地址：https://github.com/frankdilo/FDStatusBarNotifierView
3、MTStatusBarOverlay
MTStatusBarOverlay 是一個定製的 iOS狀態欄，用於覆蓋系統默認的狀態欄。
下載地址：https://github.com/myell0w/MTStatusBarOverlay
4、iCarousel
iCarousel 是一個用來簡化在 iOS 上實現旋轉木馬時的視圖切換效果，支持 iPad，提供多種切換效果。
下載地址：https://github.com/nicklockwood/iCarousel
5、MBProgressHUD
MBProgressHUD就不多說了，偉大的菊花。
下載地址：https://github.com/jdg/MBProgressHUD
6、SVProgressHUD
SVProgressHUD是一個輕量級的菊花。
下載地址：https://github.com/samvermette/SVProgressHUD
7、MWPhotoBrowser
MWPhotoBrowser 實現了一個照片瀏覽器類似 iOS自帶的相冊應用，可顯示來自手機的圖片或者是網路圖片，可自動從網路下載圖片並進行緩存。可對圖片進行縮放等操作。
下載地址：https://github.com/mwaterfall/MWPhotoBrowser
8、ShareSDK
ShareSDK支持分享到新浪微博、微信好友、微信朋友圈、QQ好友、騰迅微博、QQ空間、人人網、開心網、豆瓣、搜狐微博、網易微博、簡訊、郵件、列印、拷貝等。但是由於這個SDK包很大，所以用的時候一定要精簡一下。下載地址：http://sharesdk.cn/Download

『肆』 如何在cocos2d-x中獲取手機設備ID

你是指唯一標識嗎 ？
目前的版本 蘋果禁掉了大多數的唯一標識獲取方式 包括以前的UUID mac地址等 現在我們採用OpenUDID 一個開源的方法 你可以網路
每台iOS設備的UDID是唯一且永遠不會改變；
每台iOS設備的OpenUDID是通過第一個帶有OpenUDID SDK包的App生成，如果你完全刪除全部帶有OpenUDID SDK包的App（比如恢復系統等），那麼OpenUDID會重新生成，而且和之前的值會不同，相當於新設備；
是否足夠替代
普通的iOS設備用戶不會沒事就去恢復系統或者抹掉系統，所以一般OpenUDID的值是不會改變的；
在iOS系統升級換代時，會產生較大的影響，畢竟95%以上的iOS設備用戶都會選擇升級到最新的系統；
是否足夠替代就看你對UDID的需求是什麼了，如果要求怎麼都不能變，那OpenUDID可能還是不能滿足你的需求！

『伍』 ios開發者 能拿到 iphone用戶什麼id

下面我將列出iOS中目前支持的，以及被廢棄的唯一標示符方法，並對其做出相應的解釋，希望可以幫你做出正確的確定。

CFUUID
從iOS2.0開始，CFUUID就已經出現了。它是CoreFoundatio包的一部分，因此API屬於C語言風格。CFUUIDCreate方法用來創建CFUUIDRef，並且可以獲得一個相應的NSString，如下代碼：
CFUUIDRef cfuuid = CFUUIDCreate(kCFAllocatorDefault);NSString *cfuuidString = (NSString*)CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, cfuuid));

獲得的這個CFUUID值系統並沒有存儲。每次調用CFUUIDCreate，系統都會返回一個新的唯一標示符。如果你希望存儲這個標示符，那麼需要自己將其存儲到NSUserDefaults, Keychain, Pasteboard或其它地方。

NSUUID
NSUUID在iOS 6中才出現，這跟CFUUID幾乎完全一樣，只不過它是Objective-C介面。+ (id)UUID 是一個類方法，調用該方法可以獲得一個UUID。通過下面的代碼可以獲得一個UUID字元串：
NSString *uuid = [[NSUUID UUID] UUIDString];

跟CFUUID一樣，這個值系統也不會存儲，每次調用的時候都會獲得一個新的唯一標示符。如果要存儲的話，你需要自己存儲。在我讀取NSUUID時，注意到獲取到的這個值跟CFUUID完全一樣（不過也可能不一樣）：
示例: 68753A44-4D6F-1226-9C60-0050E4C00067

廣告標示符（IDFA-identifierForIdentifier）
這是iOS 6中另外一個新的方法，advertisingIdentifier是新框架AdSupport.framework的一部分。ASIdentifierManager單例提供了一個方法advertisingIdentifier，通過調用該方法會返回一個上面提到的NSUUID實例。
NSString *adId = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

跟CFUUID和NSUUID不一樣，廣告標示符是由系統存儲著的。不過即使這是由系統存儲的，但是有幾種情況下，會重新生成廣告標示符。如果用戶完全重置系統（(設置程序 -> 通用 -> 還原 -> 還原位置與隱私) ，這個廣告標示符會重新生成。另外如果用戶明確的還原廣告(設置程序-> 通用 -> 關於本機 -> 廣告 -> 還原廣告標示符) ，那麼廣告標示符也會重新生成。關於廣告標示符的還原，有一點需要注意：如果程序在後台運行，此時用戶「還原廣告標示符」，然後再回到程序中，此時獲取廣告標示符並不會立即獲得還原後的標示符。必須要終止程序，然後再重新啟動程序，才能獲得還原後的廣告標示符。之所以會這樣，我猜測是由於ASIdentifierManager是一個單例。

針對廣告標示符用戶有一個可控的開關「限制廣告跟蹤」。Nick Arnott的文章中已經指出了。將這個開關打開，實際上什麼也沒有做，不過這是希望限制你訪問廣告標示符。這個開關是一個簡單的boolean標志，當將廣告標示符發到任意的伺服器端時，你最好判斷一下這個值，然後再做決定。
示例: 1E2DFA89-496A-47FD-9941-DF1FC4E6484A

Vindor標示符 (IDFV-identifierForVendor)
這種叫法也是在iOS 6中新增的，不過獲取這個IDFV的新方法被添加在已有的UIDevice類中。跟advertisingIdentifier一樣，該方法返回的是一個NSUUID對象。
NSString *idfv = [[[UIDevice currentDevice] identifierForVendor] UUIDString];

蘋果官方的文檔中對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.

如果滿足這樣的條件，那麼獲取到的這個屬性值就不會變：相同的一個程序裡面-相同的vindor-相同的設備。如果是這樣的情況，那麼這個值是不會相同的：相同的程序-相同的設備-不同的vindor，或者是相同的程序-不同的設備-無論是否相同的vindor。

看完上面的內容，我有這樣的一個疑問「vendor是什麼」。我首先想到的是蘋果開發者賬號。但事實證明這是錯誤的。接著我想可能是有一個AppIdentifierPrefix東西，跟鑰匙串訪問一樣，可以在多個程序間共享。同樣，這個想法也是的。最後證明，vendor非常簡單：一個Vendor是CFBundleIdentifier（反轉DNS格式）的前兩部分。例如，com.doubleencore.app1 和 com.doubleencore.app2 得到的identifierForVendor是相同的，因為它們的CFBundleIdentifier 前兩部分是相同的。不過這樣獲得的identifierForVendor則完全不同：com.massivelyoverrated 或 net.doubleencore。

在這里，還需要注意的一點就是：如果用戶卸載了同一個vendor對應的所有程序，然後在重新安裝同一個vendor提供的程序，此時identifierForVendor會被重置。
示例: 599F9C00-92DC-4B5C-9464-7971F01F8370

UDID
在之前的版本中是可用的，但是在iOS5以及之後的版本中，以及被棄用了。雖然，這個UDID用得很廣泛，但是，不得不說的是，它在慢慢的遠離開發者，不能在考慮使用UDID了。至於這個標示符是轉為私有方法，或者完全從以後的iOS版本中移除，還有待觀察。不過，這個UDID在部署企業級簽名程序時，非常方便。獲取UDID的方法如下：
NSString *udid = [[UIDevice currentDevice] uniqueIdentifier];
示例:

OpenUDID
在iOS 5發布時，uniqueIdentifier被棄用了，這引起了廣大開發者需要尋找一個可以替代UDID，並且不受蘋果控制的方案。由此OpenUDID成為了當時使用最廣泛的開源UDID替代方案。OpenUDID在工程中實現起來非常簡單，並且還支持一系列的廣告提供商。
NSString *openUDID = [OpenUDID value];

OpenUDID利用了一個非常巧妙的方法在不同程序間存儲標示符 — 在粘貼板中用了一個特殊的名稱來存儲標示符。通過這種方法，別的程序（同樣使用了OpenUDID）知道去什麼地方獲取已經生成的標示符（而不用再生成一個新的）。

之前已經提到過，在將來，蘋果將開始強制使用advertisingIdentifier 或identifierForVendor。如果這一天到來的話，即使OpenUDID看起來是非常不錯的選擇，但是你可能不得不過渡到蘋果推出的方法。
示例:

『陸』 UDID和OPENUDID被禁用之後如何進行APP的數據分析呢

現階段而言，這些方式可能都要改變，主要有以下幾點：
1、iOS7中，已經無法訪問mac地址，通過api訪問mac地址得到的是 02：00：00：00這個，完全沒用了；
2、以前的UDID的替換方式是 mac address + bundle identifer 然後md5生成的一個字串；
3、綜上所述，OpenUDID 以及 UDID都不是最終的解決方案。

貌似iOS裡面有一個Ad identifer的東西，類似mac地址，但是這個東西可以用戶人為的重置，所以也不是上佳方案。暫時還沒用完整的解決方案。

『柒』 OpenUDID 是什麼

UDID是設備的識別碼。一般運用在電子產品上。Open UDID就是告訴你要輸入識別碼。現在蘋果目前在 iOS 應用審核中加入了一項新政策，禁止應用訪問設備的唯一身份標識符（UDID）

『捌』 OpenUDID 是否足夠替代 UDID 使用有何不同

每台iOS設備的OpenUDID是通過第一個帶有OpenUDID SDK包的App生成，如果你完全刪除全部帶有OpenUDID SDK包的App（比如恢復系統等），那麼OpenUDID會重新生成，而且和之前的值會不同，相當於新設備；是否足夠替代
普通的iOS設備用戶不會沒事就去恢復系統或者抹掉系統，所以一般OpenUDID的值是不會改變的；

『玖』 蘋果手機的設備識別碼是什麼東西

1、UDID ，全稱是 （Unique Device Identifier），顧名思義，它就是蘋果 iOS 設備的唯一識別碼，它由 40 個字元的字母和數字組成，為了保護用戶隱私蘋果已經禁止讀取這個標識了。

2、UUID，全稱是（Universally Unique IDentifier），是基於 iOS 設備上面某個單個的應用程序，只要用戶沒有完全刪除應用程序，則這個 UUID 在用戶使用該應用程序的時候一直保持不變。如果用戶刪除了這個應用程序，然後再重新安裝，那麼這個 UUID 已經發生了改變。UUID 不好的地方就是用戶刪除了你開發的程序以後，基本上你就不可能獲取之前的數據了。

3、MAC 地址，用來定義網路設備的位置。一個主機會有一個 MAC 地址，MAC 地址是網卡決定的，是固定的，為了保護用戶隱私蘋果已經禁止讀取這個標識了。

4、OpenUDID，不是蘋果官方的，是一個替代 UDID 的第三發解決方案， 缺點是如果你完全刪除全部帶有 OpenUDID SDK 包的 App（比如恢復系統等），那麼 OpenUDID 會重新生成，而且和之前的值會不同，相當於新設備；

5、IDFA 廣告標示符，適用於對外：例如廣告推廣，換量等跨應用的用戶追蹤等。IDFA 是蘋果 iOS 6 開始新增的廣告標識符，英文全稱是 Identifier for Advertising ，用於給開發者跟蹤廣告效果用的，可以簡單理解為 iPhone 的設備臨時身份證，說是臨時身份證是因為它允許用戶更換，IDFA 存儲在用戶 iOS 系統上，同一設備上的應用獲取到的 IDFA 是相同的。iOS 用戶可以通過「設置」-「通用」-「還原」-「還原位置與隱私」更換 IDFA，iOS 10 系統開始提供禁止廣告跟蹤功能，用戶勾選這個功能後，應用程序將無法讀取到設備的 IDFA。

6、IDFV，Vindor 標示符 (IDFV-identifierForVendor)，來自同一個開發商（例如 com.hu.app1 和 com.hu.app2）的應用運行在同一個設備上，此屬性的值是相同的；不同的運營商應用運行在同一個設備上值不同。

『拾』 明明就是iOS系統的，結果微信要安裝蘋果定製版的居然提示這個，求助怎麼回事，有誰知道的求告知

您好！很高興能為您解答， 拒絕 iOS 應用獲取設備的 UDID的原因
UDID本來是為了方便一個應用來統計用戶行為的，但是因為是一個唯一ID，而且直接看不到跟用戶隱私的關系，所以是開放出來的。但是，當有大量的App在市場中，而UDID對於每個App都是一樣的時候，用戶的隱私其實受到了一定程度的侵犯。假設有很多App聯合在一起，因為UDID是統一的，那麼他們就可以拼湊出用戶的隱私出來。所以從這個角度蘋果去掉了UDID的支持，而每個應用可以自行生成自己的UUID，所以，單一app的統計仍舊不會發生問題。所以主要的原因是隱私問題。
、必須使用UDID時建議的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來使用。顯而易見，這種方法問題很多。如果用戶刪除該應用再次安裝時，又會生成新的字元串，所以不能保證唯一識別該設備；如果你從一台舊設備中備份文件到新設備中，兩台設備就擁有相同的CFUUID；如果你從臨時文件中備份操作系統，就會出現一個設備里存在不同CFUUID的情況。
2、使用開源方案OpenUDID
貢獻者在readme文檔中說：

OpenUDID is a drop-in replacement for the deprecated [UIDevice uniqueIdentifier] a.k.a. UDID on iOS, and otherwise is an instry-friendly equivalent for iOS and Android.
The agenda for this community driven project is to: – Provide a reliable proxy and replacement for a universal unique device identifier. That is, persistent and sufficiently unique, on a per device basis. – NOT use an obvious other sensitive unique identifier (like the MAC address) to avoid further deprecation and to protect device-level privacy concerns – Enable the same OpenUDID to be accessed by any app on the same device – Supply open-source code to generate and access the OpenUDID, for iOS and Android – Incorporate, from the beginning, a system that will enable user opt-out to match Apple』s initial intent.
願景很好，也確實沒有用到MAC地址，同時能保證同一台設備上的不同應用使用同一個OpenUDID。但是仔細分析，還是能發現問題。

unsigned char result[16];
const char *cStr = [[[NSProcessInfo processInfo] globallyUniqueString] UTF8String];
CC_MD5( cStr, strlen(cStr), result );
_openUDID = [NSStringstringWithFormat:
@"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x",
result[0], result[1], result[2], result[3],
result[4], result[5], result[6], result[7],
result[8], result[9], result[10], result[11],
result[12], result[13], result[14], result[15],
arc4random() % 4294967295];

這里使用了NSProcessInfo類。
當設備上第一個使用OpenUDID解決方案的應用第一次調用時，確實會生成一個唯一的識別碼。同時，為了與官方的UDID位數相同，還在MD5值後面追加了8位隨機碼。然後，該方案使用到了NSUserDefaults類（應用設置）。應用將獲取到的唯一識別碼保存到應用的UserDefaults中，如果程序以後需要使用唯一識別碼，就從UserDefaults中獲取，這樣就保證可以拿到同一個識別碼。但是，如果用戶刪除了應用，UserDefaults同樣會被清空，為了避免重新生成唯一識別碼，該方案還使用到了UIPasteboard類（設備剪切板）。應用在將唯一識別碼保存到UserDefaults的同時，也會將其保存到以特殊的key標識的UIPasteboard中。代碼如：
1
2
UIPasteboard* slotPB = [:availableSlotPBid create:YES];
[slotPB setData:[NSKeyedArchiver archivedDataWithRootObject:dict] forPasteboardType:kOpenUDIDDomain];

其中availableSlotPBid是一個字元串key，前綴是「org.OpenUDID.slot.」，點後面加上數字。這個數字默認是從0到99（當然你可以修改源代碼使它更大或者更小）。
如果設備上安裝了第二個使用OpenUDID解決方案的應用，當應用調用生成OpenUDID的方法時，將會從UIPasteboard中獲取唯一識別碼（遍歷key從0到99的UIPasteboard），這里取到的就是之前第一個應用保存到UIPasteboard中的。也就是說，只要用戶設備上有一個使用了OpenUDID的應用存在時，其他後續安裝的應用如果獲取OpenUDID，都將會獲得第一個應用生成的那個。
看起來似乎很好，很復雜。但是仔細想想，還是有問題，如果把使用了OpenUDID方案的應用全部都刪除，再重新獲取OpenUDID，此時的OpenUDID就跟以前的不一樣了（本人測了一下，確實如此）。可見，這種方法還是不保險。
3、開源方案SecureUDID
稍微看了下SecureUDID源碼，發現其與OpenUDID其實差不多，只是初始獲取的唯一識別碼稍有不同。同時，從作者的Readme文檔中可見，這個方案同樣存在很多問題。如原文：
Is this a true UDID replacement?
SecureUDID has two properties that you should know about before you use it. First, as indicated above, the identifier is not derived from hardware attributes. Second, the persistence of an identifier cannot be guaranteed in all situations. This means that, while unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers. Consider this carefully in your application. Here is a list of situations where this identifier will not exhibit the uniqueness/persistence of a traditional UDID.
* The user has opted-out of the SecureUDID system, in which case you will receive a well-formed string of zeroes.
* Device A is backed up and then restored to Device B, which is an identical model. This is common when someone breaks their phone, for example, and is likely desirable: you will receive Device A』s SecureUDID.
* The SecureUDID data is removed, via user intervention, UIPasteboard data purge, or by a malicious application.
* The SecureUDID backing store becomes corrupt.
* All SecureUDID applications are uninstalled from a device, followed by a UIPasteboard data purge.
我發現，其實前面的OpenUDID也基本存在以上問題，只是作者沒寫出來。看來還是SecureUDID的貢獻者比較厚道。
4、與WIFI MAC地址相關
網上同樣有一些與WIFI MAC地址相關的替代方案，主要分三種：第一種直接使用「MAC Address」；第二種，使用「MD5(MAC Address)」；第三種，「MD5(MAC Address+CFBundleIdentifier)」。github上有個開源項目（UIDevice-with-UniqueIdentifier-for-iOS-5）實現了這幾種方法。
使用這種方法也存在問題：1、市面上有部分機器（雖然數量極少，但是本人在使用過程中確實發現過這種情況）無法獲得MAC地址，有人說這部分機器是聯通閹割無WIFI版的，具體不得而知了。2、MAC地址跟UDID一樣，存在隱私問題。蘋果現在禁用UDID，不能保證以後不會禁用MAC地址。
5、部分大公司私有的解決方案，但是他們怎麼會告訴你呢？
所以，如果你想以一種萬無一失的方法追蹤某台設備，現在還沒有比UDID更合適的選擇。但是，蘋果現在不讓用了，苦逼的開發者們，該怎麼辦呢？