Mobile app monetization and distribution network W3i is announcing the results of its tests to determine whether or not an iPhone’s MAC address can serve as a replacement to the UDID (the unique device identifier), which Apple is phasing out as a way for developers to track an app’s users.
According to W3i, developers can and should begin tracking the iPhone’s MAC address as a UDID alternative, as it has successfully seen Apple approve its own application where this is the case. Unfortunately, this advice is arguably premature. Apple may let slip a single app, but if a large number of iOS developers began doing the same (tracking the MAC addresses, that is), Apple may certainly change its position on the matter.
For background, in August, Erick reported how Apple sneaked a major change into iOS5: it was deprecating developer access to the UDID. The UDID, an alphanumeric string unique to each Apple device, has been used by mobile ad networks, game networks, analytics providers, developers and app testing systems like TestFlight. In some cases, developers used the UDID to verify whether users were accessing their app from a new device or as a way to track users across apps.
Since that change was revealed, companies have been scrambling to come up with workarounds. OpenFeint announced its UDID replacement OFUID. AppsFire proposed an open source solution called OpenUDID. And now W3i is suggesting developers use the iPhone’s MAC address – specifically the MAC address of the device’s Wi-Fi network interface.
The MAC address, also a unique identifier, is used for communications on a physical network segment. What W3i wanted to determine was whether or not that address could be reliably captured across multiple device types and with different configurations (e.g., airplane mode, Wi-Fi off or on, not in range, etc.)
Using its proprietary app, AppAllStar, which was submitted and approved on October 5th, W3i collected 78,662 MAC addresses from 10/5 to 10/22, representing 100% of the installs across iPhone, iPod Touch and iPad devices. The app was also resubmitted during that time (on Oct. 1oth) to correct some non-test related errors. In both cases, the company says it placed the code at a very high level while also naming the classes appropriately.
W3i, however, did find that 33 devices had a duplicated MAC address, which W3i thinks may indicate either jailbroken or knock-off devices. A subset of those had spoofed UDIDs as well. The data on where the duplicates were located is interesting. China and the Netherlands each had 9 duplicates, Italy had 5, Spain 3, Saudi Arabia 2, and Singapore, the U.S., Australia, Czech Republic and India each had 1.
Based on these findings, W3i is now recommending that developers begin collecting and storing Wi-Fi MAC addresses with the associated UDID and modify the application logic to use both UDID and the Wi-Fi MAC address.
Of course, all this advice may be worthless in the long run. A test involving a single application is by no means definitive proof that this is something Apple would allow on a larger scale. After all, considering that the removal of developer access to the UDID was intended to better respect user privacy, simply allowing developers to switch to a second unique ID would violate the spirit of Apple’s decision, if not the actual terms.