AppTransaction.shared throws StoreKitError code=2 in macOS TestFlight while deviceVerificationID is available

Question

Created 3w

Replies 2

Boosts 0

Participants 2

I am implementing device authentication for a macOS app. Our iOS app uses App Attest, but App Attest is not available on macOS, so we are evaluating StoreKit's AppTransaction plus AppStore.deviceVerificationID as the macOS equivalent signal.

The issue: in a macOS app installed through TestFlight, AppStore.deviceVerificationID is available, but AppTransaction.shared throws StoreKitError code=2.

I reproduced this in a focused standalone macOS test app with no backend and no custom dependencies.

Environment:

Platform: macOS
Distribution: TestFlight
App Store Connect app ID: 6769568350
Bundle ID: com.soundcity.AppTransactionProbe
App version: 1.0
Build: 1

Observed output from the TestFlight-installed app:


Bundle ID: com.soundcity.AppTransactionProbe

App version: 1.0

Build: 1

deviceVerificationID available: true

deviceVerificationID prefix: CA91ED5D...

AppTransaction.shared threw

error: StoreKitError; domain=StoreKit.StoreKitError; code=2

The relevant code path is essentially:


import StoreKit


let deviceVerificationID = try? AppStore.deviceVerificationID

let appTransaction = try await AppTransaction.shared

In the TestFlight-installed build:

AppStore.deviceVerificationID succeeds.
AppTransaction.shared throws StoreKitError code=2.

Questions:

Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight?
If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing?
If no, is there an Apple-supported way to obtain an AppTransaction JWS, or equivalent signed App Store/TestFlight app-install assertion, for macOS TestFlight builds?
For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together?

I have a focused Xcode test project that demonstrates the issue and can share it if helpful.

Answer 1

DTS Engineer OP

Apple

2w

Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight?

Yes.

If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing?

It represents networkError(URLError), which indicates that a network error occurred. You can find it by handling the error in your code

do {
        let result = try await AppTransaction.shared
        .......
} catch let error as StoreKitError {
   print(error.localizedDescription)
}

For more information, see Handling errors and Error Handling.

For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together?

AppStore.deviceVerificationID is used for transaction verification. For more information, see deviceVerificationID.

Answer 2

willfriedman OP

10h

Thanks. I uploaded and installed a fresh macOS TestFlight build of the focused probe project:

https://github.com/wfried/apptransaction-probe

The updated probe explicitly handles StoreKitError.networkError(URLError), but in the TestFlight-installed build the thrown error is not networkError. It is StoreKitError.unknown:

Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 2

deviceVerificationID available: true deviceVerificationID prefix: CA91ED5D...

AppTransaction.shared threw error type: StoreKitError error localizedDescription: Unable to Complete Request error StoreKitError: unknown error StoreKitError case: unknown error NSError domain: StoreKit.StoreKitError error NSError code: 2

So there does not appear to be an underlying URLError available from the public StoreKitError value.

Can you clarify what setup is required for AppTransaction.shared to return a verified AppTransaction in a macOS TestFlight build? The App Store Connect app exists, the build was installed through TestFlight, and AppStore.deviceVerificationID is available in the same process.