The goal is to verify and ship our own iOS app through App Store Connect. We are not building an endpoint security product. An earlier archive failed SecStaticCodeCheckValidityWithErrors with CSSMERR_TP_NOT_TRUSTED, and a later archive failed codesign --verify --deep --strict with the same trust error. The SecTrust experiment was supplementary and did not verify either product signature. We need to determine whether the current distribution archive can pass Apple's supported signing, export, and validation path, and if not, identify the specific signing input to correct. Is Xcode Organizer's Validate App, including its distribution certificate, provisioning profile, and entitlements review, the right next product-level check? If it fails, which exact Xcode or SecStaticCode error output would be useful to report back?

Thank you for identifying errSecInternal. SecTrust was used as a supplementary diagnostic of the certificates supplied by the embedded CMS, not as a replacement for code-signature validation. On an earlier archive, SecStaticCodeCheckValidityWithErrors returned CSSMERR_TP_NOT_TRUSTED. On the later archive, codesign --verify --deep --strict also failed with CSSMERR_TP_NOT_TRUSTED for arm64. These are different artifacts, so I am keeping those observations separate. Our preserved system logs concern an earlier export operation and cannot be correlated with the -26276 evaluation. Which SecStaticCode CFError fields or system-log subsystem would be most useful to distinguish a signing-input defect from a local trust-evaluation failure? We have kept trust settings unchanged.