CODEWITHSUNDEEP
swiftcore-data
Steven Lord
Steven Lord

Reputation: 263

Core Data DB Location Debug v Release Build

I have been developing my first SWIFT MacOS App and it uses Core Data. I've just done my first release build and found that it still points at the same SQL Lite DB as my debug build. As I didn't not specify it's location I assumed (incorrectly) it would be in a different location for release.

How do I specify the location of the Database for Core Data ? Is there a way to automatically set a different location for Debug and Release ? I want to be able to run release and debug on the same machine.

Upvotes: 2

Views: 292

Answers (2)

Tom Harrington
Tom Harrington

Reputation: 70976

What I usually do is have separate debug and release versions of the app. Then I can have both installed on the same device at the same time. The persistent store (and other files) use the same file names, but since they're separate apps the data is separate.

You can do this by duplicating the app target in Xcode, and making a few changes. In the list of targets, right-click your app and select "duplicate". Give the new one a similar but slightly different name. For example, maybe add "-dev" to your app's name to indicate it's the development target.

You'll also need to change the bundle ID and display name of the app. The bundle ID tells iOS it's a different app, and the display name makes it obvious which one you're tapping. You can also add a different app icon if you like.

Now you can build two versions of the app and install both on the same device. The dev version can have whatever code you're working on that's maybe still kind of broken, and the release version can be whatever's ready for release or a version downloaded from the App Store.

Upvotes: 2

CouchDeveloper
CouchDeveloper

Reputation: 19174

In iOS, your CoreData database file is usually located in Library/Application Support within the sandboxed App. Pre iOS 10 it used to be in the Documents folder.

On MacOS with sandboxing enabled it's usually located at ~/Library/Containers/<app_bundle_id>/Data/Library/Application Support/<app_target_name>

Depending on your needs, you can choose different locations for each of your persistent stores when you setup the CoreData stack.

However, I don't see any reason to choose different store locations for different Build Configurations. Thats not the purpose for Build Configurations anyway. Your database will end up being exactly the same - it cannot be affected by build settings.

I would also not recommend to use different store locations for any purpose - except perhaps when you perform Unit Tests.

What you can do however, is to set certain environment flags that affect CoreData's behaviour, for example that enables Thread Violation Assertions. You do this in Xcode Schemes - not in the build settings. Note, that a scheme uses a certain Build Configuration, say Release or Debug and that the name for the scheme can be the same which is often confusing.

You should ensure that these helpful assertions that you can set in a Scheme are not enabled when you build a release. ;)

Upvotes: 0

Related Questions