Ok, Apple announced that “as of March, 2012 all apps submitted to the Mac App Store must implement sandboxing”, and since we were preparing the release of our new Set Professional desk top app, it would be a great time to introduce it. Little did I realise that I would spend all afternoon tracking down a ‘bug’ that was without error.
SetPro allows access to Dropbox, the first time through the process you are prompted for the application folder, then the .setpro file is saved, and through the wonders of modern technologies synchronised to the cloud.
Subsequent running of the program would simply remember the Dropbox folder location and save the file directly. Or so I thought. No amount of testing, checking NSURL configurations, , would see the file being written to the folder. Go through the process again, set the folder location and hey presto, re-test and failure.
The only difference between success and failure was the use of an NSOpenPanel, even if the NSURL filepath was being set manually.
Enter the Sandbox… The entitlements file was set to use Sandboxing, with read/write access set, but that does not enable me to save directly to any folder, so why is it hit and miss ?
I found an obscure post, that mentions if you present the user with a NSOpenPanel or NSSavePanel then you can save to the URL contained in the panel; HOWEVER, if you have not presented the user this option then you are unable to save outside your Sandbox.
The frustrating part about this whole exercise is that no errors are generated, no exceptions raised, no messages passed through XCode, just the frustration that your file is not saved.