A code snippet for detecting the TestFlight environment for a macOS app at runtime

Bundle+TestFlight.swift

/// MIT License
///
/// Copyright (c) 2021 Lukas Kubanek, Structured Path GmbH
///
/// Permission is hereby granted, free of charge, to any person obtaining a copy
/// of this software and associated documentation files (the "Software"), to deal
/// in the Software without restriction, including without limitation the rights
/// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
/// copies of the Software, and to permit persons to whom the Software is
/// furnished to do so, subject to the following conditions:
///
/// The above copyright notice and this permission notice shall be included in all
/// copies or substantial portions of the Software.
///
/// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
/// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
/// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
/// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
/// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
/// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
/// SOFTWARE.

import Foundation
import Security

extension Bundle {
    
    /// Returns whether the bundle was signed for TestFlight beta distribution by checking
    /// the existence of a specific extension (marker OID) on the code signing certificate.
    ///
    /// This routine is inspired by the source code from ProcInfo, the underlying library
    /// of the WhatsYourSign code signature checking tool developed by Objective-See. Initially,
    /// it checked the common name but was changed to an extension check to make it more
    /// future-proof.
    ///
    /// For more information, see the following references:
    /// - https://github.com/objective-see/ProcInfo/blob/master/procInfo/Signing.m#L184-L247
    /// - https://gist.github.com/lukaskubanek/cbfcab29c0c93e0e9e0a16ab09586996#gistcomment-3993808
    internal var isTestFlight: Bool {
        var status = noErr

        var code: SecStaticCode?
        status = SecStaticCodeCreateWithPath(bundleURL as CFURL, [], &code)

        guard status == noErr, let code = code else { return false }

        var requirement: SecRequirement?
        status = SecRequirementCreateWithString(
            "anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.25.1]" as CFString,
            [], // default
            &requirement
        )

        guard status == noErr, let requirement = requirement else { return false }

        status = SecStaticCodeCheckValidity(
            code,
            [], // default
            requirement
        )

        return status == errSecSuccess
    }
    
}

FWIW, you can avoid relying on the common name of the cert by checking for the marker OID that Apple adds, i.e.

anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.25.1]

This just tests for the existence of the certificate extension, which doesn't seem to have a name (yet), but is pretty clearly the marker for the TestFlight distribution signing certificate. (There a different OID that marks the production App Store signing cert, and another for Developer ID, and so on.) As long as it's an Apple-issued cert (which is checked by "apple anchor generic"), the presence of that extension should have Apple's meaning.

In fact, you should find this same construct used as the designed requirement of an app delivered via TestFlight and signed with that certificate.

@rsaldinger That’s a very interesting hint! I found this custom extension listed in Apple’s Certification Practice Statement Worldwide Developer Relations PDF, and it’s, in fact, present in the certificate used for signing the TestFlight builds.

Since I don’t have much experience with cryptography and how Apple is handling its certificates I was wondering how safe it is that Apple will keep that custom extension. Isn’t it possible for Apple to make changes there just like they could rename the certificate?

It's possible but unlikely, since the purpose of these NULL-valued custom extensions (sometimes called "marker OIDs") is precisely to identify a certificate issued by Apple for a specific usage, without relying on the Common Name.

You'll see such marker OIDs (if not this specific TestFlight one) used in designated requirements (use "codesign -d -r - X.app") all over. And also in the open-source Security framework, especially in the construction of trust policies in SecPolicy.c. Some of them are given meaningful names (which are then visible in the standard certificate/trust sheets, if you scroll down through the Details section), but they've been pretty inconsistent with that over the years.

@rsaldinger Thanks for these very helpful insights! Especially the codesign -d -r X.app command is pretty useful.

I now went ahead and switched the check from the common name to the custom extension. It’s now reflected in the gist as well. Based on my testing, it seems to work just fine.

I've been looking for something like this for months. Albeit it's ridiculous that Apple doesn't provide a simple API function for something so basic, it'd take them literally 1 minute to implement.

Thank you very much!

Thank you very much for your time figuring this out! It just saved my day 😊

Thank you so much. I googled for how to do exactly this - check whether macOS app is running in TestFlight or live environment. Landed here. Works as expected.

Is the above code for macOS, or both macOS and iOS? Currently I do this. Could I also use this certificate-based method for iOS? Feels like it would even be more robust than relying on the receipt file name?

private static var isTestFlight: Bool {
    #if os(iOS)
    Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt"
    #else
    Bundle.main.isTestFlight
    #endif
  }

@jaanus: I’m glad this snipped helped you. To be honest, I haven’t checked whether the certificate-based method works on iOS as I currently don’t have any iOS app on TestFlight. If you happen to have one (I guess you’re using it for Tact, right?), you can test it for yourself and report back in this thread. Best luck with your project!

Yep, that’s the project where I use it. I’ll some time try it out with iOS on TestFlight and report back.

Verdict about iOS: cannot use the signature check, because the needed Security framework API-s are available only on macOS and not on iOS.

So as far as I know, the best way to do this across macOS and iOS is what I shared above. On macOS, do the signature check from the original post. On iOS, check the receipt file name.

@jaanus: Thanks for sharing your findings!

Months later, I wanted to add that I've been using this trick on my public macOS beta for a while, to restrict in-app features. It has worked like a charm since.

@lukaskubanek Thanks for figuring this out. Very handy to have while publicly testing new features!

I feel like sharing what I ended up doing, as it might help other readers:

https://github.com/passepartoutvpn/passepartout-apple/blob/master/PassepartoutLibrary/Sources/PassepartoutCore/Reusable/SandboxChecker.swift

Beyond being a multiplatform check, I made this observable because Xcode has been complaining about SecStaticCodeCheckValidity for a while, as it is a potentially slow call.

Also notice that the Mac condition appears first, because #if os(iOS) is also met on Catalyst and would take over.

@keeshux Thanks, but it's a shame it's GPL as I don't particularly want to open source my whole application just to check if I'm running on Testflight or not. I think for most people the one in this thread is a safer bet.