Question

Switching to custom generated device UUID’s is turning out to truly be a nightmare! I am hoping someone has come across this before and might know a way to deal with it.

Assume a user has an application with a data set of 500,000 (small) records, its not feasible to simply copy the entire db of a device and merge them. A user has this application installed on an:

1. iPhone,
2. MacBook
3. Android tablet.

When connected to the same physical network, each device can see each other and can initiate a synchronisation.
To achieve three way data synchronisation (that does not depend on a central server or an internet connection).

1. Each device keeps a list of timestamped changes.
2. Each device knows the last time it synchronised with each of the other two devices.
3. When a device sees another device, it sends through all known changes since the last time they spoke to that device.
4. If a new device is discovered, no problem just send through all data ever entered.

The problem comes along if a user backs up their iphone or ipad, and restores it onto another iphone or ipad. Under this scenario we are ending up with a user that has two devices on the local network with the same UUID. Updates end up (randomly) going to one or the other identically identified devices.

I know we can continue to use the device unique identifier for now, but I am worried whats going to happen once its gone!

Answer 1

On application start you search for a file in the applications documents folder called udid.txt. If this file is not available create it and generate your custom UDID, save it to this file. Use the following function to add a flag to this file, to exclude it from the backup and sync routines.

#include <sys/xattr.h>
- (void) AddSkipBackupAttributeToFile: (NSURL*) url
{
  u_int8_t b = 1;
  setxattr([[url path] fileSystemRepresentation], "com.apple.MobileBackup", &b, 1, 0, 0);
}

The problem with this solution is that a user might use iPhoneExplorer or something similar to change the UDID. Try to encrypt or hide the file to prevent him from doing this.

Note: Works only since iOS 5.0.1.