# TestFlight designated requirement and Gatekeeper launch of a store-signed Mac build > Source-anchored research for TestFlight designated requirement and Gatekeeper launch of a store-signed Mac build. Run status: COMPLETED. Parent: [Apple Platform Publishing (Mac App Store)](https://llms-explorer.com/tree/apple-platform-publishing-mac-app-store/) · 4 facets · 12 facts · page: https://llms-explorer.com/tree/testflight-designated-requirement-and-gatekeeper-launch-of-a-store-signed-mac-build/ ## How it works - Apple TN3127 documents codesign --display -r - 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](https://developer.apple.com/documentation/technotes/tn3127-inside-code-signing-requirements) - 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](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution) ## 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](https://developer.apple.com/documentation/technotes/tn3161-inside-code-signing-certificates?changes=__8) ## 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- ` 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](https://developer.apple.com/documentation/technotes/tn3127-inside-code-signing-requirements) - 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](https://developer.apple.com/documentation/technotes/tn3127-inside-code-signing-requirements) ## 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](https://help.apple.com/xcode/mac/current/en.lproj/dev31de635e5.html) - 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](https://pyoxidizer.readthedocs.io/_/downloads/en/apple-codesign-0.15.0/pdf/) - 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](https://developer.apple.com/forums/thread/706379) - 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](https://github.com/electron-userland/electron-builder/issues/8382) - 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](https://help.apple.com/xcode/mac/current/en.lproj/dev31de635e5.html) - 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](https://help.apple.com/xcode/mac/current/en.lproj/dev1cc22a95c.html) - 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](https://github.com/electron-userland/electron-builder/issues/8382)