I did the all stuff above, and it wasn't enough. They still rejected it. Seems the links need to be in the binary, but the rejection blurb didn't indicate what form that should take. I'll try putting them on the About box, or maybe at the bottom of the Help menu. I'm guessing the whole point is that users can find the links and click on them. Anyone got any better suggestions?

Here's an example of Transaction.currentEntitlements returning an unverified result in development. I'm running my app in Xcode with a local storekit configuration file. I have no purchased products yet. I run the app in the debugger and Transaction.currentEntitlements returns this error attached to the unverified result: What am I supposed to do with this? I just found the following post, but I'm in development, on a mac, in Xcode. So why would I get this? https://developer.apple.com/forums/thread/695927

@Skylark In my experience it's impossible, particularly on the mac. Storekit (2) seems to be totally inconsistent and unreliable. We've been fighting with it ever since we started using it. In development, in testing, and in production. The documentation is a joke, Apple engineers don't respond to forum posts, and if you request DTS they just refer you to the forums or ask you to post a bug report. I've done all of this, and am no better off. Maybe no-one actually knows how it's supposed to work. It reminds me of the early days trying to include iCloud technology in code. According to Apple at the time it "just works", and it really really just didn't. Looking at Apple's training videos for StoreKit everything is wonderful and shiny, but my experience is the total opposite. Their examples never include any processing of failure cases, and the documentation doesn't attempt to explain what those failure cases might be, what could cause them, or how to respond. Of course, in production they happen regularly. You can't properly test these cases in development, so you are left guessing. As an engineer I want to see rigorous documentation of failure cases, so I can write robust code to cope with them. Here's a good example: Transaction.currentEntitlements can return unverified. Why? Under what conditions? What does it actually mean? And how do we respond in code? I can find no answers to this on the forums or in Apple documentation. Just frustrated devs flailing around. Do I sound bitter? :) Sorry. Yours, exasperated and disillusioned.

Same think happening today to me.. Nobody at Apple seems to answer any StoreKit questions. I've recently tried via DTS as well. They just closed the case with no answers.

I'm in the same boat. Some guidance from Apple would be appreciated.

Here's the StoreKitError declaration:

I've managed to get AppTransaction.shared to throw during testing, but it throws an Error rather than a usefully typed error, and the documentation doesn't tell you what the type is. Examining the metatype by reflecting, shows that it IS a StoreKitError, so I put an explicit catch statement in: catch let storeKitError as StoreKit.StoreKitError { ... } catch { ... } Then I paused the debugger in the first catch. Here's what I see. Ideally I'd like to capture the debugger's internal output (the top two messages that appear) so I could get users to grab it if it happens in the live app. I can't find a way to access it though. Anyone know? I printed out the available concrete StoreKitError vars. I'm struggling not to be sarcastic when reading them... ;)

@lzell2 I haven't forgotten about this. I'll post something when I have a proper maintenance release ready to submit to the MAS. See my latest post at the end of this thread: https://developer.apple.com/forums/thread/780767 and also the post just before it from @weichsel who is having the same problem.

@weichsel Thanks for your input and sorry to hear you are suffering in the same way. Actually it's quite a relief to hear others are having similar problems. Agree totally about the issue being "mac bound" as the vast majority of our users seem (thankfully) unaffected. I'm busy building a maintenance release that has every bell and whistle covered regarding success and failure of AppTransaction.shared and AppTransaction.refresh(). At least then I can detect edge cases and examine what's happening. Unfortunately I'll have to ask our users to relay this info via support comms if there's no obvious way to recover in code. I'll post some more info when it's done. You might want to look at this post too: https://developer.apple.com/forums/thread/773604

@lzell2 @Tlaloc @endecotp I don't know if you are still interested, but I found a way to force the unverified case to occur when calling AppTransaction.shared Maybe you all already know how to do this, so I won't waste time posting it if no-one is interested. It does mean I can test AppTransaction.shared and AppTransaction.refresh() more repeatably and thoroughly. At least, you can test the branches of your code without artificially creating conditions in the code.

Can I just clarify my understanding of what the documentation "appears" to be saying about this unverified branch. Anyone here care to pitch in with what they think it's supposed to be doing, again according to the examples in the documentation. I use that word advisedly. All of the forced StoreKit simulated errors result in AppTransaction throwing, so I don't know how to test this. I've outlined this in my post here: https://developer.apple.com/forums/thread/780767 Here's the documentation on refresh(), which isn't much clearer. This indicates that the unverified branch IS something to treat as an issue, to be addressed by calling refresh()

OK I think I see an interpretation problem I've been wrestling with. It's the word "purchased" used throughout the documentation regarding AppTransaction. My app is free with in-app purchases (subscriptions), so the first time the user downloads my app, it has been "purchased" for zero dollars. Hence the verified branch should still be executed, and the values for appTransaction.originalAppVersion and appTransaction.appVersion will both reflect the newly downloaded version. Anyone agree or disagree? Can't test it, as it's always 1 in the Sandbox, but the documentation is clearer here, and refers to "first purchased or downloaded":

I've just had a response from my Feedback Assistant request. FWIW I submitted a DTS request on the 16th of April. It's now the 23rd and all I've received is an automated acknowledgement of the submission.

From the StoreKit configuration file: These seem like generic errors to me, not particularly relevant to AppTransaction. I can't find any documentation on them, or their applicability. Here's what I found empirically. Importantly, ALL of them throw. Nothing returns a result, unverified or otherwise. What are we to make of this (ignoring the inconsistency in the error number for Network Error)? It's not possible to deduce much from the error strings, so do we force users to refresh() their store status for any of these error conditions?

I'm spending some serious time with AppTransaction in an attempt to empirically discover how it behaves so I can release a workaround. Some of the failures return the helpful string "The operation couldn't be completed", and an ASDErrorDomain number. I can find no documentation on ASDErrorDomain whatsoever.