build disappears

[quote='808475021, StanLey-Pliszko, /thread/808475, /profile/StanLey-Pliszko'] Why does local codesign --verify pass but Apple notarization service fails? [/quote] I’ve seen this happen for a couple of reasons: Case sensitivity Packaging To test the first: Create a case sensitive APFS disk image. Use the Finder to copy your app to it. Run your codesign --verify test against that copy. On the packaging front, it’s common for apps using third-party tooling to not follow the guidelines in Placing content in a bundle. When that happens, the app can end up with a code signature that relies on extended attributes. And when that happens you can run into problems during notarisation because of the various ways that those extended attributes are packaged. To test this: Build your app to a disk image. Use xattr to check entire app bundle for extended attributes starting with the com.apple.cs. prefix. Finally, I want to address two other things that are unlikely to be the cause of this issue but you should fix

[quote='808594021, AckwelFoley, /thread/808594, /profile/AckwelFoley'] the end goal is to mount a user's entire home directory via my FSKit [/quote] That’s gonna be really challenging. FSKit is based on app extensions, and app extensions are fundamentally scoped to a given user. [quote='808594021, AckwelFoley, /thread/808594, /profile/AckwelFoley'] Is there a way to enable my FSKit module globally [/quote] No. Honestly, I think that’d make a reasonable enhancement request. On the networking side of things, macOS allows developers to package a Network Extension provider as a system extension, which runs globally. If you do file an ER, please post your bug number, just for the record. What’s your distribution plan here? Is this something you’re building for yourself? Or something you plan to ship to a wide range of users? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Any updates? Our builds are still stuck during the Archive step. Ticket 102756662562. Would appreciate any guidance.

If all your assertions about the portal settings, provisioning profile, the entitlement file and it's contents are correct, the remaining cause I can think of for the signed app not having the entitlement is either the entitlement file is not being built into the bundle, or there is a different entitlement file being build into the bundle that is missing the aps-environment key. I would suggest to check the building/signing process you are using that it is not missing the correct entitlement file. Of course it wouldn't hurt to double check that your previous assertions about the various relevant points are still correct.

My issues might even be better solved with FSActivateOptionSyntax, but I don't know where to find the docs for it. Or how to propably use it. Yeah, that's probably meant to be used for your situation. I think you're supposed to be able to provide a path then you can get a security-scoped URL that you can use to access that specific path while sandboxed. I briefly looked at that a while ago but I don't think most of the Info.plist keys are documented right now. Most of the documentation right now is just scouring the forums or Apple's open-source FSKit extensions for examples (or, if you're lucky, replies to your feedbacks), which isn't too great. My (untested, could be wrong) assumption was that if you were to set something like shortOptions abc:d: Then on the command line you'd be able to pass options like -a or -b, while -c=arg and -d=arg both take additional arguments. I never needed it for my own extension though so I didn't look too hard, but the forums post you listed suggests that the ability to get a

Thank you! Your explanation about .listRowSeparator(.hidden) being row-specific (and not global to the entire List) was exactly what I needed. I was only applying: .listRowSeparator(.hidden) .listSectionSeparator(.hidden) to the List itself, assuming it would hide all separators automatically — but as you pointed out, SwiftUI requires the modifier to be applied on every row. What I did to fix it I added: .listRowSeparator(.hidden) directly to each transaction row inside my custom content view: ForEach(...) { ... } .listRowSeparator(.hidden) Then I also added it to: the header Section for each day the top block inside ReportMensileView (statistics + month picker + total + picker) This ensured that every row rendered by the List has the separator explicitly hidden. Result All the “mysterious horizontal lines” immediately disappeared, without breaking: native List scrolling swipe-to-delete custom rounded card backgrounds grouped Sections Everything now renders perfectly clean. Thanks again for pointing