Anti-Piracy measures for Mac App Store apps?

As an indy developer, it's prohibitive to start developing backend receipt validation services. Is there anything else in Apple's technologies that we can use to verify whether the person who is using my app, has paid for it?

The first thing I thought of when Apple rolled out Sign in with Apple ID, was hopefully, it would include some API that would allow me to ask a simply question: did this Apple ID pay for my app? As an indy developer, this is the one feature that would keep my paid app on the Mac App Store.

Anyone have any good suggestions for solving this as an indy developer?

Replies

As an indy developer, it's prohibitive to start developing backend receipt validation services.

Why do you say that? Do you think it will take too long to learn the required technologies? Or maybe you think the cost of server infrastructure will be unaffordable? Why specifically does it matter that you are an “indy developer”?

You do have DeviceCheck on Mac (though not App Attest, IIRC). I wouldn’t say it is easier to use than receipt validation.

Beware of the danger of false positives. If someone pays for your app and then for some reason your code decides they’re a pirate, they will write a 0-star review and your sales will fall. How many blocked pirates are worth one bad review? Bad reviews can be catastrophic, and generally pirates would not have paid for your app anyway.

@endecotp

Why do you say that? Do you think it will take too long to learn the required technologies? Or maybe you think the cost of server infrastructure will be unaffordable? Why specifically does it matter that you are an “indy developer”?

If you want to do business in Europe and the UK, and you want a backend service that stores information about your customers, then you are legally obligated to comply with the GDPR, unless you are comfortable with getting sued into your next lifetime. That's not a one man job, hence why I'm asking as an indy developer.

If someone pays for your app and then for some reason your code decides they’re a pirate, they will write a 0-star review and your sales will fall. How many blocked pirates are worth one bad review?

You're making disparaging assumptions about my abilities in a way that almost seems like borderline gas-lighting. The idea that I should simply tolerate pirates to ensure the app's reputation on the store is just bizarre to me. It is worthwhile blocking every single pirate in my view. If the software is good quality and people who value it and have paid for it, review it positively then I don't see how that will get drowned out by hypothetical bugs you feel I'll introduce.

and generally pirates would not have paid for your app anyway.

Tired of hearing this fallacy. That's like saying the only people who will buy your app are the ones who paid for it. If a pirate is not interested in my app, then why would they download it off a pirate site? Because it's available for free. The idea that people who are willing to pay for your software, won't download it for free, given half the chance, is naive.

If you want to do business in Europe and the UK, and you want a backend service that stores information about your customers, then you are legally obligated to comply with the GDPR

Not quite; it’s only an issue if it’s personal information that you store. App receipts do not include personally-identifying information. You can do that without any great concerns.

Even working by yourself, you do have the option of getting legal advice. Or maybe taking a course.

You're making disparaging assumptions about my abilities

I’m sorry that it sounded like that but I had guessed that you were avoiding doing receipt validation because it seemed too complex, rather than due to your legal concerns.

The idea that I should simply tolerate pirates to ensure the app's reputation on the store is just bizarre to me.

Everything that I wrote is based on my own, recent, experience (though with iOS apps, rather than Mac apps, which does make a difference). This is a judgement you have to make based on your own priorities.

The idea that people who are willing to pay for your software, won't download it for free, given half the chance, is naive.

The type of app you choose to work on is a factor. I recall a great Dilbert where he has a chart that says poor/rich on one axis and stupid/intelligent on the other. He’s pointing at the chart saying “we’ll be targeting this market segment”. If your app mainly appeals to smart kids with not much cash, you’ll get a higher piracy rate than if you take Dilbert’s approach.

Not quite; it’s only an issue if it’s personal information that you store.

Not quite; it's personally identifiable information that you request from the user, and they provide to you in response. It doesn't include unsolicited data such as if someone emails you their personal details without you asking for that information. I've read the +30k word document on the UK Governments guidance on GDPR. It's not a small task, but we're getting off topic, I suppose.

App receipts do not include personally-identifying information.

True, however, if you've ever read the tech news in the last decade you'll know that companies that used to publish anonymised data for research purposes have stopped doing it, because it was quite quickly discovered that even anonymised data can be cross-referenced with other data (anonymised, or otherwise) to eventually render that data no longer anonymous. Suggesting getting lawyer involved is missing the context of my original post.

But still, you need to be extremely careful with how you handle other people's financial data. I've worked as a backend engineer for over a decade in commercial banking, investment banking, publishing, startups etc. I'm well aware of the team of people required to engineer and maintain a backend solution. If you think it's a one-person job, you are already way out of your depth.

The whole point of my post is to get feedback from Apple regarding a simpler mechanism of receipt validation for those who can't afford to setup and maintain a backend receipt validation service, in the hopes of reducing app piracy and given indy developers more of chance of financial success. Bug accusations aside, I'd be happy to hear your thoughts and criticisms on this mechanism, and why, perhaps it hasn't been implemented up until now.

Also, I couldn't get AutoPairs to work on Sonoma. No matter how many times I granted it permission in Accessibility Settings, the user interface never reflected that permission, even after restarting the app. And it never did auto-complete my text.

If you think it's a one-person job, you are already way out of your depth.

I’m a one-person business, and I’ve done all this - app receipt validation, DeviceCheck, App Attest, etc. You could do it if you wanted. I would still caution that you need to balance the costs, including the costs of false positives, against the benefits.

The whole point of my post is to get feedback from Apple

Feedback from Apple is quite rare on this forum. More likely, you’ll just have to listen to other developers sharing their experience.

@endecotp

Feedback from Apple is quite rare on this forum. More likely, you’ll just have to listen to other developers sharing their experience.

*giggle snorts* @ Eskimo

I think Eskimo's work rate speaks for itself.

Yeah, but I try to stay focused on technical issues. This thread sits at the intersection of policy (which I try to avoid commenting on) and DRM (which DTS doesn’t support; I talk about that here).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

  • No worries. I was just pointing out that feedback from Apple on here isn't quite rare.

Add a Comment