I am just trying to implement In-App-Purchasing with in my application and I am successfully able to test my application but I want to offer few part of application will be free and some part will be give to user after payment. How can I do it. Thank you.
we basically keep the features locked in our application and unlock them after user makes in app purchase. To lure the user, when user tries to access that feature, we usually show the user message that it is locked in this version of application and in order to unlock it, in app purchase needs to be done.
All the features should have unique product identifier, so as to identify which feature the user unlocked (purchased)
Related
I got most of IAP purchase working, using user defaults etc
But supposing a user buys an app, then erases or updates to a new phone.
Then reinstalls the app.
How do I detect that the user has previously purchased the app?
That is what restore functionality is for. See the Restore section of:
https://developer.apple.com/documentation/storekit/in-app_purchase/offering_completing_and_restoring_in-app_purchases
There are three ways:
If you store some purchase indicator in the app keychain, it will be present when the app is re-installed. If you are doing subscriptions also include an expiration date you can check if a subscription is possibly out of date.
If you send the app receipt up to Apple, it will always give you back the most current purchase data - which includes any prior purchases. So on first launch, always send the receipt up to Apple to see if you might want to automatically restore a purchase made previously. Note that sometimes an application receipt will not be present immediately after install (although it should always be there), which is why you also need to allow for option 3.
There is also a SKPaymentQueue’s restoreCompletedTransactions() call you can make to basically replay previous purchase transactions. This is something you should wire to a button somewhere in your UI - Apple requires that. It's not something you want to automatically call as it can prompt for the user to enter their iTunes account password, so you should not rely on this method to restore purchases automatically, but it is good to have in place as a backup for the user.
So all the documentation and posts I see about auto-renew subscription are using the server side model to deliver products. Is there a particular reason why one couldn't use the Built-in model.
I am creating a audio player app that will provide new original music every month. With service side verification I understand that it checks to see if the receipt is valid before allowing the user to download the audios from my server.
However, couldn't I just program my app to ping the app store to see if their subscription is active. If their subscription isn't active have the app sit on the home screen saying "Please renew your subscription before regaining access to the audio player"
It's my understanding that the server side model is there to prevent pirates from gaining access to my servers resources. Is there any other reason I should use it?
It depends on whether you want your application to be hacked or not.
Main reason for all the validation routine is that once application is available to user, he can modify it in any way he likes which can be seen on all the hacked iPhone apps out there.
So in your case they would delete all checks from your code and set "active" to true.
Currently I'm working on an app for a social network, where users have to purchase premium membership to unlock some extra features.
At first I used auto-renewable subscriptions, but my app got rejected. They told me to use non-renewable subscriptions and:
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
The most logical way to transfer subscriptions in my case would be by using registration, as user can't view the content (or purchase subscriptions) without registering and logging in. So this means that registration is required.
Will my app get rejected again? If yes, then what workaround would you suggest?
Any help would be greatly appreciated.
Yes and No.
If you force your user to register (especially with email address) =
REJECTED
If you make registration optional and let the user to use your app
with limited access = APPROVED
(The above statement was from my own experience and understanding. Please correct me if I'm wrong.)
First my app got rejected for using auto-renewable subscriptions.
But second time my app got rejected (this time non-renewable). The reason is, my app requires user registration. In apple's term, 'requires' means 'force'.
If you choose to use user registration to meet this requirement,
please keep in mind that it is not appropriate to require user
registration. Such user registration must be made optional. It would
be appropriate to make it clear to the user that only by registering
will they be able to access the content from all of their iOS devices;
and to provide them a way to register later, if they wish to access
the content on their other iOS devices at a future time.
From the above, the highlighted lines makes it clear that, the user registrations MUST be optional. If the user wish to access on other iOS devices, they can choose to register. But there is a catch again.
The catch is,
17.2 Apps that require users to share personal information, such as email address and date of birth, in order to function will be
rejected
So what I'm going to do is,
I would let the user to buy subscriptions without registration. But I will auto register the user with the unique ID to identify the user later. And showing the user, that, they have to register with an username and password in order to access the subscription among other iOS devices.
I would not force the user to register with email address. Instead, I will use 'username' as mandatory and 'email' as optional, but stating that, it's recommended to enter the 'email' so that, it would be easier in case of password recovery.
This is my experience with apple's in-app purchase so far.
Please correct me if I was wrong any where...
Auto-renewing subscriptions are only for periodical content like magazines, newspapers, etc that appear in the newsstand app. Apple will flat out reject any use of Auto-renewing for any other purpose. You have to use Non-renewing Subscriptions for "Services". Best info for this is http://developer.apple.com/news/pdf/in_app_purchase.pdf
As for the user registration chicken-and-egg scenario, you can get the app approved if it allows registration of anybody regardless of in-app purchases. That is to say, only allow the IAP after the user has registered. Your "Free" users can just have limited content.
I don't think that Apple would reject an app just for requiring registration, unless that registration's sole purpose was to allow a user to share their subscription across all their devices. In that case, Apple insists that you provide an optional method for the user to share the subscription.
This is the scenario for the application right now:
The application I am working on has it's own login service, i.e., the user can register on the app and login to it too.
A user logs into the application (by the application's credentials) and then gets options to buy any of the 10 books listed there. After the book is bought, it will be registered with his application's userID and every time the user logs in with the ID, on any device, he will have that book available.
Now, since in this scenario, a user should be able to purchase a book again and again (but with different app credentials), I am thinking of using the "consumable" product option and adding a condition in the application itself that checks what books the logged in user has bought and not display to them the books they have bought (again, by app-credentials). This way, the won't be able to buy the same book again.
Is that possible?
Please advise.
If I understood you correctly, you just don't want to let user buy the same book more than one time. If so, you just need to check on application start which books user has already purchased and then correct the list of available for purchase books removing from it already purchased.
I think you want to implement Non-consumable product where if user purchase any book from one device then it should be available to user on other device as well.Store Kit provides built-in support to restore non-consumable products on multiple devices.To restore transactions, your application calls the payment queue’s restoreCompletedTransactions method.
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.