“missing package product”

Lemme take a step back here. ES products typically ship in one of two ways: If they’re consumer focused, they use an ES system extension. If they’re enterprise focused, they use an ES daemon. It sounds like you fall into the latter category. If so, why are you adopting SMAppService? That mechanism is intended for folks shipping consumer focused products. For an ES client that’s targeting enterprise environments it makes sense to stick with an installer package. In short, SMAppService is meant to be a replacement for things like SMJobBless and SMLoginItemSetEnabled, not a replacement for installer packages and launchctl. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It's incredibly easy to miss, I searched for almost an hour a few months back.Go to https://icloud.developer.apple.com/ and log in. Then, select your container on the left side. Afterwards, click on the small cogwheel in the development area (not production!). In this menu you'll find the option to Deploy Schema to Production….

The third-party program does seem to have library validation disabled: I recommend that you discuss this with the tool’s author. The only good reason to disable library validation is if the tool is loading plug-ins from other third-party developers, which seems unlikely. I see a lot of folks disable library validation because they think it’ll make their life easier but, in reality, it makes things harder. Specifically, the combination of disabling library validation and dangling load commands is the number one cause of mysterious Gatekeeper rejections. See Resolving Trusted Execution Problems for the details. So, unless this tool needs to disable library validation, I recommend that you re-enable it. That’s better for security and it helps with Gatekeeper. I thought about notarising, but as far as I understand you can only notarise Apps or Zip files. Am I missing something? Yes. As a general rule you should not notarise each code item separately. Rather, build all your code items into a complete product

I had this error using the latest version of Xamarin. I usually sign the App in Xamarin and then use the Application loader. But got the error you reported. So I did this...1. Made the archive in Xamarin2. Opened Xcoder Organizer (When I tried to publish from here I got an error about the ITunesMetadata.plist)3. Show Package Contents on Archive4. Open Products, Applications, Show package Contents of the Application.5. delete the itunesMetadata.plist6. submit the app from the organizer.7. Sucess

It’s hard to say what’s going on here because you’re using a third-party tool to sign your app. You can find my general advice on how to sign and package a Mac product in: Creating distribution-signed code for macOS Packaging Mac software for distribution I recommend that you compare that advice against what your third-party tooling is doing. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I'm pretty sure that if availability information is missing, that means that the glyph is only available in xOS 26. There is a 3rd party package that imports all of these symbols into a static namespaces so the compiler can check this for you. See https://github.com/SFSafeSymbols/SFSafeSymbols