Continued Mac App Store Receipt Verification Woes

[Jeff_Tullin]

@Thomas_Roemert

do you want to give each customer a serial number to identify them?

yes.
I have done that for many years outside the Mac App Store, effectively.

for those who own a MBS licence, there are StoreKit classes
I do . This sounds promising

[Thomas_Roemert]

Apple wont give you any infos about the customers, but you can do the same as the „big players“: make an account on your website required to use the software….

[Ian_Kennedy]

I can’t see Apple allowing a small developer to sell an app that has no functionality, without a registration on your website. Unlocking additional functions, I can see.

[Sam_Rowlands]

@Ian_Kennedy

I can’t see Apple allowing a small developer to sell an app that has no functionality, without a registration on your website. Unlocking additional functions, I can see.

Most developers are prohibited from distributing an app that doesn’t do anything until it’s been registered. Big brand companies can do this because they’re more equal than indie developers. Bigger companies even have an App Store handler to help them through the process. The rest of us are just there to increase the numbers.

@Thomas_Roemert

And it looks like you have to bring your own Libcrypto - as Apple hides theirs and Xojo currently does not expose its internal dylib - if you use Thomas Tempelmanns / Sam Rowlands receipt validation. Juerg Otter has a Xojo project to build your own LibCrypto at Github, as Beatrix Willius mentioned above.

If Xojo could care enough to expose the functions in the included libCrypto, you wouldn’t need to add an additional copy to your application.

@Jeff_Tullin

I have been debating a Mac Store app, but they don’t allow user-generated serial numbering, do they?
Without App Store Receipt validation, does that mean people could just duplicate an app to another machine without buying?

Two things.

1. App Store receipt verification is required even for FREE apps, you can be rejected for not doing it properly.
2. Currently you are not allowed to use an external payment system or serial numbers. However that might be changing now that Apple’s anti-steering rules have been found in violation of California law.

Consider the App Store an alternative sales channel, the main advantage of having your application on the Mac App Store is for people who use the Mac App Store search to find apps.

You’ll need a marketing plan to get people to download your application, so that it can appear in a top 10 chart, where browsing customers may find it. You can also apply to Apple to promote your application, but personally I’ve never been “chosen”. In contrast, before the App Store, Ohanaware apps were often featured on the Apple “Downloads” site.

Many and I do many indie developers find the Mac App Store not worth the effort. Hence why it’s chock full of old outdated apps.

[Scott_Crick]

Unfortunately, half of this particular app’s revenue comes from the Mac App Store, so I still have to deal with it.

So, I’m trying the TestFlight thing, but I can’t get TestFlight to see the latest build of this app as anything other than “Not Available for Testing”. I have a suspicion I’m doing wrong with entitlements, but I haven’t quite figured out what.

I need to do this right, but I’m so tempted to just try getting it through review without really testing the receipt thing.

[Andrea_Suraci]

Any developments on this? I am currently stuck with the infamous “App is damaged and can’t be opened” alert. I tried moving the app to the Applications folder after signing it but it won’t launch. (Sonoma 14.1.2)

[Sam_Rowlands]

I don’t spend as much time here as I used to do so, but I can give you some hints.

• If you don’t use App Wrapper, you’ll need to make sure that the permissions in the Application are correct.
• IIRC receipt validation shouldn’t be tested with the App Store submission certificate. If you use App Wrapper, and scripts, it should sign the debug build with the correct certificate for testing receipt validation.
• Ensure that you’re using a test account and not a live account when testing you receipt validation code.
• Make sure you’re using the iOS way of validating receipts, and not the macOS way. The Mac way has been broken for testing for some time, while the iOS way was working last time I tried it.
• Double check your validation code, and walk through it, if there’s an error or something changed, then it’s not going to work.

I haven’t updated this code for a long time (and at this point I have no intention to do so as I’m migrating all my apps to a different language). You’re free to use this in your application. Please note that it requires a paradigm shift in how you handle receipt verification. I seem to recall I provided a design pattern in the demo app.

OWStoreKitBridge - Integrating the Mac App Store with Xojo

[Andrea_Suraci]

Thank you Sam, I appreciate that! I use AW and also have the MBS plugins. I will study your code and try to adapt it. From what I have understood so far from this thread and Apple’s byzantine documentation, there is no way to test a receipt in a debug build. The preferred way to test an app nowadays is to upload a development build and send TestFlight invitations or enable sandbox testers.