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
Related
I am trying to write a thumbnail provider extension (on macOS) that accesses the Core Data store of the main application, shared via an app group, to find images to base icon thumbnails on. This worked fine until I added one attribute to the Core Data model. Now the extension always crashes with An error occurred during persistent store migration and attempt to write a readonly database.
Creating a new default model version and deleting the Core Data Store doesn't help. Somehow the thumbnailer extension still thinks that the store written by the main application uses an earlier model, which makes no sense.
If I set shouldMigrateStoreAutomatically to NO, I get The managed object model version used to open the persistent store is incompatible with the one that was used to create the persistent store.
If I set readOnly = YES on the NSPersistentStoreDescription, I get The file couldn’t be saved because you don’t have permission. which I think may be a concurrency isse, caused by lots of thumbnail provider threads trying to migrate the store all at once.
EDIT: Original code here: https://github.com/angstsmurf/spatterlight/blob/quicklook/SpatterlightThumbnails/ThumbnailProvider.m
Right, I got this to work, but I'm not sure how.
Some of the things I did: cleaned up the build folder, deleted all copies of the main application from my hdd, built a new release version of it, put it in Applications, picked that one when Xcode asked me to choose an app to run after building the thumbnail provider extension. That still didn't work, but afterwards I no longer got any store migration errors when building and running in Xcode.
So basically the problem seems to have been that Xcode picked an old build of the main application to run along with the extension, which created an old version of the Core Data store. Or the old store was still being cached somewhere. Just cleaning the build folder was not enough to fix this.
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?
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.
I have a Cocoa application for which I've changed the name. I'm using the excellent Sparkle Framework (http://sparkle-project.org) to provide updates to my users.
Unfortunately, it appears that Sparkle doesn't support application name changes out of the box. I'm hoping there is some hack so that I can provide users who already have the app with an update to the newly named version.
I'm not sure this is possible using only the vanilla Sparkle framework. The reasoning is that the file name of the application can differ from the CFBundleName defined in Info.plist. Sparkle needs to ensure it is updating the correct file system structure, no matter what it may be named.
Consider the following scenario:
User downloads and installs Adium.app whose CFBundleName is Adium.
User renames it to Instant Messenger.app.
Sparkle downloads and installs an update.
After the update, the file name of the newly updated app is still Instant Messenger.app and the CFBundleName is still Adium.
You can either hope that the fact that your application name has changed in the menu bar will prompt the user to rename it themselves, or your can pull some trickery at application startup to quit the application, rename it, and re-launch it if certain criteria are satisfied. I don't recommend the latter though, users do not like applications deciding to move themselves around without permission.