“missing package product”

I've made a change to our app. We have a faceless helper app that we used to use for running all our scripts. It uses XPC for communication between it and the main app. It was developed many years ago when we needed to stop blocking the main thread when multiple jobs were running scripts. I updated it a few days ago to use ScriptingBridge (like we'd previously done to the main app). This has been used in production now for a couple days. We no longer experience crashes caused by the low level AE system (AECreateEmptyEvent, etc). That's the good news—the AE errors for one job no longer take out the app and any other jobs. I do still get problems that appear to be empty replies from telling the InDesignApplication (an SBApplication subclass) to doScript:ourScript. This mostly happens when running multiple jobs at once and when I switch our main app in and out of the foreground. I assume doing that jiggles a lot of Jell-o. I don't know what would cause that; the AE system, SB, or InDesign.

Oof, good luck with ReactNative. I haven't used any IAP ReactNative library, so I'll speak in terms of native StoreKit. On a somewhat relieving note, I also have this issue in my Swift-native iOS app, and I made a post about it on the forums, too. It happens both in Sandbox and production, but NOT when using Local StoreKit Testing configuration files. There are multiple ways for you to observe StoreKit updates. You can observe transactions with Transaction.updates, and also just the subscription updates themselves with SubscriptionStatus.updates. Technically, these are different, but of course a new transaction means potential for a subscription status update. Basically, I had to implement logic to de-duplicate subscription updates that were redundant. For every Subscription update I get, I map it to an array for what I see as active subscriptions. The rest of my app will watch for if my array of active subscriptions changes. If it changes, then we will enabled/disable features. Duplicate transaction

Similar situation. First time app, macOS and iOS versions, no login, no account, no server - just plain SwiftData, CloudKit, and one in-app purchase to unlock lifetime access. TestFlight: macOS build: submitted Feb 09, 2026 -> approved Feb 11, 2026 iOS build: submitted Feb 09, 2026 -> waiting -> re-submitted by incrementing build number Feb 18, 2026 -> still waiting, status on Mar 12, 2026: 'Waiting for Review' In-app purchase: didn't require submission I got enough feedback from my macOS beta testing that I decided to go ahead with the final app approval submission. Production: macOS build: submitted Mar 06, 2026 -> approved Mar 09, 2026 iOS build: submitted Mar 06, 2026 -> still waiting, status on Mar 12, 2026: 'Waiting for Review' In-app purchase: status on Mar 12, 2026: 'In Review' Without the IAP approval, it doesn't even make sense to announce my macOS release to my network because the app will just lock up after 14 days if they're unable to purchase. Why are things happening

Right. I've done a clean build (with only the one, new app group), the entitlements file is correct, and it runs with the correct entitlements on both my dev machine and a Ventura one. Curiously, though, the entitlements validated flag is still not showing as set. I'm waiting to hear back on the results from the Sequoia machine, but I expect that means it's still going to fail. So in the meantime -- could this be an issue with notarization rather than signing? I've just discovered that because we're distributing the app in-house rather than through the App Store, the installer package for these internal releases hasn't been going through notarytool. Is that a deal-breaker under the newer OS versions?

[quote='879525022, dispacthMain, /thread/818199?answerId=879525022#879525022, /profile/dispacthMain'] Do you think standard DNSSettings still should work? [/quote] I don’t know, which is why I suggested you try it. It’s definitely counter-indicated by the docs, but I can’t see anything in the code that blocks it. OTOTH the system is complex, so it’s easy for me to miss things. Of course, if it does work then there’s the question as to whether you should relying on this implementation detail. However, it’s only worth digging into that if it actually works. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for the download link. I’m not sure what the actual problem is here. I ran your app through (roughly) the process described in Testing a Notarised Product, and everything seemed to work just fine. Specifically: In a fresh macOS 26.3.1 VM, I downloaded that zip archive in a way that sets quarantine. I unpacked it using the Finder. And then I opened the app using the Finder. It passed Gatekeeper, launched, and showed its initial UI. I then ran some basic validity checks, and those also passed with flying colours: % syspolicy_check distribution umldiagrammer.app App passed all pre-distribution checks and is ready for distribution. % codesign -v --deep --strict -vvv umldiagrammer.app … umldiagrammer.app: valid on disk umldiagrammer.app: satisfies its Designated Requirement % spctl -vvvv --assess --type exec umldiagrammer.app umldiagrammer.app: accepted source=Notarized Developer ID origin=Developer ID Application: Humberto Sanchez II (NA8Z96F8V9) Please run through these steps yourself and let me

I heard several years ago that there is a software package or equivalent that lets you create a SwiftUI screen design based a Figma submission.