TestFlight designated requirement and Gatekeeper launch of a store-signed Mac build
Parent: Apple Platform Publishing (Mac App Store) · Published reference · snapshot 2026-10-29
↓ Facts as markdownall context files
Source-anchored research for TestFlight designated requirement and Gatekeeper launch of a store-signed Mac build. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- Apple TN3127 documents codesign --display -r - <app> as a way to inspect an app’s designated requirement. Inspect the exact App Store Connect or TestFlight app under investigation because a development-signed variant can carry a different requirement from the store-distributed variant. (high confidence) [source]
- Apple’s notarization documentation says software distributed through the Mac App Store does not require separate notarization because App Store submission includes equivalent security checks. The electron-builder Mac App Store guide reports the same split between store distribution and direct Developer ID distribution. (high confidence) (verified as of 2026-10-29) [source]
Problems, failure modes and limitations
- The original Mac App Store distribution-signed archive is not a supported general-purpose local launch artifact. Apple says macOS may sometimes run it, but this is unsupported and can fail when the app claims restricted entitlements. Apple identifies TestFlight as a pre-release testing route because it re-signs the app. This separates uploading the archive from running the TestFlight-installed copy. (medium confidence) [source]
Comparisons and alternatives
- A designated requirement (DR) is the code identity test embedded in a signature, and macOS can use it to recognize the same code during later authorization checks. Apple documents `codesign -d -r- <app>` as a way to display the DR. Apple also says TestFlight re-signs an app for testing; therefore, inspect the installed TestFlight artifact itself rather than treating the pre-upload archive's DR as conclusive (the last sentence is an inference from Apple's re-signing description). (medium confidence) [source]
- Apple TN3127 says an Apple Development designated requirement differs from the requirements used by Developer ID and Mac App Store apps; it explicitly says a Mac App Store app will not satisfy the Apple Development requirement, or vice versa. Apple’s code requirements guide says codesign typically derives a default designated requirement from the program name and signature chain when the signer supplies no explicit requirement. (high confidence) [source]
Facts and statements
- Apple's current Xcode guide groups TestFlight and App Store delivery under App Store Connect and says that channel uses an Apple Developer Program distribution provisioning profile. Apple also says TestFlight re-signs the app much like the App Store. Do not treat the local pre-upload Apple Distribution identity as a complete description of the delivered TestFlight artifact. (medium confidence) (verified as of 2026-10-29) [source]
- A sample `spctl --list` output in the PyOxidizer Apple code-signing guide labels a `[Testflight]` rule `allow execute` and lists separate `[Mac App Store]` rules for `allow install` and `allow execute`. This is sample policy output, not a guarantee that current macOS releases use the same labels or requirements. (low confidence) [source]
- Apple’s DTS Gatekeeper troubleshooting guidance focuses on Developer ID-signed code and recommends strict codesign verification; it says Gatekeeper should not block App Store apps. A separate third-party release audit says its signature, notarization, and stapling checks did not install the package. Implementation inference for TestFlight: inspect the delivered beta’s signature and designated requirement and test its actual launch separately, without assuming Developer ID Gatekeeper guidance applies unchanged. (medium confidence) [source]
- A 2024 electron-builder issue reports that an app installed through TestFlight failed to launch. The author said a Developer ID installer package passed notarization but failed Transporter validation, while a Mac App Store installer package passed Transporter but failed notarization. The author later reported success after enabling electron-builder’s notarization option and expressed a belief that it notarized the app before packaging. This is one self-reported workflow result and does not establish that all TestFlight builds require notarization. (low confidence) [source]
- Xcode documents App Store Connect as the distribution method for apps delivered through TestFlight or the App Store, signed with an Apple Developer Program distribution provisioning profile. The electron-builder Mac App Store guide identifies Mac App Distribution as the app signing certificate and Mac Installer Distribution as the uploaded package certificate. (high confidence) (verified as of 2026-10-22) [source]
- Apple’s Xcode launch simulation uses spctl -a -v and quarantined copies for Developer ID-signed apps. Mac Hardening’s September 2026 guide says Mac App Store apps report their own spctl source and that a rejected result predicts rejection if the app were quarantined. Do not treat a Developer ID notarization result as the expected Gatekeeper label for a TestFlight build. (medium confidence) (verified as of 2026-10-22) [source]
- In electron-builder issue 8382, the author reported that a Developer ID installer package passed notarization but failed Transporter checks, while a Mac App Store installer package passed Transporter but failed notarization. The author later reported resolving the case by enabling electron-builder’s notarization option and said they believed it notarized the app before packaging. This self-report illustrates separate validation outcomes; it does not establish that a TestFlight build needs Developer ID notarization. (medium confidence) [source]
Children
- No children recorded.