NSOpenPanel in sandboxed app ignores provided directory URL

Question

I am building sandboxed OS X app (OS X 10.10.5, Xcode 6.4). In the course of execution I open NSOpenPanel object. Then I run next snippet:

NSString* s=[@"~" stringByExpandingTildeInPath]; 
NSOpenPanel* panel = [NSOpenPanel openPanel];
[panel setCanChooseDirectories:YES];
[panel setCanChooseFiles:NO];
NSURL* url=[NSURL fileURLWithPath:s];
if(url){
    [panel setDirectoryURL:url];
}
[panel setAllowsMultipleSelection:YES];
[panel beginSheetModalForWindow:[self.outlineView window]completionHandler:^(NSInteger result) {}

My expectation is that panel opens in directory /Users/xxx/Library/Containers/com.123456.App/

Instead that the panel opens in directory /Users/xxx

Application is actually built and deployed into directory /Users/xxx/Library/Containers/com.123456.App/Data/

While debugging I observe that at this point:

if(url){
    [panel setDirectoryURL:url];
}

url contains correct value: file:///Users/xxx/Library/Containers/com.123456.App/Data/

Any idea?

Souther

Answer 1

Is there a reason why you want to use an NSOpenPanel in the app's container? The container is meant for the app's internal data/support files (which users generally should not need to access). NSOpenPanel/NSSavePanel are used for the user to select a file/directory out of their own documents, which would not be located in the container.

Also, consider using NSFileManager URLsForDirectory:inDomains: to get an NSURL to the desired path.

Lacilacie

Yes, I have a reason and according to Apple guidelines I MUST use NSOpenPanel if I want to browse directories – Souther

Right, but using NSOpenPanel to browse your app's container does not make sense. No user data should be stored in the container, only your app's internal files which the user should not be accessing directly. Regardless, is there any difference if you use NSURL* url=[NSURL fileURLWithPath:NSHomeDirectory()]; – Lacilacie

@Boris - you only need to use NSOpenPanel to have the user grant you access to files your app does not already have access to. Files in your container can be accessed directly, and you can find the contents of a directory using the usual APIs. – Arboreal

My scenario is that, when app first runs, it creates a couple of sample user files. Ideally these would be in a Documents/MyApp subfolder but sandboxing puts them into the equivalent sandbox location instead. So I then want user to be able to browse/open them, using NSOpenPanel. But as per original post, NSOpenPanel ignores the sandbox path and in fact just presents Documents folder to the user. So what is the appropriate way to set up this scenario up in conformance with Apple guidelines and sandboxing restrictions? – Along

I'm running into the same issue. I have a quick save button to save files to the documents directory (They get saved to the sandbox directory), then I want the user to be able to open the saved files with NSOpenPanel, but that opens the users actual documents directory! I don't want the user to have to open a NSSavePanel just to save the docs. But, I cannot save to the user's document directory without NSSavePanel. Annoying. I have not found a way around this. – Pertinent