The current version of an application in the App Store is free and has very limited functionality. An In-App Purchase unlocks everything else.
I have decided to remove the In-App Purchase and just make the application cost the same price as the In-App Purchase did. But if I make the update now, then those users who have the free version but who have not yet paid for the In-App Purchase will get a free update into the full version.
I have removed all traces of my singleton class, PurchaseManager, from the application, so that at this point, when I build/run it, all of the features are unlocked. At this point, how can I make sure that the free-version users don't just ride an update into the full version?
Maybe there's a way to test whether the app is obtained through an update or through a purchase? That way, if it's through an update, I will see if it's the free version w/o the IAP and then force the user to purchase the IAP to continue playing.
Any ideas?
There was a user default that was guaranteed to be set in the first version. If the objectForKey: returned nil, then it was never set which means the first version was never run. In that case, I set YES to the user default for whether the In-App Purchase was purchased.
The above ran only once, which guaranteed that users of the demo continued to use the demo until they bought the In-App Purchase (priced the same as the second version of the game), and that users of the full version from v1.0 had the full version as planned.
Not that easy. Push out a minor update your current app and record the device ids of all those who got the in-app activated.
post a blog on your site asking users to send in their device ids and emails for re-imbursing the cost of the in-app purchase. You can cross verify this from the collected device ids.
I know this is painful. Most people who first released their apps on Cydia and then officially on app store did this. For example, snapture.
Related
I made an app and released it onto the App Store costing $2.99 AUD.
I now want to make it free and block some features for a premium upgrade(In App Purchase) My problem is that I want the users who have already purchased the paid version get an update to the premium version of the free app.
I was wondering if there is a way to verify the user has purchased the in app purchase before on launch of the app and if it comes back saying they have purchased, they get the extra features and if not, they don;t
Is there any way to check or verify purchases??
Thanks
The way to do this is to to check the original application version from the receipt. There is a receipt field called original_application_version. This is the version of the app that was originally purchased. You can check the receipt to see if the original version is from when it was a paid download, and flag that this user is "premium".
Whether you want to do this locally or server side is up to you.
Note that download receipts are not present in Sandbox, but should be in production. So you'll have a receipt even if no in-app purchases have been made. If for some reason there isn't a receipt present on the device, you should have a restore purchases button that will return a receipt where you can check the original application version.
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.
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 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
I submitted an iPhone app to the store that got approved, but some things with the inApp purchasing weren't working. The consequence is that the users that tried to install the inApp purchases were charged, and Apple has recorded that they already purchased the additional feature. I have fixed the issue, and I use NSUserDefaults to track whether or not a user has purchased the feature. The problem is the users that have already paid for it. Is there a way to check through Apple whether or not the feature has already been paid for?
Thanks.
See the Restoring Transactions section of the In-App Purchase guide. Specifically:
Store Kit provides built-in functionality to restore transactions for
non-consumable products, auto-renewable subscriptions and free
subscriptions. To restore transactions, your application calls the
payment queue’s restoreCompletedTransactions method. The payment queue
sends a request to the App Store to restore the transctions. In
return, the App Store generates a new restore transaction for each
transaction that was previously completed.
If it is a consumable product (it shouldn't be) then I don't think there is a way to do it via Apple.