I have an existing OSX app that supports OSX 10.5 onwards. I want to publish it to the AppStore and therefore I need to sandbox the app. I guess sandbox app should be supporing 10.7 onwards.
The app uses a folder in the username directory to create temp files etc
It also copies a sql db file which already has empty tables to the same temp folder and upates records as the app is used.
Furthermore if there is a crash it picks up logs from the crashlog folder of osx and requests user to submit them to developer.
Question
with a sanbox app, where do I store temp files ?
Where should I place the db file which can be read/witten to + new App update should be able to find exsting db file.
Should the custom code for crash reporter be kept or be made redundant ?
Thanks
where do I store temp files ?
In the directory recommended by NSTemporaryDirectory(). (This applies to both sandboxed and non-sandboxed applications.)
Where should I place the db file which can be read/witten to
In your application's Application Support directory. Use NSSearchPathForDirectoriesInDomains() to find it, then append your application's name. Again, this is the same whether you're sandboxed or not.
new App update should be able to find exsting db file.
Not possible. You can ask the user to locate the existing file with a NSOpenPanel, but you can't open it yourself, because it'd be outside your sandbox.
Should the custom code for crash reporter be kept or be made redundant ?
You'll need to remove it, because it won't work under sandboxing — crash reports are not stored to your sandbox. You will receive crash reports for your application through iTunes Connect.
Alternatively, you may want to look into a third-party crash reporting service like PLCrashReporter.
There is a mechanism to migrate the data of an existing App into the sandbox: Migrating an App to a Sandbox on developer.apple.com
This is done once the newly sandboxed app is launched the first time. If you can determine where the database was stored, you can migrate it into the sandbox.
Related
I'm quite new to OSX and xCode development so any help here appreciated. I'm developing an OSX app that stores data in core data and I want to clear the core data model so that it gets re-generated without having to do a migration as I've not pushed the app to any devices yet. I'm incrementally playing around and adding entities as well as changing attributes/etc on existing entities.
I get this error when running the app via xcode after I've added an attribute to an already created entity:
The managed object model version used to open the persistent store is
incompatible with the one that was used to create the persistent
store.
I've looked at these questions and answers and I'm not getting them to work:
Deleting CoreData store on OS X?
How do I overcome XCode object model version error?
The answer that seems most likely to resolve this (which doesn't work for me) is to go to ~/Library/Developer/Xcode/DerivedData and delete the application folder there. The DerivedData folder does hold a folder with the name of my application and it does get re-generated when I delete it and have the project open in xCode. In fact I've removed all folders in that DerivedData folder but still the same issue.
Anyone knows how to solve this on OSX xcode 8.1 running El Capitan? My App's deployment target is macOS 10.11.
Assuming this is not a document-based app, the Core Data persistent store file will be located in ~/Library/Containers/[your bundle ID]/Data/Documents/. You can remove the full container or specific files. For a document-based app, of course, it'd be in the document.
On iOS you'd just delete the app, but on OS X it's a little different.
Based on comments etc, I'm sharing two ways I've found that solves this issue for me.
Option 1 - adding app sandbox capability.
Add the capability of 'app sandbox' to your app. The data store then gets moved to the ~/Library/Containers/<appName>. When you want to regenerate the core data store to get around versioning issues, you can then delete that folder.
Option 2 - find out the core data persistent store location via code and then delete those files.
As per Tom Harrington: My app used an NSPersistentStoreCoordinator as U could see in my AppDelegate's core data setup. I got the urls of the persistent stores via this in the AppDelegate.swift (I added this just before where the crash happens when the core data versioning error occurs):
for store in (coordinator?.persistentStores)!
print("store url: \(store.url)")
}
This showed that the location of the persistent story for my app was ~/Library/Application Support/com.apple.toolsQA.CocoaApp_CD/TableViewPlayGround.storedata. FYI: My app bundle id is co.uk.gamba.TableViewPlayGround so this means the data store is not kept in folders relating to my app's bundle when running via xcode. The core data model got replaced without error each time I deleted that file and restarted the app in xcode.
Xcode has always saved the Core Data/Sqlite database files of any given App in that App's Documents folder - by default. But has that just gotten changed in Xcode 8?
I just created a new Core Data App (in Xcode 8.1) and after running the App I couldn't find the usual three sqlite files in the app's Documents folder. Instead, and after much digging around, I discovered those sqlite files in the App's Application Support folder, which is located inside that app's Library folder.
Is this a bug? Or is this the new thing now?
I thought that if we wanted to persist data in an iOS App, the data had to be written into the Documents folder - and that calling saveContext() did just that, automatically.
Anyone know what's going on?
4 Performance: Hardware Compatibility
Performance - 2.4.5
Your app uses still one or more entitlements which do not have matching functionality within the app. Apps should have only the minimum set of entitlements necessary for the app to function properly. Please remove all entitlements that are not needed by your app and submit an updated binary for review, including the following:
com.apple.security.files.downloads.read-write
It is not appropriate to predetermine the path that the user may have their files located.
Apple has indicated it is not in their judgement that your application requires reading or writing in the Downloads folder without user specification.
Disabling the com.apple.security.files.downloads.read-write will still allow users to save and open files located in their Downloads folder through standard interfaces (NSOpenPanel, NSSavePanel).
Note that it will disable your application from saving and opening arbitrary files in the Downloads folder without first being selected by the user.
I am trying to get my app submitted to the mac app store and I am having a bit of a design problem. Our app is an authoring tool and comes bundled with many projects created with the tool. Before the time of the app store, we would ship our app as an .img file which contianed a project directory and our app. Since I am only going to be submitting the .app file to the app store
with my app I am wondering where I should but the projects directory.
Initially I tried to put the projects directory inside of the bundle but this will not work because it is possible for the user to make changes to projects which might add new files to the project directory and this would make the sandboxing unhappy and mark the app as invalid.
What is the correct place to store such resources? I assume they should go inside the container? If so, what would be an elagent way to deploy this projects directory? Since we do not have installers in Apple land what would be the best place to deploy this projects directory? Do I just need to check on app launch if the projects are present and if not copy them from the bundle? This seems wrong.
Do I just need to check on app launch of the projects are present and if not copy them from the bundle?
Actually, this sounds right to me. As you said, the user cannot change/add any files in the app bundle. If you have resources there that the user needs to interact with, I would copy them to the ~/Library/Application Support/MyApp/ folder when they are needed. The user can then interact with the files from that location. (When sandboxed they go into a different but related location.)
I don't really know what your app does, but it would also seem like a possibly useful feature to "reset" the project files/folders back to a starting state. So copying the files in this way would allow for that kind of behavior as well.
I'm going through the effort of migrating an existing Snow Leopard app store application to a sandboxed Lion application. As part of the sandboxing, the Library path moved from ~/Library to ~/Library/Containers/appname/Data/Library.
The user defaults were automagically carried over from ~/Library/Preferences/app.plist to ~/Library/Containers/appname/Data/Library/Preferences/app.plist.
But my core data sqlite store was not. I've searched, but cannot find anything related to this migration.
Do I need to migrate the store manually or am I missing something here? If I do have to migrate it myself, I'm confused with how to access the old store file .. since it resides at ~/Library, which is no longer accessible after being sandboxed..
Any help is much appreciated!
Add a new Property List called "container-migration.plist" to your project.
In the PList editor, add a property (row) called "Move" as type Array.
Add a string to the array pointing to current app data folder. E.g. ${ApplicationSupport}/Your App Name
More info here:
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/MigratingALegacyApp/MigratingALegacyApp.html#//apple_ref/doc/uid/TP40011183-CH6-SW1