In the this Article Apple wrote how to enable an auto-renewing subscription from the users point of view. But my question is how to handle this auto-renewing subscription as the developer of an app?
In my app (currently in developing) the user can buy some subscriptions (30 days, 3 months and 1 year) via in-app-purchase. After a successful payment I send the bought item identifier to my server to save the new subscription time (also used for other platforms). This works perfectly in the sandbox-environment.
But if I correctly understand the article the auto-renewing subscriptions is performed from inside the AppStore and inside my app. How can I now track the subscription?
If a subscription is autorenewed, the transaction won't pass the paymentQueue:updateTransactions method. The renew just happens on the Store.
If you want to test for it you have to either:
Revalidate the receipt on your application server, if you store the receipt there.
Revalidate the receipt on your iOS client
See: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1
In order to avoid testing for an autorenew each launch/activation you should store the endDate of the subscription period to test for a renew afterwards.
Also see: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html#//apple_ref/doc/uid/TP40008267-CH4-SW4
However, there seems to be a bug in the sandbox. Subscriptions sometimes get renewed, sometimes not. Hard to test....
based on the (rather scant) info found in apple's in-app-purchase documentation, my impression is that whenever you need to determine the state of a user's auto-renewal subscription, you would restore their transactions.
this would cause the app store to send all auto-renewal transactions to your app, at which point you would process the receipts and make the appropriate content available.
presumably, you would only need to do this when the user's current subscription (which you can track locally) is set to expire, or when they are first installing the app.
Related
I have an auto-renewing subscription in my macOS app. The initial purchase refreshes the app receipt, which can be locally checked to validate whether the user has an active subscription.
When the subscription automatically renews, the app receipt is not updated. Even when the transaction passes through the SKPaymentQueue on app relaunch, the receipt is still not updated.
The only way I've managed to get a current receipt is to use SKReceiptRefreshRequest, but this prompts the user to input their App Store login credentials.
How can I make sure the user's subscription information in the receipt is up to date without using server-side receipt validation?
EDIT: The behavior described reflects my experience with the StoreKit sandbox. If the same behavior can be confirmed to be nonexistent in production, that would be awesome.
I'm creating a Mac app that has a non-renewing subscription as an in-app purchase. I want to sync this data to the cloud for the following reasons:
I want the user to be able to use the app on all their Macs
The in-app purchase enables a widget, so that widget needs to access this data.
By Apple's documentation the restoration of non-renewing subscriptions has to be handled by the app by some kind of registration / cloud sync.
So I decided to implement a CloudKit sync to store the following data:
Which IAP product did the user purchase (currently only one value, but might change in the future)
When did the purchase occur.
Here's what I'm doing now when a user makes an in-app purchase:
I validate the receipt
If I find any IAP data, I sync that to CloudKit
I use a function to fetch the purchase data from CloudKit for the said widget
Question 1: As far as I can tell all the in-app purchases are contained in the receipt file, even after removing and restoring it. I could be using this, however the documentation clearly says I shouldn't. Even the forums are not certain about it... What do you think?
Question 2: While testing the app with multiple sandbox users I noticed that no matter which sandbox user I use to make the purchase, the currently logged in iCloud account (my personal account) gets the receipt data synced to CloudKit. Why isn't the purchaser (App Store) user getting the data to their private cloud database? How can I test that everything works fine? Do I have to log out of my iCloud account to make this work?
Thank you for your time :)
Question 1: Using the App Receipt to restore non-renewable subscriptions
From Apple's Documentation:
Apple's documentation on whether an in-app purchase of a non-renewing subscription remains in the receipt has contradictory answers:
Yes (retrieved 2016-05-11):
Table 1-2 Comparison of subscription types
Subscription type Auto-renewable Non-renewing Free
Users can buy Multiple times Multiple times Once
Appears in the receipt Always Always Always
Synced across devices By the system By your app By the system
Restored By the system By your app By the system
No (retrieved 2016-05-11):
The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt.
From Apple's Developer Forums:
In a thread reporting the temporary (now fixed) loss of non-renewable subscriptions from the app receipt, an Apple Developer Technical Support engineer said:
I've queried the iTunes Production Support engineer who made the change - The "fix" to provide the history of non-renewing subscriptions in the application receipt is permanent. My interpretation is that permament means that if we make a change, we'll announce the change at a Developer Conference and announce the function to be deprecated for a period of time.
With regards to using iCloud as a means to restore non-renewing subscriptions, I've heard from my App Review contact - an application "can use iCloud to track the non-renewing subscriptions (NRS) but it can’t force the user to login prior to making the purchase. It has to be optional - that can can alert the user that iCloud is required to access the NRS content from their other iOS devices - and providing a way to register later, if users wish to have access to this content at a later time."
Source: https://forums.developer.apple.com/thread/22345#79067
You could attempt refreshing the app receipt to restore the non-renewable subscriptions, but it has broken before, the documentation isn't clear, and there have been past reports of App Review rejecting applications that try this method.
Question 2:
CloudKit always uses the current iCloud account under Settings > iCloud.
App Store purchases use the Apple ID configured in Settings > iTunes & App Store.
The user may be signed into the same Apple ID for both iCloud & iTunes, but there is no guarantee. These are two entirely separate settings.
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.
The app we are creating delivers information which updates on a daily basis, how to provide a free taster is unclear to me. Can you help?
Info on Non-Renewing Subscription from p149 of the iTC developer Guide, p151 states Inn-App purchase cannot be free.
https://itunesconnect.apple.com/docs/iTunesConnect_DeveloperGuide.pdf
■ Non-Renewing Subscriptions have been used in the past for services with a limited duration. An example of this would be a magazine or newspaper that requires users to renew their own subscriptions. Non-renewing subscriptions can still be offered, but auto-renewable subscriptions are now preferred for the following reasons:
When creating an auto-renewable subscription, you can easily set up the various durations that you want to offer. Non-renewing subscriptions do not have this feature, so you must provide the information some other way. As this is often done in the display name, you end up with a separate listing for every possible duration. By contrast, auto-renewable subscriptions allow you to have a single listing where the user simply chooses one of the durations that you offer.
Because a non-renewing subscription requires a user to renew each time, your app must contain code that recognizes when the subscription is due to expire. It must also prompt the user to purchase a new subscription. An auto-renewable subscription eliminates these steps.
As part of iOS, an auto-renewable subscription will automatically be delivered to all devices associated with the user’s Apple ID. To make device-syncing available for a non-renewing subscription, you would have to create your own delivery system.
You could sell your app for free on the store. Then offer a non-renewing subscription, but only show the option to the user after a month has passed (or whatever period you choose). You should administer the subscription from your own server so that you can verify receipts, and keep track of expiration dates even if a user deletes your app and re-installs it. Using your server will also give you a way to sync the subscription across all the devices a user owns (which is required by Apple. They essentially insist that you implement an optional username/password system to allow a user to restore their subscription to other devices).
Warning: Don't use the words 'trial' or 'demo' in your app or description. This is against Apple's policies. Also, don't make your app dead if the user chooses not to buy a subscription after a month. This will also likely get you rejected. You should continue to provide some functionality.
Distribute a free lite version with function limit, or try in app purchase.
I was looking to this thread.
It's stated that the App Store calls the paymentQueue and posts a transaction with transaction.transactionState==SKPaymentTransactionStateRestored.
But I'm not getting those calls. I'm testing
with sandbox accounts/subscriptions, that expire and are auto-renewed every 3 minutes;
WITHOUT verifying receipts.
This way, my updatedTransaction method is never called after the first buy.
Anyway, if I later on restore completed transactions, I get all the receipts.
Any experience with sandbox? Also, the point 2) is needed or (as I think) it's optional?
The state: SKPaymentTransactionStateRestored is only determined if you have the receipt on the user's device and you use it to make the transaction. If you do not have the receipt, then you will need to call restoreCompletedTransactions to decide whether to apply the auto-renewed subscription.
The situation when you won't have a receipt is when the user buys an auto-renewable subscription, then deletes the app or installs the app on a different device. In other cases, you can safely store the receipt on the device.
The issue is detecting the case when the user has purchased an auto-renewing subscription and needs to have the content activated. Without a receipt, if you trigger the transaction, it will fail with the state SKPaymentTransactionStateFailed. Looking at the error code, you will see SKErrorPaymentCancelled. This, as far as I can tell, is a bug on Apple's part. You will need to make the best decision for your app to deal with it :/