I need the supported way to obtain an Apple-signed AppTransaction for a development-installed iOS app without initiating an in-app purchase. DTS directed me to ask on the forums.
Environment at the time of reproduction
- Physical iPhone 17e, iOS 27.0 (24A437).
- Xcode 27.0 (27A266a), macOS 27.0 (26A428).
- Swift / SwiftUI / StoreKit; version 0.1.0, build 1.
- Explicit bundle identifier registered with App Store Connect; development signing. The executable signature, embedded profile and installed executable hash were checked.
- Installed and launched using devicectl. Network access allowed.
- No StoreKit Configuration file or StoreKitTest session.
- No IAP products or TestFlight builds. App Store Connect version 1.0: Prepare for Submission.
Observed behavior
- Call
try await AppTransaction.sharedonce. It throws; no verified transaction is returned. - From a separate visible button, the user explicitly calls
try await AppTransaction.refresh()once. - No Apple Account authentication prompt appears. The refresh fails immediately.
The refresh error is identified by Swift pattern matching as StoreKitError.systemError:
Outer NSError: StoreKit.StoreKitError, code 1
Underlying NSError: SKInternalErrorDomain, code 14
The refresh was recorded at 2026-09-20T15:40:12Z. The original shared probe recorded only the outer error, so I am not claiming its underlying error was identical. I could not find a public definition of the internal error; I am not interpreting it as SKErrorDomain code 14.
A Sandbox Test Account was subsequently created, but has not been signed in on the device. The user could not find the Sandbox Apple Account entry. No purchase has been attempted to make that entry appear. The later controlled refresh is described below. The device App Store account differs from the developer account; we have not established this as a cause.
Controlled follow-up on 2026-09-22
A separate instrumented copy of RefreshProbe was development-signed, installed and launched with devicectl on the same phone. The user explicitly tapped refresh once at 2026-09-22T14:35:39Z. It again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The runtime executable SHA-256 matched the locally validated signed binary. No verified AppTransaction was returned.
Bounded traversal of the typed underlying error, NSUnderlyingErrorKey and multiple underlying errors exposed only those two domain/code nodes and no allowlisted numeric service status. We did not collect arbitrary userInfo, accounts or signed transactions. App stdout confirmed the result; no storekitd/appstored system log or Xcode IDE launch comparison is claimed. The user confirmed that this attempt also showed no Apple Account login or password prompt.
This instrumented copy is separate from the original source ZIP described below. No automatic retry or purchase was performed.
VPN-disabled follow-up on 2026-09-22
After the earlier controlled attempt, the user reported using a VPN. For a second controlled attempt the user confirmed that the VPN was disabled and the normal Apple Account remained unchanged. At 2026-09-22T14:48:25Z, one explicit button tap again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The bounded error tree was identical to the preceding attempt. The user confirmed that no login or password prompt appeared. No verified AppTransaction was returned.
The runtime executable hash matched this signed build. The StoreKit call and diagnostic logic were unchanged; only the run identifier and UI label changed to preserve earlier records, followed by installation/relaunch. VPN and account conditions are user observations, not captured network routing. Disabling the VPN did not resolve this attempt; this is not proof that all network causes are excluded. There were no automatic retries or purchases.
Questions
- Is an Apple-signed sandbox AppTransaction supported in this development-install scenario without an IAP product or purchase attempt? What registration and authentication prerequisites apply?
- What supported diagnostics or corrective steps should we use when refresh fails before presenting authentication?
- Is there a supported sandbox authentication path for this case without initiating a purchase or signing out of the normal Apple Account?
- If logs are needed, which narrowly scoped StoreKit logs should we collect?
Focused sample
A small project with two targets (192 Swift source lines, no dependencies) is ready to provide. The source entry points match the probes used for the observations above. Both packaged targets passed unsigned generic iOS builds, but the newly assembled focused package has NOT itself been re-signed and run on a device. It performs no purchase or photo-library access and does not include credentials, provisioning profiles, device identifiers or signed transactions.
I can provide the package to DTS in the existing email request with a link to this forum post. I have not uploaded the package publicly.