“build disappears”

Thanks for all that extra info. So, it’s definitely correlated with iOS 26.3. Which is strange, because I can’t think of any iOS 26.3 aligned change to local network privacy that would affect this. You could file a bug about this issue, but I’m not sure it’d get traction. As you noted in your first post, this whole process is a bit of a kludge, and it’s hard to argue that we should fix this (in contrast to FB12846267, which we definitely should fix, but haven’t yet). But if you do file a bug, please post your bug number, just for the record. At this point I think it might be worth considering different approaches. I zenned on that a bit today and I wasn’t able to come up with anything I’m truly happy with. One approach that I like is to have your UI test use some sort of IPC mechanism to the app, have the app connect to the accessory under test, and then proxy the UI test’s requests to that accessory. Unfortunately I couldn’t think of a good way to do that. It is possible to set up an IPC channel between apps

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 passe

[quote='817887021, kappie, /thread/817887, /profile/kappie'] Both produce: Warning: unable to build chain to self-signed root [/quote] Hmmm, that doesn’t sound good. Have you tried testing the cross-over cases? That is: Building on macOS 26.3 and trying to install on macOS 26.2 Building on macOS 26.2 and trying to install on macOS 26.3 Those will let you determine whether this is a build problem or an install problem. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Beta iOS app still waiting in review since Feb 09. My macOS build was approved on Feb 11. Not sure what happened after that. I received a favorable Small Business Program response in about 10 days after I applied I think. Not sure what's happening in the month of February, but at least enough developers are talking about it on here that it's nice to not be alone.

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/P

Hello - Please review this documentation with details for Sandbox testing in a TestFlight build of your app: https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox#Sign-in-to-your-Sandbox-Apple-Account-for-a-TestFlight-app Related documentation to review: Overview of testing in Sandbox Enabling developer mode on a device Testing at all stages of development with Xcode and the sandbox Testing subscriptions and in-app purchases in TestFlight Please let us know if you have any additional questions or need further assistance. Thank you.

The fix is included in iOS 26.4 seed builds. Please let us know if the problem still reproduces there.

OK. When you run this command, what do you see: % find YourApp.app -name libswiftCompatibilitySpan.dylib YourApp.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib libswiftCompatibilitySpan.dylib exists to provide Span support on older systems. AFAICT it’s expected to work on Intel Macs running 13.1 or later: % vtool -show-build Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib (architecture x86_64): Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform MACOS minos 13.1 sdk 26.2 ntools 1 tool LD version 1230.1 … And I tested it here in my office, on both 26.2 (Rosetta) and 13.6.1 (real hardware), and I didn’t have a problem. However, that was from my main app, not from a privileged helper tool, so it’s possible that there’s something specific to privileged helper tools in play here. My test code is pasted in at the end of this email. If you temporarily add this to your app, does it work on the same Intel Mac?