Mac sandbox created but no NSUserDefaults plist

Question

I'm trying to track down some issues arising from sandbox creation. Under multiple circumstances it appears that an NSUserDefaults .plist file is not created in Data/Library/Preferences. I have seen this in the debugger and when launching the app from the Applications directory. I have not tried archiving, signing the app and then launching. Is that required?

An alias file ending in .LSSharedFileList.plist is created but it points to itself and therefore does not exist.

I don't know if it's related but Console reports:

appleeventsd[72]: <rdar://problem/11489077> A sandboxed application with pid ... checked in with appleeventsd, but its code signature could not be validated ( either because it was corrupt, or could not be read by appleeventsd ) and so it cannot receive AppleEvents targeted by name, bundle id, or signature. Error=ERROR: #100013  { "NSDescription"="SecCodeCopySigningInformation() returned 100013, -." }  (handleMessage()/appleEventsD.cp #2072) client-reqs-q

Thanks.

Answer 1

Just moving this into a full answer so it doesn't get missed. I only read it after trying the other solutions when this was solved in a few clicks.

@greg and @mehals answer in the comments section for the first solution solved it for me without needing to change any of my code

Killing cfprefsd did the trick from activity manager.

Answer 2

After spending a ton of time found freaking simple solution:

- (void)fixDefaultsIfNeeded{
    NSArray *domains = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask,YES);
    //File should be in library
    NSString *libraryPath = [domains firstObject];
    if (libraryPath) {
        NSString *preferensesPath = [libraryPath stringByAppendingPathComponent:@"Preferences"];

        //Defaults file name similar to bundle identifier
        NSString *bundleIdentifier = [[NSBundle mainBundle] bundleIdentifier];

        //Add correct extension
        NSString *defaultsName = [bundleIdentifier stringByAppendingString:@".plist"];

        NSString *defaultsPath = [preferensesPath stringByAppendingPathComponent:defaultsName];

        NSFileManager *manager = [NSFileManager defaultManager];

        if (![manager fileExistsAtPath:defaultsPath]) {
            //Create to fix issues
            [manager createFileAtPath:defaultsPath contents:nil attributes:nil];

            //And restart defaults at the end
            [NSUserDefaults resetStandardUserDefaults];
            [[NSUserDefaults standardUserDefaults] synchronize];
        }
    }
}

Answer 3

I ran into this on 10.10 when I trashed the container directory of my app but didn’t empty the trash.

On 10.10, I can consistently recreate the app’s property list file not getting created if the container directory is still in the trash and it getting created successfully if the trash is empty.

So, the solution (at least for my issue) is to always empty the trash after deleting the container directory of a Sandboxed app while testing.

Answer 4

Swift 2 solution

let settingsDefaults = NSUserDefaults.standardUserDefaults();    

func registerSettingsPlist() {
        let sourcePath = NSBundle.mainBundle().pathForResource("Settings", ofType: "plist");
        let appDocsDirURL = self.applicationDocumentsDirectory;
        let destinationPath = appDocsDirURL.path?.stringByAppendingString("/Settings.plist");
        if (!NSFileManager.defaultManager().fileExistsAtPath(destinationPath!)) {
            do {
                try NSFileManager.defaultManager().createDirectoryAtPath(appDocsDirURL.path!, withIntermediateDirectories: true, attributes: nil);
                try NSFileManager.defaultManager().copyItemAtPath(sourcePath!, toPath: destinationPath!);
            } catch let error as NSError {
                print ("Error: \(error.domain)")
            }
        }
        let settingsDic = NSDictionary(contentsOfFile: destinationPath!);
        NSUserDefaults.standardUserDefaults().registerDefaults(settingsDic as! [String : AnyObject]);
        self.settingsDefaults.synchronize();
    }


lazy var applicationDocumentsDirectory: NSURL = {
            let urls = NSFileManager.defaultManager().URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask);
            return urls[urls.count-1];
}();

Answer 5

Could this be related to the caching of NSUserDefaults?

In recent OS X versions the defaults are not immediately written to disk so you might not see them right away. You might want to try synching the prefs manually - From NSUserDefaults Class Reference:

At runtime, you use an NSUserDefaults object to read the defaults that your application uses from a user’s defaults database. NSUserDefaults caches the information to avoid having to open the user’s defaults database each time you need a default value. The synchronize method, which is automatically invoked at periodic intervals, keeps the in-memory cache in sync with a user’s defaults database.

Although I believe even that might not immediately write the defaults to disk in 10.9 anymore as some daemon caching the user defaults is now also involved.

Check also

Reading NSUserDefaults from helper app in the sandbox

Objective-C NSUserDefaults caching prevents another app from accurately reading changes

When (not) to abuse NSUserDefaults