Default store location #36

Closed
opened 2025-12-29 15:22:43 +01:00 by adam · 4 comments
Owner

Originally created by @jamesbebbington on GitHub (Feb 1, 2016).

I'm in the process of transitioning to CoreStore from AERecord and have noticed that by default (on iOS at least), CoreStore is saving the DB in …/Library/Application Support/ whereas before my app had it in …/Documents/.

Apple's Core Data Programming Guide sample code uses .DocumentDirectory. Is CoreStore correct to use Application Support?

Originally created by @jamesbebbington on GitHub (Feb 1, 2016). I'm in the process of transitioning to CoreStore from AERecord and have noticed that by default (on iOS at least), CoreStore is saving the DB in `…/Library/Application Support/` whereas before my app had it in `…/Documents/`. Apple's [Core Data Programming Guide](https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/CoreData/InitializingtheCoreDataStack.html#//apple_ref/doc/uid/TP40001075-CH4-SW1) sample code uses `.DocumentDirectory`. Is CoreStore correct to use `Application Support`?
adam added the question label 2025-12-29 15:22:43 +01:00
adam closed this issue 2025-12-29 15:22:43 +01:00
Author
Owner

@JoeMatt commented on GitHub (Feb 1, 2016):

We actually got rejected and had to resubmit due to our sql location. User generated data can be in either location you mentioned but ingested data should use the Caches directory. So really it depends

@JoeMatt commented on GitHub (Feb 1, 2016): We actually got rejected and had to resubmit due to our sql location. User generated data can be in either location you mentioned but ingested data should use the Caches directory. So really it depends
Author
Owner

@JohnEstropia commented on GitHub (Feb 2, 2016):

@fractious That depends on the nature of your store. Quoting "Where You Should Put Your App’s Files" section in the File System Programming Guide,

Where You Should Put Your App’s Files
To prevent the syncing and backup processes on iOS devices from taking a long time, be selective about where you place files. Apps that store large files can slow down the process of backing up to iTunes or iCloud. These apps can also consume a large amount of a user's available storage, which may encourage the user to delete the app or disable backup of that app's data to iCloud. With this in mind, you should store app data according to the following guidelines:

  • Put user data in Documents/. User data generally includes any files you might want to expose to the user—anything you might want the user to create, import, delete or edit. For a drawing app, user data includes any graphic files the user might create. For a text editor, it includes the text files. Video and audio apps may even include files that the user has downloaded to watch or listen to later.
  • Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle.
  • Remember that files in Documents/ and Application Support/ are backed up by default. You can exclude files from the backup by calling -[NSURL setResourceValue:forKey:error:] using the NSURLIsExcludedFromBackupKey key. Any file that can be re-created or downloaded must be excluded from the backup. This is particularly important for large media files. If your application downloads video or audio files, make sure they are not included in the backup.
  • Put temporary data in the tmp/ directory. Temporary data comprises any data that you do not need to persist for an extended period of time. Remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device. The system will periodically purge these files when your app is not running; therefore, you cannot rely on these files persisting after your app terminates.
  • Put data cache files in the Library/Caches/ directory. Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file. Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed.
@JohnEstropia commented on GitHub (Feb 2, 2016): @fractious That depends on the nature of your store. Quoting _"Where You Should Put Your App’s Files"_ section in the [File System Programming Guide](https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html), > Where You Should Put Your App’s Files > To prevent the syncing and backup processes on iOS devices from taking a long time, be selective about where you place files. Apps that store large files can slow down the process of backing up to iTunes or iCloud. These apps can also consume a large amount of a user's available storage, which may encourage the user to delete the app or disable backup of that app's data to iCloud. With this in mind, you should store app data according to the following guidelines: > - Put user data in Documents/. User data generally includes any files you might want to expose to the user—anything you might want the user to create, import, delete or edit. For a drawing app, user data includes any graphic files the user might create. For a text editor, it includes the text files. Video and audio apps may even include files that the user has downloaded to watch or listen to later. > - Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle. > - Remember that files in Documents/ and Application Support/ are backed up by default. You can exclude files from the backup by calling -[NSURL setResourceValue:forKey:error:] using the NSURLIsExcludedFromBackupKey key. Any file that can be re-created or downloaded must be excluded from the backup. This is particularly important for large media files. If your application downloads video or audio files, make sure they are not included in the backup. > - Put temporary data in the tmp/ directory. Temporary data comprises any data that you do not need to persist for an extended period of time. Remember to delete those files when you are done with them so that they do not continue to consume space on the user’s device. The system will periodically purge these files when your app is not running; therefore, you cannot rely on these files persisting after your app terminates. > - Put data cache files in the Library/Caches/ directory. Cache data can be used for any data that needs to persist longer than temporary data, but not as long as a support file. Generally speaking, the application does not require cache data to operate properly, but it can use cache data to improve performance. Examples of cache data include (but are not limited to) database cache files and transient, downloadable content. Note that the system may delete the Caches/ directory to free up disk space, so your app must be able to re-create or download these files as needed.
Author
Owner

@JohnEstropia commented on GitHub (Feb 2, 2016):

By default, CoreStore uses the Application Support directory as SQLite files are assumed to be preferred as hidden from the user.

@JohnEstropia commented on GitHub (Feb 2, 2016): By default, CoreStore uses the Application Support directory as SQLite files are assumed to be preferred as hidden from the user.
Author
Owner

@jamesbebbington commented on GitHub (Feb 2, 2016):

Thanks guys, that makes sense.

@jamesbebbington commented on GitHub (Feb 2, 2016): Thanks guys, that makes sense.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#36