Core Data Lab 3.1 improves compatibility with macOS 27 in multiple ways. A lot of smaller adjustments have to do with some subtle AppKit bugs. However, most changes are related to the “New Features” of System Integrity Protection in macOS 27. This affects only users who use the Search Database function. It required quite some effort to keep the feature working in macOS 27, hence all the prose below.
Normally, sandboxed apps can’t access files outside the app’s sandbox. To get access to a file or folder, the sandboxed app must initiate a user interaction. For example, presenting a NSOpenPanel, to retrieve a security-scoped bookmark for a certain file location. This is also what Core Data Lab does, the first time you open the Search Database function. A NSOpenPanel is presented to select a folder that acts as a search path. The bookmark of this selection is stored by Core Data Lab in NSUserDefaults, for future reuse.
Since macOS 15, a valid folder bookmark is not sufficient anymore to open files located in the folder or subfolders, if the folder is (a subfolder of) one of the two official sandbox app container folders, ~/Library/Containers or ~/Library/Group Containers. System Integrity Protection (SIP) in macOS 15 and macOS 26 displays a confirmation dialog each time an app tries to access data from other developer teams located in one of the two app container folders. It is even possible in Xcode to configure the text that is being displayed by said dialog.
In macOS 27, SIP goes a large step further by not presenting a dialog at all. Access is simply refused without any warning or user interaction. Access to other app containers in macOS 27 is now only possible by giving the app explicit access to other apps’ data containers in the Files & Folders subsection of the Privacy & Security section of the System Settings. This section is dynamically filled with apps that try to access data from other apps. Permissions can be set individually for each accessed app container, per accessing app.
It is perhaps good to understand that SIP access refusals do normally not happen when the app has a direct bookmark to a file, such as a database, within the app containers. The SIP file protection comes only into action when the app tries to access files using a security-scoped bookmark of (a child folder of) an app container folder.
The following features are implemented to keep the Search Database feature in Core Data Lab useful and workable:
A “known issue” when switching from the Core Data Lab Trial version to the release version of Core Data Lab is that SIP may stop trusting any Core Data Lab-related app. To fix this, reset the Privacy & Security settings for Core Data Lab in the Terminal app with the following command:
tccutil reset All betamagic.Core-Data-Lab
This will remove all references to Core Data Lab in the Files & Folders subsection of Privacy & Security settings. To reconfigure the Files & Folders settings for Core Data Lab, first let Core Data Lab access the files where you want to have access to. This will result in adding a fresh “Core Data Lab” item in the Files & Folders subsection of the Privacy & Security settings.
A lot of small changes in macOS 27 forced Core Data Lab to implement some adjustments. The following are not under the hood:
There are several other adjustments in Core Data Lab 3.1:
Core Data Lab owners can download the update for free from the Mac App Store. If you are not yet a Core Data Lab user, you can try the app for free, for 14 days.