How to confirm registration of App Store purchases

I was asking about DRM last Spring about App Store submissions. There was a comment I didn’t follow up on at the time … that unless I add code, purchases from the Mac App Store can shared with other machines and Apple will happily let them run. And there was a link that referenced an article about having to use VerifyReceipt. But the article is for a language other than Xojo and I don’t understand what it’s saying. And there’s also a warning that VerifyReceipt is deprecated.

I didn’t find anything in the documentation on this topic; but, maybe I don’t know exactly what to look for. Where can I find an example of what needs to be included in the Xojo app so that it plays nicely with the App Store?

Do you use our MBS Xojo Plugins? We have the AppReceiptVerificatorMBS class.

And also AppReceiptIAPMBS class for in-app purchases.

But maybe for new developments, check the StoreKit2MBS module instead.

There you can query current entitlements.

I have used your plugins, but not the right ones for this. I used the plugin that compiles and runs AppleScript (more than ten years ago)

I was looking at the link and the StoreKit2. It looks like overkill to me. It looks like it’s got a lot about in-app purchases and a ton of stuff I don’t have any use for. Isn’t there a simple way to verify that an app’s been purchased or not?

Apple decided “no”

3 Likes

Does this mean if I want the Swift module so I can validate items submitted to the App Store, the only way is to get the plug that has all of the modules?

Are you all saying that everyone who’s building apps for the App Store is getting this plugin?

At one point in the past I know Christian offered licenses for individual parts, but that’s a conversation to have with him.

Some people are. Some aren’t. Some people don’t bother distributing via the Mac App Store. (I honestly can’t think of any forum users to ping who are in the MAS, sorry.)

Here’s an interesting take I found today.

It aligns with my views in that you should balance DRM with the value it provides. You don’t want to inconvenience legitimate users and spending time on DRM takes away from your other work. This extract for example:

It’s much more worth­while to put a unit of effort into winning new customers rather than chasing down bad actors.

Of course, my motivations for “DRM should be easy to implement” are that I offer an extremely easy to use DRM. But would you rather spend my time or yours? :wink:

2 Likes

Tim,

thanks for the link.
I have a simple DRM that I built maybe 15-20 years ago that I can use for direct sales without little hassle. But it doesn’t do anything to prevent users who have bought the app from the App Store from sharing it. It’s not as comprehensive as what you’re describing, but I think it’ll be sufficient for the limited distribution I expect from direct sales. And unless I’m misunderstanding the website, it doesn’t look like it does anything to control the scenario I described. That sounds like something I need Christian’s AppReceiptVerificationMBS for — if it turns out I get enough interest in the product to make it worthwhile.

Chuck