“SwiftData inheritance relationship”

Thanks for your clarification. For my curiosity: @main struct FoodGuardApp: App { var body: some Scene { WindowGroup { ContentView() } .modelContainer(for: FoodItem.self, configurations: [ ModelConfiguration(Default, cloudKitDatabase: .shared) ]) } } The above code doesn't build (because .shared isn't supported), does it? The sharing worked locally (between users in the same Apple ID)... If the code doesn't build, I am super curious how the sharing worked locally ... I am guessing that you probably added .shared with your own code by extending ModelConfiguration.CloudKitDatabase, and that SwiftData falled back to .private because it didn't know .shared. That will explain why the synchronization of the private database works, but is definitely not the way to support CloudKit sharing. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks a lot, Ziqiao, for your quick response. You’re absolutely right – I now realize that .shared CloudKit containers are not yet supported with SwiftData. In my implementation, I attempted to use a SwiftData model with a ModelContainer(for:sharing:) configuration and used UICloudSharingController to manage sharing between Apple IDs. The ModelContainer was configured like this: @main struct FoodGuardApp: App { var body: some Scene { WindowGroup { ContentView() } .modelContainer(for: FoodItem.self, configurations: [ ModelConfiguration(Default, cloudKitDatabase: .shared) ]) } } The sharing worked locally (between users in the same Apple ID), but failed when another Apple ID accepted the share, producing this error: CKError: Bad Container (5/1014) Couldn't get container configuration from the server for container iCloud.com.de.seki.FoodGuard Based on your reply and DTS confirmation, I now plan to migrate my project to Core Data + CloudKit, using NSPersistentCloudKitContainer and UICloudSharin

As of today, SwiftData + CloudKit integration doesn't support CloudKit sharing, as you can see that ModelConfiguration.CloudKitDatabase only has private(_:). I am wondering what SwiftData with CloudKit sharing means in your context. If you don't mind to share more details about your implementation, together with the code snippet that triggers the CloudKit error, I'd probably have more to comment. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Precedent & Fairness in Enforcement Rove is an intentional, safety-forward dating product. It is neither spammy, low-effort, nor duplicative — and yet we continue to face rejections under Guideline 4.3(b). This raises serious concerns about selective enforcement of App Store policy. In the past 60 days, Apple has approved a wide range of new dating apps, including: • Ready: Dating & Relationships – Launched June 3, 2025. Marketed as a native app for “intentional dating,” with a thematic approach directly comparable to Rove. • Meetline – Launched May 15, 2025. A transit-based connection app that limits conversations, just like Rove limits user visibility to avoid overload. • Yuzu – Asian Dating & Friends – A non-swipe app tailored to a specific community — proof that niche dating concepts are not inherently duplicative. • Metya / DateGuard – Two safety-first apps that use community filters and moderation-centric design. These are directionally aligned with Rove’s own innovation in safety a

First off, ruling an issue out here: However, when our tool is installed from a Standard Account, the macOS messages asking for confirmation to access the Desktop or Documents or Downloads folder don’t appear and access to the file/folders is denied. Does your app include all of the relevant tcc strings (NSDesktopFolderUsageDescription, etc.)? Also, one thing to be careful of here is that there are a bunch of heuristics in this system that control how/when these are presented, which can make knowing why something is working a particular way difficult to determine. When you're looking closely at an issue like this, I'd always suggest working on a totally clean machine*, not your normal development machine. *VMs are handy for this, as you can get the system to a fully configured state, then duplicate the VM image so you can always start over from the same exact starting point. We install a Photoshop plug-in and it’s mainly a UI which then executes a background app containing the business logic to read/write fil

Thank you Quinn for the insights! It's quite a coincidence indeed, I hadn't seen that other thread yet! I think I found that ancient Q&A while searching the Documentation Archive for Authorization information (or maybe on a comment you left in an older thread). Before filing a bug report, I'd like to clarify whether this is actually a bug or simply a missing feature. What puzzles me specifically is the behavior of Activity Monitor.app: Even when I use rights that are explicitly configured as non-shared (like authenticate-admin-nonshared), Activity Monitor still appears to inherit the credentials. I also tried to configure com.apple.activitymonitor.kill with a timeout of 0, but that didn't help. The only way I've found to prevent this behavior is when the original application explicitly calls AuthorizationFree() with the .destroyRights flag. However, newer versions of System Settings don't have the lock icon you mentioned, so they appear to not be destroying these rights (even if I close the windo

I am not asking for help fixing a crash. I did that by commenting out one line of code where I was asking SwiftData to sort ModelA results on a title string from an associated ModelB object. ModeB has a one to many association to ModelA and must exist before any ModelA objects are created BUT CloudKit requires that you specify the relationships between these two models as Optional. Therefore when I tried to sort ModelA results by a Title in ModelB I needed to declare the property as a force unwrapped title of ModelB in the SortDescriptor. It would be ludicrous to try to show the actual code so that you can follow everything. Suffice it to say that this SortDescriptor was accepted by the compiler, and gave me exactly what I wanted when I ran the App either in a Simulator or on a device that downloaded the app from Xcode. BUT when the app was uploaded to the App Store and then downloaded from TestFlight the App would immediately crash with no useful error pointing to the problem. Bottom line i

As a workaround, it does seem that if I log in to a GUI session as the root user (https://support.apple.com/en-us/102367) and enable my FSKit module as the root user in System Settings, then automount works (even from a regular user). Seems like some kind of “modules enabled as the logged in user” vs “modules enabled as the root user” discrepancy. Yeah, there are a bunch of places in the system where logging in as root will change the normal system behavior. There's a common Unix pattern macOS inherits, which is that the root is both a: Standard user account (which is why you can log in). The user ID the system uses as the owner ID for stuff it doesn't want some other specific user to own. Going back to here: enable my FSKit module as the root user in System Settings, then automount works (even from a regular user). What's going here is that there's a split between the system's extensions (which work) and the user's extensions (which should work, but don't). Strictly speaking, logging in as root shou