Is it possible to copy a different plist into the application bundle code wise??

Question

Hello all again. My question is stated above in the title but I'll write it here again

Is it possible to copy a different plist into the application bundle code wise??

This is actually a bit related on my previous question ;) http://stackoverflow.com/questions/1125048/create-a-dictionary-property-list-programmatically

But since I can write out the plist (and test if I'm doing something wrong ) I was wondering if I can copy my written file

[testBook writeTofile:@/Users/jack/testbook2.plist" atomically:NO];

to my application bundle in code (so that it can read from here with NSString *path = [[NSBundle mainBundle] bundlePath]; NSString *dataPath = [path stringbyAppendingPathcomponent:@"testbook2.plist"];

Another alternative is good as well for instance if I can read my plist directly from another path instead of the mainBundle

Answer 1

I don't know exactly what you're doing, but depending on your application, you might want to use the Application Support directory:

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, YES);
if ([paths count] > 0) {
    NSString *path = [[paths objectAtIndex:0] stringByAppendingPathComponent:@"App Name"];
    // Create the directory if it doesn't exist, etc.
} else {
    NSLog(@"Fail!");
    // ...
}

Answer 2

Physically, yes it is possible sometimes.

NO, DON'T DO THAT!!

Okay... copying stuff into your App Bundle is bad, your app bundle is not where you keep settings or data. You should think of your app bundle as readonly. You should do this for several reasons:

1. While most of the time a user on a Mac OS X system has permission to write to an app sometimes they don't. Think about children who are not using admin accounts, or lab deployments at schools.
2. It will invalidate codesigning. If you sign your application this will change the signature and break the codesign, causing all sorts of weird issues (losing any firewall permissions the app has, telling the user the app has changed and asking them for keychain permission again, etc). In the future this may also pop up all sorts of warnings since tampering with an app is a big security red flag.
3. It won't work on iPhone. That may not be an issue, but if you every intend to use this code on an iPhone the apps bundles are sandboxed readonly

The correct place to put this sort of stuff is into a sub folder of the Application Support folder