“SwiftData inheritance relationship”

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

The only way around it I've found is to create an intermediate 1:1 model that contains the 1:N relationship since SwiftData won't query 1:1 relationships by default.

[quote='791334021, Nasheet, /thread/791334, /profile/Nasheet'] does the system not give access to the relationship between apps and their categories [/quote] This is not possible unfortunately. I desperately need the same functionality for my app as well. A while ago I sent a feedback request / radar to Apple but haven’t heard anything back: FB16121372 I would urge you to file a feedback request as well: Demonstrate your use-case. Showcase how this would not affect user-privacy (you still don‘t know which app and category are represented by each token, you just know that they’re related). Post your feedback number here as well 🙌 Let’s work on this together and shape the future of the Screen Time API – such an important topic nowadays that deserves more attention by Apple!

@DTS Engineer This is still an issue. For now we stopped using relationships. Instead we store IDs and load entities lazy when accessed.