“missing package product”

Hello Jayko, The App Store Server API, specifically the Get Transaction History endpoint, allows you to review the history of one-time purchases, consumables, and non-renewable subscriptions in the sandbox (and production). You can retrieve the sandbox account’s transaction history using any transactionId, originalTransactionId, or appTransactionId. Additionally, you can use the optional productType filter with the value set to NON_RENEWABLE to narrow down the transactions to only those of non-renewable products. Here's the link to the Get Transaction History endpoint: https://developer.apple.com/documentation/appstoreserverapi/get-transaction-history

I have this problem with a private repo (which I have full access) on github.com too. Things I've tried (with Xcode not running) that did not help: deleting DerivedData deleting org.swift.swiftpm in both Library and Library/Caches deleting Xcode user defaults (com.apple.dt.Xcode) removing github items from Keychain Access restarted Mac after deleting above Each time I try to resolve packages it fails with SSH Key failed to verify. When I click on Edit Credentials it asks for my GitHub Personal Access token. I have an ssh key. It works everywhere except in Xcode - this also worked a month ago from within Xcode. This feels like it broke in Xcode RC2. The only thing that works is to run xcodebuild -resolvePackageDependencies in the terminal in my repo root. Which is a pain when you do a lot of branch switching or merging main into the branch. This is also how I know that the key works fine and I suspect it's a problem with Xcode itself.

Thank you, Quinn. Regarding the warning: security verify-cert -c /path/to/cert confirms the Developer ID Installer certificate chain is valid (no errors). The unable to build chain to self-signed root warning appears with both productbuild --sign and productsign, but the resulting signature passes pkgutil --check-signature and notarytool accepts it. The same team's Developer ID Application certificate signs the .app inside a ZIP without any issues — that ZIP passes Gatekeeper on the same machine. Regarding cross-over testing: Unfortunately I only have access to macOS 26.3 (beta 3) at the moment, so I cannot test the cross-over cases right away. However, here is what I can confirm on macOS 26.3 alone: Step Result pkgutil --check-signature Signed with Developer ID Installer, valid notarytool submit Accepted stapler validate Valid spctl -a --type install Rejected syspolicyd log meetsDeveloperIDLegacyAllowedPolicy = 0 The .app (via ZIP) is signed with Developer ID Application from the same team and passes spctl -

Same Problem here, submitted a Ticket... id : , status : 422, code : ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING, title : Beta contract is missing for the app., detail : Beta Contract is missing. } ] }

[quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] Our IPC implementation is based on [/quote] I find it strange that this is limited to sockaddr_un. macOS is not unusual in longer paths; I don’t know about Linux, but pretty much all the BSDs work this way. [quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] Are there any guarantees the path returned by this function will always fit within the buffer sockaddr_un? [/quote] I’ve never seen such a guarantee. [quote='878482022, Pavel, /thread/817602?answerId=878482022#878482022, /profile/Pavel'] are there any other locations for IPC sockets that avoid this path length restriction? [/quote] The traditional location for this stuff is /var/run. See the hier man page. But if you do use that, choose an appropriately unique file name to avoid collisions with the system and other third-party products. Typically that means using reverse DNS or embedding your company or product name

Resolved. Of course I did it to myself, but #Xcode could have warned me. Package dependencies either direct or indirect in my project are A <- B <- C <- D <- E <- App where x <- y means x is a dependency of y. I was writing tests for package C. To make test setup easier I called functions in package D and E, adding D and E as dependencies to C. Oops. Don't do that. Apparently adding C and C_C is how Xcode handles circular dependencies.

After completely losing my mind on this I solved it! I moved /System/Library/AssetV2/com_apple_MobileAsset_iOSSimulatorRuntime to an external drive to free some space and that broken the download. I simply removed the symlink without restoring the original folder and everything went back to normal. Hope this helps somebody else!

The find command returns nothing when the app is built with XCode 26.3 or XCode 26.2. Is there a build setting that ensures that libswiftCompatibilitySpan.dylib gets included? I've tried copying it in build phases, but that crashes the main app. I do have Always Embed Swift Standard Libraries set to yes in the main app. Including the sample code in the helper (NB: the helper tool doesn't have an app delegate - it's a command line tool) also doesn't resolve the crash. If it's helpful, here's the relevant piece of the crash log from the helper: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/libswiftCompatibilitySpan.dylib Referenced from: <91AD8720-25FD-3ABB-B10A-6A7630E7BA48> /Users/USER/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/MyApp.app/Contents/MacOS/com.micromat.TTDaemon Reason: tried: '/usr/lib/swift/libswiftCompatibilitySpan.dylib' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cr

Thank you for your post. It is intriguing that you are considering restricting device installations. I would be more interested in understanding the specific reasons behind your desire to avoid iPad installations. Supported Destinations: iPhone / UIDeviceFamily: 1 : By itself, this does not prevent iPad installation. It simply tells the App Store: “this app is designed for iPhone. The App Store will still allow iPad users to download it, and it will run in compatibility mode (the letterboxed, zoomed-in iPhone screen on an iPad). However the UIRequiredDeviceCapabilities: telephony iPads (even cellular models) do not have the telephony capability (the ability to make standard cellular phone calls). By adding this to your Info.plist, you are telling the App Store that your app physically cannot function without a phone dialer. I believe that means the App Store will completely hide your app from iPads and iPod Touches. Then again, apps that run on an iPhone should be allowed to run on an iPad in compatibility mo