“SwiftData inheritance relationship”

Can you try only adding the capabilities and permissions on the main app when you archive? The extensions should inherit these, rather than need to also have a declaration.

Getting back to this! Thanks again or the detailed response. The ugly truth is we need exec_b to be run from exec_a and by thirdparty tools that might need to call up it's UI. Think of exec_a as a sort of launcher program that orchestrates exec_b instances it's called up but so too do other parts of our pipeline, potentially. [quote='831858022, DTS Engineer, /thread/778169?answerId=831858022#831858022'] Add com.apple.application-identifier and com.apple.developer.team-identifier to your App. [/quote] Where should this be put? In the entitlements.plist we use while signing App? If we're to test the .inherit entitlement to just get exec_a launching exec_b, you're describing something like: # codesign other binaries... (macdeployqt does much of this work) # Sign child exec codesign ... --entitlements=./entitle_child.plist .../exec_b # Then sign the App (including the com.apple.application... tags) codesign ... --entitlements=./entitle_app.plist .../App.app Apologies if I'm missing the mark here. App val

interferon, thanks for responding. Doing another google search for answers I learned that SwiftData and CloudKit only do private databases. So, I need to wait for the next best SwiftData update in order to have a public database. I can wait. So SwiftData and Cloudkit are not using public databases at this time.

It’s hard to offer a definitive answer to this because my focus is primarily technical and your relationship with your vendors is very much a business relationship. However, there are two standard ways to approach this. Both of them start with adding your developer to your team. From there: You can set their privileges such that they can do all the work on your behalf. See Developer > Support > Articles > Program Roles for info on what’s what there. You can give them limited privileges and have them send you an Xcode archive (.xcarchive), whereupon you deal with the final distribution step by loading that into Xcode. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you for the answer. I'll keep the printing function in mind. As for my original issue, I later found that it was likely due to 2 embedded NavigationStack. Removing the duplicated inner stack resolved the issue. I was able to continue, but got another hang with basically the same query. I am at the point where the time I've saved with the more concise syntax of SwiftData has been completely lost to debugging issues. I will revert back to CoreData. Even if it is more code, I feel like I have better control of the behaviour and life cycle.

Hi there, I encountered the same error when defining mutual @Relationship references (one-to-many or many-to-many relationships) between two models. Have you found a solution? thx

[quote='831680022, mmccartney, /thread/778169?answerId=831680022#831680022, /profile/mmccartney'] Each of our executables require the same entitlements: [/quote] This is potentially confusing, so let’s go to a table: Entitlement App Child ----------- --- ----- ….app-sandbox true true ….inherit - true ….cs.disable-library-validation true true ….files.user-selected.read-write true - ….network.client true - ….network.server true - In this table: App is your main application and Child is any program is spawns as a child process. - indicates that the entitlement shouldn’t be claimed at all. In general, you shouldn’t claim an entitlement with a false value, that just causes confusion. For the last three rows, you don’t need to, and mustn’t claim, the entitlement because these are part of your static sandboxed, which is what the second row is about. [quote='831680022, mmccartney, /thread/778169?answerId=831680022#831680022, /profile/mmccartney'] And if it's all going to TestFlight then I suppose it's restri

No, there is no reference cycle and memory leak here. By using @Model, hat and owner are converted to computed properties, and some logics are implemented there to maintain the integrity of the relationship. Those details are barely documented, but conceptually, SwiftData takes care the integrity and so you don't need to worry about that. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Quinn! Thank you for your efforts and details. Your posts on this forum have been a lifesaver for those of us new to the world of Apple development/deployment. Current Entitlements Each of our executables require the same entitlements: com.apple.security.app-sandbox com.apple.security.cs.disable-library-validation com.apple.security.files.user-selected.read-write com.apple.security.network.client com.apple.security.network.server From the research into the articles you posted, it seems like these are all safe to inherit but I could be wrong about that! And if it's all going to TestFlight then I suppose it's restricted? The lib validation is disabled because we include a plugin ecosystem through Qt. I've tried adding the com.apple.security.inherit in our entitlements but am still seeing the same issue. Here's the entitlements for the exec_b (and exec_a) > codesign -d --entitlements - exec_b Executable=/Users/foo/src/SomeApp.app/Contents/MacOS/exec_b [Dict] [Key] com.apple.security.app-sandbox [Valu

It should be possible to get this setup working. You mentioned TestFlight, which suggests you’re targeting the Mac App Store. If so, all your executables must be sandboxed. If you plan to spawn exec_a as a child process of exec_b then exec_b has to use sandbox inheritance. See Resolving App Sandbox Inheritance Problems. The other potential gotcha is entitlements. If exec_a uses restricted entitlements [1] then those entitlements get authorised by the provisioning profile embedded in the app bundle. If exec_b also needs restricted entitlements then things get trickier. So, does exec_b need any restricted entitlements? A restricted entitlement is one that must be authorised by a profile, as explained in TN3125 Inside Code Signing: Provisioning Profiles. Finally, I have a bunch of hints and tips on this topic in Resolving Trusted Execution Problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Which it’ll need for a Tes