How can I reset a cocoa application in Xcode? When I run my application from Xcode all user default are saved. I would like to reset (delete) my application to create a new one with new settings and run as it would be run first time.
I found one way - I change a name of my app to a different one and it is started as new. But how can I do this with an old name?
You can use the defaults command line tool to remove all the settings, you just need the bundle id of your app (which you can find in your Info.plist file), e.g. if your bundle id is "com.foo.barApp" then you can run this from a terminal shell:
defaults delete com.foo.barApp
Is your app limited to the App Store? If so, I don't think there's a way to delete your entire application, specifically because of the sandbox restrictions. We'd need more information on how you are planning to distribute it to help.
If you just want to delete your app settings, then clear whatever database you store your app data in - [NSUserDefaults +resetStandardUserDefaults], SQLite, App Library directory, whatever. That is dependent on how/where you are storing user data, there's no one size fits all solution.
Related
I am distributing my OS X application on individual USBs and, for this reason, everything must be self contained.
The app itself lets users input information and then saves this information to an existing text file (specifically an ObjectDB database). Herein is my problem.
I'd like to keep this text file inside the app itself (i.e. inside the Content folder) so it's out of the way and can't be deleted by the average user. But once the app is signed, it seems the text file can't be altered with any new information without getting flagged by Gatekeeper. Is this really the case? There's no way to store data files within apps now?
I'd appreciate any suggestions. Thanks.
Yes, you are correct. If you modify the application package, the signed package is no longer valid. That's kind of the purpose of signing a package.
Your options are to store the text file in a temporary folder on the user's computer, or to instruct your users to disable gatekeeper (don't do this).
I develop a Mac app that saves and loads files of a unique type. The type is properly declared in the info.plist under CFBundleDocumentTypes, listed as LSHandlerRank: Owner and CFBundleTypeRole: Editor. I am releasing a new version of my app and I would like that if users who already have a previous version of my app on their machine install the new version but keep the old version also installed, the new version automatically takes over the file association for this type from the old version of the app. But the default OS behavior seems to be to grant the earliest installed app associated with a file type to be it's permanent owner unless the user manually changes it. I know that the command line tool duti can make association changes, and also the system file com.apple.LaunchServices.plist can be edited, but these don't seem like the best or most reliable way to go about this programmatically from an app. Is there any "right"/Apple-sanctioned way to do what I want?
The official, Apple-sanctioned way for an application to set the default application for a file type is probably to use their provided LSSetDefaultRoleHandlerForContentType function. This function sets the values stored in LaunchServices.
Here is the limited official documentation on how to use this API in Objective-C and Swift.
There doesn't appear to be any way to do this via Info.plist, as the first application get's set as the user preferred application. The user must change their preferred application, which you can facilitate with the above API.
I have the following situation:
I have Mac OS bundle with application which uses some 3rd party dynamic libraries and those libraries depend on some environment variable, let's name it ENV_VAR. I want to set ENV_VAR to some value for my application only because if I set it for the whole system it may breaks some other apps. And it should work transparently to the user i.e. he just run my app from the Application folder by double clicking it. How can I achieve it?
NOTE: dynamic libraries are loaded before main functions starts hence setting this variable in the main doesn't help.
You can add a key "LSEnvironment" to your app bundle's Info.plist. The value can be a dictionary with strings for keys and values and those key-value pairs will be added to the environment when your app is launched by Launch Services (e.g. from the Finder or Dock but not from the Terminal).
<key>LSEnvironment</key>
<dict>
<key>ENV_VAR</key>
<string>value</string>
</dict>
However, in my testing (on Snow Leopard), it was a bit flaky to test, at least when editing the Info.plist of an existing app. Basically, Launch Services caches this part of the app's Info.plist when it first encounters the app and won't necessarily recognize changes on disk. You can sometimes prompt it to reread the Info.plist by, for example, duplicating the app bundle or temporarily moving it to a different folder. Of course, the overkill solution would be to use lsregister to flush and rebuild the cache:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -seed
This caching issue won't affect your end users, just you as you tweak the Info.plist. Also, it shouldn't affect you if you make the change in your source Info.plist and then build the app using Xcode.
I am not sure if the following works because I don't have such an app to try. The idea is to set the environment variable from the terminal, then call your application:
ENV_VAR=something open -a YourApplication
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'm building an application that I hope to submit to the Mac App Store. The app has an SQL database that stores all of the items that the user has created.
Does anyone know where I should be storing this to comply with Apple's guidelines? Should it go in Application Support, the Documents folder, the Library or somewhere else??
Generally, you shouldn't automatically create file in the user home directory, except in ~/Library/Application Support/<Application>. So either let the user choose where to store the information (if it is document centric), or store it in Application Support.
See the question: What location do OSX/Cocoa applications generally use to store data files?