“missing package product”

Hello! I'm trying to notarize my first app. My notarization submissions via xcrun notarytool submit are hanging indefinitely. The upload completes, but the processing never finishes. Upload ID: d1a3ef28-4255-4938-96e1-c6a9b73beb06 122ba838-f362-44fb-aaff-bbf27ec9d963 Details: Artifact type: macOS .app bundle packaged as .zip via ditto -c -k --keepParent Signing identity: Developer ID Application Code signing flags: --force --options runtime --deep Architecture: arm64 (also amd64 in previous attempts) macOS version: Darwin 25.3.0 What I've verified: Code signature passes codesign --verify --deep --strict

That page seems pretty clear to me: If your certificate expires, users can still install packages that were signed with this certificate as long as the package includes a trusted timestamp. However, I encourage you to test this for yourself: Make sure your package has a notarisation ticket stapled to it. Set up a VM. Download your package to it in a way that sets quarantine. Disable networking on the VM. (This is why stapling the ticket is important.) Use System Settings to change the time to well after your package’s expiry date. Try installing it. I expect to work, but I’d love to hear your experience either way. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks again for the extensive answer! To be clear, we got things covered regarding not being able to continue doing work in the background. What was unexpected to us however was the behaviour of the setServiceStatus method, but now I understand its use-case is different from what we thought it was. Especially because one of the values of the enum is connecting we thought we should use it to track the connection state from the client side of things. And then you run into trouble as soon as the application is moved to the background because you will lose the ability to update the state, so the last state will stick. And as the PTT UI actually is only accessible when your app is in the background, this didn't make sense to us.

Hi Richard, Thank you for the clear explanation and the suggested workaround. I understand now that there is no official API to fetch assets specifically from the Recently Deleted album, and that using UIImage to create a new asset would result in the loss of critical metadata. Regarding your question about our goals: Our intent was to provide a better UX by warning users before a save operation results in an invisible asset (due to the automatic grouping with deleted items). Since we cannot reliably detect this state via the current Photos Framework, we will evaluate whether to handle this by pre-processing the metadata or by filing an enhancement request through Feedback Assistant as you suggested. I appreciate your time and the technical insights provided throughout this discussion. Best regards, Jimmy

Out of curiosity, I just tested this, and I still see the bug. To see it yourself, just use the code from my first post but change the savingURL accessor to use a security-scoped bookmark, as follows: To be honest, that was basically a blind (well, slightly educated...) guess. To be honest, the whole combination of factors is fairly odd (timing is random, failure self-corrects, etc.). One thing to pass along— I just did a bit of testing with retrying the copy, and clearing the error seems to be tied to TIME, not retry count. If you decide to go the retry route, you may want to delay the save for a second or so instead of just retrying over and over. I’m actually doing (b), since this is very fast on copy-on-write volumes such as APFS even for large files. (Copy-to-temp file is almost instant.) I think very fast actually understates how significant the performance difference is. As an industry, I'm not sure we've really processed how constant-time copying should change file management. For slower volumes, much

@DTS Engineer: Thanks for chiming in, Ed. I've just received a notification that this issue has been addressed in Xcode 26.3, which introduced a setting to enable individual width for navigators/inspectors in window tabs. It's great that the Xcode team listens to our feedback. P.S. My next rant that I'm about to post will be regarding the bug FB19249805 to highlight another productivity downgrade in Xcode 26: the inability to open files in new window tabs, which destroys workflows that have been established for many years.

@csdevfr Thank you for the recommendation. My initial message included a link to the report with the sysdiagnose. For context, here are my current setup: • TestFlight builds. • Production cards. • Apple certification stage - the step where you need to select a lab for certification. Our card provider insists that the encryption API is working as expected and that their SDK relies on the same implementation. Unfortunately, they haven’t been very responsive. I’m hoping to receive the nonces from Apple so we can confirm whether the issue is on their side and have clear evidence to ask them to thoroughly verify everything.