That explains and is consistent with the originalAppVersion definition: https://developer.apple.com/documentation/storekit/apptransaction/originalappversion originalAppVersion represents the CFBundleVersion (build number) on iOS, or CFBundleShortVersionString (marketing version) on macOS, for the original purchase; so unless build number is properly maintained (e.g., incremented if maintained as a number, or set to marketing version if maintained as a string), it won't be unique to identify past purchases on iOS (and for me almost all build numbers were 1).

originalAppVersion is always 1.0 in sandbox: https://developer.apple.com/documentation/storekit/apptransaction/originalappversion

I always get "1" in my case (not "1.0.0"), even though the version at the time of purchase was "0.9.5". I should clarify that prior to version 1.0.0, app was paid (so users had to pay for that 0.9.5), but starting with 1.0.0 app became free with in-app purchase. The returned originalPurchaseDate is accurate however. I get the same original version (wrong) and original purchase date (correct) from app receipt too. I'm wondering if (1) AppTransaction (or app receipt) understands versions smaller than "1.0.0" (or assumes "1" for everything smaller), and if it does, (2) transition to IAP at version 1.0.0 has anything to do with this problem (e.g., app becoming "free" resetting the original app version). do { let result = try await AppTransaction.shared switch result { case .verified(let appTransaction): originalAppVersion = appTransaction.originalAppVersion originalPurchaseDate = appTransaction.originalPurchaseDate case .unverified(let appTransaction, let error): // verification failed ... } catch { // error ... }

After a few attempts I learned the reason in my case was missing EULA in the app binary and the app description in the App Store. See the review notes below (which specifies both are required), The painful part was that all IAP subscription definitions become useless if the binary is rejected (when introducing IAP subscriptions for the first time); I had to recode all of them. Design your code and subscription product identifiers in a way that changing identifiers wouldn't need a binary update. Review notes in my case (relevant pieces), Update the app's binary to include the following required information: A functional link to the Terms of Use (EULA) A functional link to the privacy policy Update the app's metadata to include the following required information [metadata in my case meant app description on the App Store]: A functional link to the Terms of Use (EULA). If you are using the standard Apple Terms of Use (EULA), include a link to the Terms of Use in the App Description. If you are using a custom EULA, add it in App Store Connect.

Can someone help? Subscription stuck in "Missing Metadata" state with nothing visible to fix.

I double checked the plans rank/order (Starter = 3, Plus = 2, Pro = 1), re-ran the experiment, and got the same result. I check currentEntitlements both right after the purchase and in the transactions listener; readings consistent and as reported.

It looks like renewal state does change to .expired after some time; I'm not sure when or if it is load dependent (I checked one hour after expected expiration time (e.g., 3 * 3 * 12 = 108 minutes for a quarterly subscription on an accelerated time basis of 1 month = 3 minutes, and 12 renewals). Maybe this shows possible delays need to be handled.

Issue seems to have been related to the outage; error is not showing up anymore.

[I realized my problem is with StoreKit / iOS testing but error is the same; will put this into an iOS-specific post too]. I'm getting this (I think) the same error starting today (on iOS 18.1 beta 5/6/7 at least) while trying StoreKit sandbox testing. Outside code/app, I can't even login to the test account in settings->AppStore->Sandbox Account (goes through email/phone confirmation and then silently fails). Tried a different password for a new sandbox test account with no success...Anyone else experiencing this? Status page (https://developer.apple.com/system-status/) shows some related outage from two days ago, but no current problem. Error: Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=530 "(null)" UserInfo={NSUnderlyingError=0x3009ca040 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed The authentication failed." UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=AMSErrorDomain Code=2 "Password reuse not available for account The account state does not support password reuse." UserInfo={NSDebugDescription=Password reuse not available for account The account state does not support password reuse., AMSDescription=Password reuse not available for account, AMSFailureReason=The account state does not support password reuse.}", "Error Domain=AMSErrorDomain Code=306 "Reached max retry count Task reached max retry count (3 / 3);" UserInfo={AMSDescription=Reached max retry count, AMSURL=..., NSDebugDescription=Reached max retry count Task reached max retry count (3 / 3);, AMSFailureReason=Task reached max retry count (3 / 3);, AMSStatusCode=200}" ), AMSDescription=Authentication Failed, NSDebugDescription=Authentication Failed The authentication failed., AMSFailureReason=The authentication failed.}}, storefront-country-code=USA, client-environment-type=Sandbox}

Any development in 2024? renewalInfo.willAutoRenew does not seem to get cleared (after 2-3 hours (with accelerated timing in sandbox) ; is that long enough?). I really hope to see expected values in sandbox before launch. The only hint I could find so far is that the expirationDate in the latestTransaction for the product identified by renewalInfo.currentProductID is in the past (but renewal state remains .subscribed, willAutoRenew remains true, etc.). If this issue cannot be fixed, is checking the latest transaction expiration date a valid approach? Should I look at this date check as a hack for sandbox, or is it necessary outside the sandbox too?