We are three guys, who have made a free game for iPhone, which has been available on the App Store for almost a year.
The app is a board game, where you create a user or login using your Facebook credentials. You are able to log out of the game and log back in with another account.
Now we have updated the app with the ability to upgrade the user to a premium user. Allowing personal and global game statistics.
But Apple is giving us a headache in the approval process, and refuses to accept our In-App Purchase. First they would not approve it, as it had no restore button. Then when we told them, a restore button was not required, as it was a consumable purchase, they now demand we change it to a non-consumable and add the restore button.
Consider this scenario if purchase was non-consumable.
User logs in.
User upgrades account to premium
User logs out.
User logs in with a different account.
User restores the previous purchase.
This would allow you to upgrade two accounts to premium, but with just one purchase.
Apple's argument is, that our users need to be able to restore purchases, if a new device is setup, or a device is restored.
But that is not the way it works. Users upgrade their accounts to premium accounts. Now when they buy a new device or restores an existing device, they just log in with their existing game account, and the upgrade will be available, because we on the server-side has marked the account as a premium account.
So my question is basically. Were we totally wrong, when we choose to use a consumable instead of a non-consumable. And if so, how should a non-consumable be implemented in order to be (potentially) purchased more than once with different game accounts on the same device?
And secondly, if we are correct about the usage of a consumable in-app purchase, what should we say to convince Apple, that we are on the right path?
If your premium account is something that your users have to buy only once then Apple is definitely right to ask you to switch to non-consumable in-app.
The scenario you described is quite possible (i had to face it too) but if you add server-side verification of in-app receipts before unlocking the premium feature (saving all transactions associated to a user) you have the chance to verify that the purchase is new or restored checking the fields original_transaction_id and original_purchase_date in the receipt data. This way you can see if the user restoring the purchase is the same that originally bought it (maybe checking its facebook user id).
Anyway, experience showed me that the chance of this happening is not really high and i wouldn't recommend implementing this check (although server side validation is almost always a must ;-) )
According to the 'Restoring Transactions' section of the In-App Purchase Programming Guide:
If your application supports product types that must be restorable, you must include an interface that allows users to restore these purchases.
If your app contains non-consumable purchase, and if you don't include a restore button apple will not approve your app.
This has been made necessary by apple after June 2012.
So to answer your question: No, it seems that you must use restoreCompletedTransactions.
Hope it helps you.
Related
In my app user can log in with a phone number (account) and purchase auto-renewable subscription. This subscription will be associated with his account so he can log in on another device and see his purchased items. The problem is that he can log in with different phone numbers (accounts) on the same device where the subscription was purchased and restore purchases. So he can restore purchased item for other accounts using the same subscription.
Question: Can we remove Restore Purchases functionality in that case? If we can't how can we handle such situations?
I heard that all apps in Store should have restore purchase button but it doesn't make sense in our case.
See this answer here: https://stackoverflow.com/a/54153169/3166209
In summary, you're required you to have restore functionality, but it doesn't have to be implemented through StoreKit. You'll notice large, cross-platform, subscription apps like Netflix don't have a restore purchases button anywhere for the exact reason you mentioned.
For an iOS game application that has in-app purchases which are considered to be non-consumable (buy once and permanently unlock) when logging onto account A from a different device, a user has the option to restore items purchased, but creating a new game account or multiple accounts what should/shouldn’t be allowed with restoring and what is recommended in this scenario from a dev point of view?
The purchase and restoring is done by Apple and you can't influence that. If the user click restore, you don't have to do any check yourself. You make a call so Apple checks if this user has already done the purchase. It means that a user on a new phone can restore using its account, but a user making a new account can't restore. To you it doesn't matter. You show the restore button anyway and let Apple's API tell you what must be restored.
This links contains the Apple guideline for restoring IAP.
I am planning to use subscription (auto renew) type of in-app purchase. My idea is to allow one subscription per device. (i.e.) if someone purchase the subscription on iPhone, he shouldn't be able to use same subscription on iPad. Instead I want to force user to new subscription for other device. But from in-app purchase what i understood is that, if user subscribe for a particular item, if he tries to purchase the same thing again, app store allows to user to restore already purchased item.
As per my current setup, all the downloads will happen from a separate server and I am going to keep all the receipts and content in that server. In order to implement this particular thing, what should I do in my application? Could someone help me on this?
Also if I want to limit download of data from server using in-app purchase for only 3 device? Beyond 3 I want user to make payment via in-app purchase again? How will I do this?
Thanks
Apple's In-App Purchase Guidelines state that you must support restoring subscriptions to all of a user's devices (see page 7).
Also consider if your content is episodic (such as a TV show or magazine) because that's a requirement for using auto-renewing subscriptions. For things like time-limited access to a certain feature, like voice guidance in a navigation app, you'd need to use non-renewing subscriptions.
i have a news reader app. i want to add IAP to my app.
i added Consumable Purchase. when the user purchases i write expire date to nsuserdefaults.
when it expires i show purchase screen again.
but apple rejected it,
it says:
However, based on product functionality, it would be more appropriate to use the Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
...
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:
....
first i tried to use Auto-Renewable Subscription, but my app doesn't have any content to be downloaded.
then i tried to implement Non-Renewing subscription. but people say that it is deprecated.
i want to allow users who buyed app to use it on other devices too.
but i can't get AppleId (Apple doesn't allow it either).
I'm really stucked.
how can i add monthly subscription to my app?
can anyone give me some advice...
I've been through almost the exact same thing. Here's what you do:
First off, although Apple's documentation seems to suggest that Non-Renewing Subscriptions are deprecated, they are not. In fact, that's what Apple steered me towards when they rejected my app for using Auto-Renewing subscriptions.
In terms of syncing across multiple devices: I tried using a unique identifier that I stored on the user's iCloud account to identify a user (like what #Yorxxx suggested), but Apple rejected the app again, saying that the guidelines state that I need to provide an optional username/password system to allow a user to restore their subscription onto all their devices.
A few notes about Non-Renewing Subscriptions:
You set and track your own durations and expiration dates.
You essentially have to administer the service from your own server, since you'll need to sync a user's subscription across all their devices.
There is no prompt asking the user if they want to send the developer their contact information.
restoreCompletedTransactions is useless with Non-Renewing Subscriptions.
If I were you I would store the persons username on iCloud if they give you one. That way, when they install your app on a new device, you can prompt them that they already have an account and if they log in, their existing subscription will by synced to that device.
I have a question regarding in-app payments for iPhone apps. I thought the only difference between auto-renewing subscriptions and non-renewing subscriptions was obviously the self-renewing thing.
But as I read through the documentation it seems that there are other important differences. This is how I understood it:
Auto-renewing:
user can disable auto-renewing (so it might behave like a non-renewing subscription)
is restored after a device reset
is automatically transfered between different devices on the same iTunes account
can only be bought once (as long as the subscription is still valid)
Non-renewing:
the developer must handle license restoring after device resets
user can buy the subscription more than once at a time
Is this correct?
I seems like auto-renewing subscriptions are way better for my app, even though I don't need the subscription to necessarily renew automatically.
But, as an additional question, when I added a new product in iTunes Connect, I had only the choice between "Consumable", "Non-consumable" and "non-renewing subscription" - but no auto-renewing subscription?!
Best regards
I think you get the differences globally.
Some corrections however:
is restored after a device reset
is automatically transfered between different devices on the same iTunes account
Not really, it's up to you, in your application, (usually in the dedicated "store" part of your application) to propose a restore subscription so that the user will be able to get back his subscription on this iOS device (this may be needed if he resets the device as you said, but also if he deletes the application and reinstall it).
The restore action (triggered in your code via StoreKit) will automatically prompt the user for his iTunes password, so this cannot be done automatically without user acknowledge.
user can disable auto-renewing (so it might behave like a non-renewing subscription)
yes this can be achieved from the settings in the iPhone, in the "store" part, and then display for apple ID properties: the user will get a view with all his on going subscription + a switch to disable the auto renewing.
when I added a new product in iTunes Connect, I had only the choice between "Consumable", "Non-consumable" and "non-renewing subscription" - but no auto-renewing subscription?!
I also had this at the beginning, the reason for that is that you didn't acknowledge a part of the contract (Amendments) that is specifically related to autorenewable subscription. As far as I can remember, go to the Contracts, Tax, Banking part of itunesConnect and you should have something to agree on, then you'll be able to create auto-renewable in app purchase.
a subscription is not synced with iTunes instead it is saved on a apple server somewhere. It is stored in your account (indeed thats not correct, it can be synced but I mean it's not only stored on the device). "Consumable" are such things like ammo in a shooter game. You can buy them more than one time and but this would mean that "Non-consumable" and "non-renewing subscription" are nearly the same.
Did you read the customer help also additionally to the developer documentation?
http://support.apple.com/kb/ht4009