This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Mac OS X: Where should I store save games for a game delivered as a bundle?
i am migrating my iOS game to mac. The file I used to store high scores is saved under xxx.app/Contents/Resources. However, when I enable the sandbox and entitlement, the directory becomes unwritable. I tried xxx.app and xxx.app/Contents as well without luck.
so which directory should I use or which entitlement should I add?
EDIT
I have tried ~/Library/Application Support/Your Game Name/ and it does not show permission errors but unable to save the game data. there is no Library under user/my_name, but one under unser/shared. Do i need to add any entitlements?
EDIT 2:
Please dont close this question. The answer to earlier question does not work for me. Instead, the flagged answer of this question is correct.
Under app sandboxing your app has a container folder in which it can write pretty much anywhere, however I would recommend just writing to the Data/Documents folder, which can be obtained using the following code:
NSString *documentDir = [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) objectAtIndex:0];
This will give you the folder at ~/Library/Containers/com.yourdomain.yourapp/Data/Documents. Note that the ~/Library folder is hidden under Lion/Mountain Lion so needs to be unhidden using this on the command line:
$ chflags nohidden ~/Library
(Only you, the developer, needs to unhide that folder so you can poke around from Finder to see what your app has written; your user's won't need to unhide it to use your app).
Related
I have a file that's in my NSBundle, and I'd like the user to be able to save it anywhere they'd like on their computer. How would I be able to do that? I'm using Xcode 8.1, Swift 3, and making a macOS Cocoa application. Thanks for your help!
Use NSSavePanel to obtain the destination URL from the user
Use NSBundle to obtain the source URL in your app bundle
Use NSFileManager to copy the file
If once you've read the documentation, or written some code, you get stuck ask a new question showing where you've got to and what your problem is.
HTH
I am writing an app for Maverick.
The app creates a folder under /user/document, named "folder.db".
All the user related files will be in a folder "folder.db".
I would like to associate my app with "folder.db" directly, so that clicking on it would open my app and not the Finder.
How to achieve that?
Note: I tried to play with the UTI settings in xcode but not luck...
First .db is generally used for databases. So probably not a good idea. What you are looking for is a package or bundle in Cocoa terms. In Cocoa you want to look for the fileWrapper methods. Those create package/bundle files that are folders with a special flag bit set to make it act like an opaque file in Finder
You might want to study NSWorkSpace, NSFileManager, NSBundle, NSDocument and NSOpenPanel and NSSavePanel.
Those will get you on the path.
My mac os app get a NSURL of alias by user interaction (drag & drop), so the app have the permission to read the alias file, but it doesn't have permission to read the origianl file within app sandbox (Mac OS X 10.7/8).
I resolve the alias by
NSData* bookmark = [NSURL bookmarkDataWithContentsOfURL:aliasURL error:nil];
origURL = [NSURL URLByResolvingBookmarkData:bookmark
options:NSURLBookmarkResolutionWithoutUI
relativeToURL:nil
bookmarkDataIsStale:nil
error:&error];
When I try to read origURL file, I get the error: The file couldn’t be opened because you don’t have permission to view it.
I aslo tried call the start/stopAccessingSecurityScopedResource on the origURL but no help.
I also tried resolving bookmark data with NSURLBookmarkResolutionWithSecurityScope option, but get "The file couldn’t be opened because it isn’t in the correct format." error from URLByResolvingBookmarkData method.
So, How do it? Thanks.
I haven't tried this, but I think I might have an idea what's happening. The way OS X punches through the sandbox with drag-and-drop is by granting the app the files are dropped onto access to the dropped files until the app quits. This works using the plain NSString file paths on the pasteboard, so it does not rely on the security scoping mechanism.
Your app probably has access to the alias file, but only that file, not the one to which it refers. The sandbox hole-punching mechanism probably doesn't follow the alias and grant access to the underlying file. If you can get the path of the file to which the alias points (and I'm not sure that's possible), you can get around the sandboxing by prompting the user to select that file in an NSOpenPanel. That's another way of punching through the sandbox, using what Apple calls the "Power Box".
For more information on how to do this, check out the answer I wrote here: https://stackoverflow.com/a/11786156/105717. It links to another answer, then adds some helpful niceties to make what's happening clearer to the user.
Maybe, just maybe my similar situation and solution will help:
Have you definitely got the entitlement "com.apple.security.files.bookmarks.app-scope" set to "yes" in your entitlements file?
"The file couldn’t be opened because it isn’t in the correct format." I was getting this same error when trying to resolve the bookmark, that turned out to be the fact that the file was locked in Finder (do a 'get info' on the file and check the 'locked' box is off) so the security data was never generated in the first place.
Hope there's something in there to help!
Todd.
I've been playing around with an app I want to submit to the Mac App Store, and part of the functionality is simply grabbing a file the user chose by dragging or opening, and saving a modified of it to the same directory as the original file (but with a different file name).
I don't want to use a 'Save' dialog box, as that destroys the utility of the application I'm building, but it looks like that might be the only way the app would be allowed—under sandboxing requirements—to write a file to an arbitrary location (arbitrary, in this case, being in the same folder as the existing file) on the disk as a new file.
Is there any way I can approach this without disabling sandboxing? Also, if I submit the app without entitlements/sandboxing turned on today, will it be approved by Apple (supposing it passes all the other requirements), or are they already turning down non-sandboxed apps?
For your first question, no, I don't believe there is any way to write to a file the user didn't specify, unless it's either in your app's container, or (as of 10.7.3) in a directory you have a security-scoped URL for. See the documentation here. If the user specifies a file, I doubt you get permissions to the enclosing folder, but it's worth a shot.
Answering your second question, as of today, Friday April 27th, 2012, the App Store does not require sandboxing. The latest deadline given was June 1, 2012.
I have another question dealing with app sandboxing. So I need access to the users' home directory and at the same time the app should be able to shut down the Mac. This requires to not using sandboxing.
My problem is that I don't know how to remove sandboxing and being able to submit the app to the Mac App Store. I think that the archives are sandboxed because I had turned it on once..
How to remove sandboxing from the archives properly?
Thanks for your help!
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
If I understand what you are asking correctly, you'll need to remove the entitlements.plist from your project and make sure that the Summary view of your target in Xcode has sandboxing turned off:
As Derek Wade pointed out, you can make an App like GarageBand X (which behaves obnoxiously with third party plugins like Amplitube due to Sandboxing) NOT run in a sandbox by editing the binary itself with a HEX editor like HexFiend. Look for:
<key>com.apple.security.app-sandbox</key>
Immediately following that bit you'll see the true tag, which as suggested I switched to 'fals' (no extra bytes) and now GarageBand will happily interact with third party VST plugins. Huzzah.
I found if you go into the .app package, under Contents/MacOS, there should be a binary file that matches the name of your app. Copy that file to your desktop. Edit the desktop copy of the file with TextEdit. You should find within the file, the text representation (xml) of the Entitlements for the app. Find the Sandbox entitlement flag (usually set to <true/>) and change it to <false/>. You will have to unlock the file when editing. Save the file (located on the desktop). Rename the original file in the .app package (i.e. append .old to the filename). Copy the desktop file back to the .app Package location (you may have to authorize it). This should remove the sandboxing.
You cannot remove Sandbox if the user ran you application via Sandbox.
That's the whole point - don't you think ?