I'm developing an iOS game where the users can buy some amount of internal currency (say 1000 golds) by a Consumable In App Purchase.
How to restore a Consumable Purchase if the users want to transfer their balance from one device to another?
In Apple's docs it says that we have to use our own server. But how to get user's Apple IDs? Or may be there is some other way to track consumable purchases?
If what you want to do is to share the products the user buys across different devices; you will need to:
Keep the game state in the server and obtain it from the device.
Identify users somehow, i.e. username/pass.
Update the game state in the server each time the user buys/consumes/gains products
If you only need to share state across different installs on the same device, you could just use the device ID to identify the user.
You will need to be able to store the users state in a manner independent of the device they are using to access your game. So this would mean implementing a server based user profile with authentication (and appropriate security), or using some third party service.
Note that since iOS 4.1 you have the ability to use GameKit, which provides alot of these benefits for you. If you use GameKit then you will be able to retrieve user information from GKPlayer, and use this information to store currency amounts and other state in your own server.
Related
I want to share In-App purchased product identifiers from one app(say "App1") to another app(say "App2"). Both run on iOS 7 devices. And more importantly since "App2" was released long time back, both the apps have different Team IDs. When the user clicks on a "Restore purchase from App1" button I want "App2" to unlock certain features based on the purchases the user has made in "App1". What is the best way to achieve this?
I dont want to use UIDocumentInteractionController or UIActivityViewController because that would require unnecessary user interaction.
Key chain items or iCloud key-value storage cannot be shared because both the apps have different Team IDs.
Can't use an exclusive server through which the two apps can communicate.
You cannot do this by using the IAP API. You could store the information on your server and unlock it for a user, however, this is against the App Store Review Guidelines:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected.
And technically you would not be using the API if you checked against your own server and provided the content through that.
Now this looks possible for subscriptions with App Bundles: https://developer.apple.com/documentation/storekit/in-app_purchase/offering_a_subscription_across_multiple_apps
You can offer customers auto-renewable subscription services that are accessible through multiple apps across one or more operating systems.
In order to offer this functionality, your server must grant access to the subscription content across all apps, despite the user having purchased the subscription within a specific app. You can use a unified account management database along with server-side receipt validation to validate a user's purchase and ensure in-app transactions are handled. By entitling subscription access from your server, you can provide users the ability to access your subscription across multiple apps.
It's Possible using Authentication API
step 1: When purchased product successfully to store status inside API
step 2: Then call API every time of didFinishLaunching to check purchase status and use multiple APP
Another benefit is make payment without any payment gateway...
As you iOS devs know, you can only set one price tier for your app and in-app products in the app store. However, you can (theoretically) publish it as separate apps in different countries with different prices. I would like to do the same with in-app products of the same app - define alternative in-app products, and control their visibility in the app depending on user's country. I don't want to use NSLocale or NSTimeZone because they can be changed in settings. I want to know the country that the app store / user is connected to.
For example, I want to offer an auto-renewing subscription for most users, but I know that auto-renewing subscriptions are not available in the Israeli app store, so I want to show a non-renewing subscription exclusively to Israeli users, and not show them the auto-renewing one. Is there a reliable way of achieving this?
Thanks,
Avi
After investigating further, I discovered that when querying products in store-kit, SKProduct returns with a property named priceLocale, which consists of the country code and currency code. The country code of priceLocale seems to be consistent with the user's app store.
To sum up, doing these steps will get the result, however in a slow and not straightforward way:
Define an in-app item;
Query that item in your app;
Determine user's country according to [product.priceLocale objectForKey:NSLocaleCountryCode];
Show the user the relevant products your app supports in their country.
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.
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.