Safer check of .appStore vs .testFlight build, and enables TESTFLIGHT deployment

[johnqh]

@mike-dydx This is what I meant as we discussed.

It would require a TESTFLIGHT deployment in the env.json, which should contain deployer's mainnet and our testnet environments.

[mike-dydx]

what is the value/benefit of TESTFLIGHT ?

I am assuming the TESTFLIGHT deployment contains mainnet and testnet environments

If app store review build results in testFlight (we are not certain), then they will see those as the default selectable environments. App review might say "you cannot expose beta/test environments to users" and reject. I think apple might like to see that test environment access is behind special submission instructions.

[johnqh]

TESTFLIGHT deployment would have both mainnet and testnet, and default to mainnet, so unless reviewer enables debug and then switch to testnet environment, he is on mainnet.

It should be something like:

"TESTFLIGHT": {
         "environments": [
            "dydxprotocol-mainnet"
            "dydxprotocol-testnet"
         ],
         "default": "dydxprotocol-mainnet"
      },

[mike-dydx]

Ah, right. I am forgetting that the menu is hidden unless the Debug flag is enabled via QR code. I will get this updated in v4-web as well.

[johnqh]

I am doing a PR on v4-web for this

[mike-dydx]

i think my PR has the same logical outcomes, but without using the checkResourceIsReachableAndReturnError API (which is a synchronous round trip)

This method synchronously checks if the file at the provided URL is reachable. Checking reachability is appropriate when making decisions that do not require other immediate operations on the resource, such as periodic maintenance of user interface state that depends on the existence of a specific document. For example, you might remove an item from a download list if the user deletes the file.

[johnqh]

The only different is with app reviewer.

We don't know what receipt file URL they have. If it is "sandboxReceipt", with previous logic, they will end up in.appStore. But if we check if it is reachable (essentially check if the receipt file is present), then reviewer will end up in .testFlight.

[mike-dydx]

from my PR
if Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt" is true, then outcome is .testfFlight✅

if Bundle.main.appStoreReceiptURL?.lastPathComponent != "sandboxReceipt" is true, then outcome is .appStore unless jailbroken or isDebug is true✅

if Bundle.main.appStoreReceiptURL?.lastPathComponent == nil is true, then outcome is .appStore unless jailbroken or isDebug is true. To be safe in the case that app review does not have an appStoreReceiptURL, this outcome should be .testFlight so this is incorrect ❌

so my PR has a potential issue depending on app review binary

---

for your PR
if Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt" is true, then outcome is .appStore if checkResourceIsReachableAndReturnError is true (i think this might be incorrectly true? since the appStoreReceiptURL might still be reachable with checkResourceIsReachableAndReturnError) ❌

if Bundle.main.appStoreReceiptURL?.lastPathComponent != "sandboxReceipt" is true, then outcome is .appStore if checkResourceIsReachableAndReturnError is true ✅

if Bundle.main.appStoreReceiptURL?.lastPathComponent == nil is true, then outcome is .testFlight if checkResourceIsReachableAndReturnError is true ✅

so your PR has a potential issue depending on app review binary as well. This is only if the sandbox receipt url is reachable

---

I think we might need to combine both of ours to be 100% safe?

    public static var source: Source {
        if isJailBroken {
            return .jailBroken
        } else if isDebug {
            return .debug
        } else if isTestFlight {
            //reached if `Bundle.main.appStoreReceiptURL?.lastPathComponent == "sandboxReceipt"`
            return .testFlight
        } else if isAppStore {
            //reached if `Bundle.main.appStoreReceiptURL?.lastPathComponent != "sandboxReceipt"`
            return .appStore
        } else {
            //reached if `Bundle.main.appStoreReceiptURL?.lastPathComponent == nil`
            return .testFlight 
        }
    }

[mike-dydx]

additionally, I cannot think of a scenario where Bundle.main.appStoreReceiptURL != nil && checkResourceIsReachableAndReturnError == false

so maybe we can remove the synchronous checkResourceIsReachableAndReturnError to reduce app start-up time?

[johnqh]

The difference is checkResourceIsReachableAndReturnError, which is true if the receipt file exists. This is battle tested, in our v3 (and many apps before I used it in dYdX)
"sandboxReceipt" is undocumented and can change anytime.

[johnqh]

@mike-dydx Like I said in Huddle, I think using "sandboxReceipt" should work. Worst case is that if Apple changes the receipt name (or Apple review has a different receipt name), the TestFlight/Reviewer app behaves like App Store download. If that happens, we can deal with it later. I reverted my changes back to use "sandboxReceipt" check