My app uses in-app purchase, and I verify the transaction receipts with Apple. This has shown me that many users are trying to pirate the in-app purchase mechanism by submitting fake transaction receipts, which come up with a product ID of com.zeptolab.ctrbonus.superpower1 (from "Cut the Rope"). Of course I don't let them use the in-app purchase items with a fake receipt. What are some strategies for battling iOS piracy and trying to get these people either to pay or to suffer?
The only way to truly prevent this is to control everything through your own server(s). Even the infamous "com.zeptolab.ctrbonus.superpower1" receipt is an actual valid receipt that Apple's own validation endpoint will tell you is OK. Once a transaction is completed, the app should send the transaction data to a server you control and:
Validate the receipt with Apple from your own server.
If Apple says it's OK, parse the product_id field from Apple's response and make sure it's a product ID from your app.
If the first two items pass, return data to tell your app where to download your content (if it's hosted content).
Even this has a flaw, especially if your IAP content is simply on the device but "locked". There are ways to redirect the validation call from your server to make your app think your server said "everything is OK!". This is much more difficult if your IAP content is hosted remotely as they can't as easily spoof the response with the location of the content if they don't know where the content is in the first place.
The problem in all of this for most people is that controlling your own servers and remote content can get costly, not to mention the need to write your own validation logic. The more difficult you make it for these hacks to be successful, the more it can cost you, so you have to weigh just how much you want to make them "suffer" with how much time, effort and money you're willing to spend vs how much you're making and/or losing. Remember, one "pirated" IAP is not necessarily equal to one lost sale, so it can be hard to gauge just how much you might be losing from this.
Related
The idea is whether rain or shine, wet or fine, user must get that he paid for all out.
From Apple:
Store Kit provides built-in functionality to restore transactions for non-consumable products, auto-renewable subscriptions and free subscriptions
For these transactions Apple Store Kit has good build-in tools. I want to focus on other types (consumable in particular).
One and only transaction information is an identifier and a receipt data which we receiving by Store Kit after successful purchase.
Our application uses server-side model to deliver products to it. But there still much cases of losing purchase data, such as if the server lay down while user is making purchase via App Store so its not possible to send receipt to server to complete verification process.
Current workaround is:
Server returns a list of product identifiers
User selects one; app saves its identifier on device (via SQLite or Core Data). Standart Apple Store transaction process goes right after that.
In case of success application saves receipt data in conjunction with its identifier on device and send it to server. If there were failure or cancelation the identifier is immediatelly removed from device.
If server's response is OK then app removes identifier with receipt data from device. Otherwise it will send requests to server periodically until successful response behaves.
But this approach still has leaks. For example, user can remove application from device not waiting for transaction delivering to server, so there will not any proof about his purchase at all.
Your suggestions?
The fundamental rule is that you not call finishTransaction: on the payment queue until you have successfully delivered content. That means that you make the request to your verification and content servers and they come back with valid responses. Only after those proper responses do you call finishTransaction:. Note that bad purchase receipt is valid just not good. You will get people trying to ripoff goods - don't lose sleep over it but do put in proper receipt checking.
As I understand it (from my non-consumable items), as long as you do not call finishTransaction, the store will continue to retry it on your app installation. For that reason, I do not think you need your application to save the receipt on the device. However, for consumables, the server has to store the data if you want to be able to restore it later. A non-trivial problem is what key to store it under.
BTW, your first line is absolutely correct and worth losing sleep over.
I am working on a application which has a more peculiar requirement. Basically it is something which is not targeted at end users but at a system integrator who will embed an iPad into a larger system and sell it to an end user as a whole.
However, the problem I'm facing is that the system integrators could simply purchase the app once and then keep cloning thousands of iPads from a single iTunes account, my company would not get any revenue from this.
Is there any way around this. I've looked at in app purchases but according to the guidelines I'm supposed to give in app purchase restore functionality so I guess if I don't the app won't get approved.
I could use external authentication servers I guess, but that may be viewed as circumventing the app store.
I've loked at the volume B2B stuff but I'm not quite clear on how that works or if it would help me in this case.
Any ideas?
Thanks
Last time I checked an application can only be installed on five devices, and then the other ones simply refuse to install the application.
If this system integrator managed to circumvent this, it's he who is breaking the App Store rules.
You can't use the App Store mechanisms as you described (you can't change iTunes). In-App purchases of non-consumable items must include a restore option so the user can restore it on all his devices even if it's thousands (this also for subscriptions etc). If you won't enable that you would be rejected.
You can think you can send the Device-ID for each device that purchase the item and have control over that(or any information) but apple would simply reject your app because it's forbidden to send device-ID.
If your service is online you can simply use some kind of tokens created on your servers which would be given to each client (from some kind of private key), This way you must be connected to each purchased item (only those would contact your servers and you would grant access).
Security wise you must consider leaving some of the functionality on your server side. This is not illegal same as you can't access Facebook without username& password.
And now for the easy way, Define your service as consumable item for in-App purchase(if you can). What does it mean? Lets say you are selling a special feature like "Ad-Free" you can sell credits that would be consumed with each app open or any other process you have in mind, You can even set this credit to 1 million for 0.99$ (so the user never gets to that) but still the consumer would have to buy it again and again for each device and it would be absolutely legal by Apple. Pay attention that the problem would be on the consumer side such as that if user have deleted his app you should find a way to help him or refund him on next buy. Also, If you can and would use this method pay attention to save those credits on the restored folder on the device, so if the user would upgrade or restore the device he would still have the credits he bought.
Pay attention that if you are going to use in-App there are lots of methods to steal this content on jailbroken devices and you must use your own server to check the buying process (according to Apple).
Another important thing is that the app without the in-App purchase must have some value to the user.
I have an application that we are building to be delivered to our users for free. However, the business wants to be able to sell this application to anyone else who might want it. Is there anyway we can do this?
The suggestions and concerns we've come up with are:
Submit app with price and deliver free download codes to users, but I believe that we only get something like 50 free download codes and we have more than 50 users.
Submit app for free, but make content an in-app purchase and have some mechanisim for allowing our users to validate and get the content free. We think that Apple will hate this since the application isn't functional without the content.
Submit application twice, one free and one paid and just direct our users to the free one. This means that our free version can be found and used by anyone cutting into the revenue stream.
Any suggestions/advice/hints/rants welcome.
Have you considered Software as a Service? The app is an extension of the service. Make the app free to anyone, but to get anything useful out of the app, require username/password or some other validation. You'd be hard pressed to find an app today that doesn't require some sort of signup process.
There are plenty of options you can go with.
In-App Purchase
Free/Lite version of App
Paid version of App
Just a matter of what you and your customers want. Good luck.
Why not have a very basic version of the app available for free (so that Apple is happy) and then have the rest of the app "unlocked" when the user either:
Registers their copy of the app back with your servers (covers giving it to some for free)
Makes an in-app purchase to unlock the rest of the functionality
This keeps Apple happy, gives you the functions you want, and is only minimal effort.
You can pay for and gift paid apps to iTunes account holders. Making the app appear to be "Free" to those recipients. If it's your own app, Apple will keep (only) 30% of the price you pay, so add that on to your cost of doing business.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
I have an app I'm developing which relies heavily on users being able to purchase content which will be downloaded from a server. As the app nears completion I'm becoming more concerned about my current distribution model, which is simply that when the user purchases an item the app then generates the correct URL and downloads the data (e.g., from www.website.com/content/music.mp3).
I have some simple web development experience, but I'm not aware of any authenticating process to ensure that only my iphone app has access to this content. In other words, as soon as somebody detects the outgoing URL request, they could get my content for free. Is there anything I can do to prevent, deter or even strongly discourage this?
Send the receipt to your server, verify the receipt and create a one-time-url for the file.