I'm currently working on an iOS app that will allow users to purchase an auto-renew subscription to access service charged monthly. I would like to be able to offer a basic and premium service, and allow users to upgrade or downgrade from one or the other.
I've set up test users and some test products and I've found that if you select the basic subscription first and then later on select to purchase the premium subscription the test user is charged for both services simultaneously.
Does anyone know if its possible to programmatically cancel a users current subscription when we've noticed they've either upgraded or downgraded their service, so they are only being charged once?
I've seen that using this link
https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions
Allows a user to manage their subscriptions manually, but I would like to handle migrating them to their new plan automatically.
The control over the subscription once purchased is by the user. Only the user who purchased can cancel the renewal. As a developer you can't do any changes.
After a discussion with someone at Apple the answer to this is question is that there is no support for multiple product subscriptions with the same duration. They would not comment on how certain apps are able to do this. Officially it's not possible.
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
I work for a game developing company which releases at least one game a month. For our true fans we want to start providing a subscription to our games, so they can play all our games (on any platform) without constantly having to buy them.
The idea for iOS is to use the in-app auto-renewable subscription. This results into a receipt which we store in our backend. The backend can validate this receipt and provide the apps with information about the subscription of the user.
This system will solve a lot of problems: You can take the subscription in 1 game, and play all the games as well, on any device you like.
But now we come to the problem: After a month the receipt is not valid anymore, and we need to check in the iTunes store to see if the user still has a valid subscription.
My first idea was to use the "latest_receipt_info" field, to get the latest receipt and validate this. But according the documentation this feature should only be used for iOS 6 receipts:
"Only returned for iOS 6 style transaction receipts for auto-renewable
subscriptions."
source:
https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-
Even though I can actually still use this field with my brandnew iOS 10 receipt, I don't think it's smart to use it since it's deprecated.
(another source telling you shouldn't use it anymore: https://forums.developer.apple.com/message/156580#156580)
The advised solution of apple is to implement a SKPaymentTransactionObserver in the app. This will retrieve the latest receipt when it's available, and send this to the backend. Even though this is far from ideal, this could work... however:
This means the app has to be active to retrieve the latest receipt. And in our case it's very well possible a user takes a subscription in app1, and after a couple of days downloads app2, 3 and 4, but never uses app1 again. So in this case the latest receipt will never be fetched (because only the observer of app1 can access the receipt)
To fix this problem we should be able to fetch the receipts from this subscription from any app in our subscription group. But according the documentation on the apple site (https://developer.apple.com/app-store/subscriptions/ ) you can only access a subscription from 1 app, and you have to do the multiple app thing yourself:
You can offer auto-renewable
subscriptions to access multiple apps in your portfolio. Each app must
be approved to use auto-renewable in-app purchases and must be
published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent
auto-renewable in-app purchases in each app offered in the multi-app
subscription so that users can subscribe from any app. To avoid users
paying multiple times for the same offering, you are responsible for
verifying that they are subscribers in one of the apps before showing
any subscription options. To do this, consider maintaining an account
management system in which users create an account with your business
to sign in to each app.
So is there any way to do what we want, without forcing the user to go back to the app he used to purchase the subscription every month?
On the last WWDC we went to StoreKit labs and personally asked StoreKit evangelist about this. We were told that the 'latest_receipt_info' field return by iTunes validateReceipt endpoint is exactly what we are suppose to use in order to check if the subscription was renewed or not.
This is not going to be deprecated in the near future but they do have plans for adding some server-to-server communication that solve few of the problems we ran into:
Your server will be able to get notification from Apple regarding any subscription renewal, cancellation, downgrades etc.
In the latest_receipt_info returned by the validateReceipt endpoint few fields will be added, providing information like whether the subscription will be renewed after current one is expired, whether there was a problem charging the user's credit card etc.
Sources:
WWDC 2017 Session 303 - What's new in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit
We are developing one iOS application for iPhone which will free features as well app will have premium features with 4 in app purchase auto-renewable subscription options as below:
Single monthly subscription
Single yearly subscription
Family monthly subscription
Family yearly subscription
We will have one store screen inside the application which will have options to subscribe to various subscriptions which our app provides.
We found that user can go to device settings and manage their In-app purchase subscriptions.
We are also planning to provide options like user can upgrade from one subscription to other and user should also be able to down grade their subscription which would be all of the same options in reverse and back to the free version
Possible upgrading option:
Free to Any 4 subscription options
Single monthly to single yearly
Single monthly to family monthly
Single monthly to family yearly
Family monthly to family yearly
Possible down grading options:
Family yearly to family monthly
Family yearly to single monthly
Family monthly to single monthly
Single yearly to single monthly
From any 4 subscription options to Free version
Note:
According to Apple we can not use Apple family sharing option to share In App purchases so we are developing our own family sharing option in application. (Reference: https://support.apple.com/en-in/HT203046)
Queries:
We have some doubts how we can manage the subscription in our iOS application?
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
Apple will reject custom family sharing option using auto renewable subscription option?
What are the points we need to take care at our end which apple will not handle if we can go with above features?
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
It will be great help to us if any one can share their views or provide some guidance on which way we should go or if we are going off track from the apple policy.... all those kind of your feedback will help us to get things moving over here.
Thanks
We have some doubts how we can manage the subscription in our iOS application?
Because you are using your own user management system, you should persist the state of a subscription associated to the user in your database. When the user creates a purchase in the app, the app should send this receipt on to your API which will then proceed to validate it.
Once persisted, enqueue a scheduled process to run on the Subscription Expiration Date to update the record and ad infinitum until the expiration date is no longer in the future.
Your app should query your API when the user opens the app to determine their subscription status. Don't rely on the receipt locally in the app as your user's family member devices will not have this purchase associated.
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
If all products listed in iTunes Connect are of the same "Subscription Family", they will appear in the Subscription Management page in the users iTunes account.
When a user switches between products a transaction will be created and a SKPaymentTransactionStatePurchased event will be added to the SKPaymentQueue. This will be a new transaction with the same Original Transaction Identifier as the first purchase made with a product from the same Subscription Family with the Product Identifier reflecting the new product.
For this reason, you want to have your transaction observer in your app running in the background to receive any new transactions. When a new transaction is received you can either a) send the whole receipt to your API or b) inform your API that a new transaction has been received and re-validate the receipt that was persisted.
Going with (a) may become problematic as the receipts will become larger over time requiring more bandwidth from the user each time.
Going with (b) also has it's drawbacks because you can get into trouble with edge cases like the user switching iTunes accounts. A solution for this is to store the apps identifierForVendor with the receipt, and require the app to send the whole receipt if it does not match. Most of the time you will just be informing the API that a transaction has occurred, and on the few occasions that the identifier doesn't match it will send along a new receipt.
What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
When restoring, a new transaction with a new transaction ID will be created, the original transaction ID will be the same though. If you create a transactions table in your database, you can ensure a transaction and it's original transaction is only ever associated to a single user, thus preventing users restoring purchases on other devices with a different user and gaining access to the subscription.
A restored transaction will be pushed onto the queue with SKPaymentTransactionStateRestored and so when this happens simply I advise sending the receipt to your API and process the receipt normally; associating any new transactions to the original user.
Apple will reject custom family sharing option using auto renewable subscription option?
I doubt it, but I am not Apple so don't take my word for gospel. Spotify have a similar scheme called "Spotify Family" where a user can share their Spotify account with their family, not sure if this is enabled for their iTunes app though.
What are the points we need to take care at our end which apple will not handle if we can go with above features?
You need your own API with user management and family association
Your users need to sign-in/register on your app
You will need to prevent family users from purchasing if their parent account already has a purchase.
Persist receipts and the identifierForVendor in the database.
Handle receipt validations using the validation API.
Persist a table of transactions and consider this table self-referential so that a transaction can belong to an original transaction through the original_transaction_id. Ensure the transaction_id column is unique.
Validate the receipt each time a transaction is due for renewal.
What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?
I see nothing in the guidelines except for section 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
I think this one is a little contradictory, since in 17.5 it states:
Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected
I guess by this, it means a user must be able to use the app without requiring registration, but I know of many examples of apps that do exactly this.
I am implementing auto-renewable subscriptions in iOS and want to be able to test the scenario where the user cancels the subscription but I am unable to do so because when I try to manage subscriptions with the sandbox account the app store wants me to associate a payment method with the sandbox account but in my experience once I do that the sandbox account is no longer valid.
Is it even possible to test cancellations or do I just blindly code for cancellations? I have search high and low and have not found anyone who has been able to manage subscriptions in a sandboxed environment.
I realized today that I was thinking about this all wrong and I can see why its not as necessary to be able to manage subscriptions. I was thinking that the 'Cancellation Date' field would reflect when a user cancel's (or really just opts out of auto-renewing) their subscription. But I was mistaken this field is only for the times when a user contacts Apple Support and requests to cancel early and receive some sort of a refund, and this is not something that is managed directly by a user.
Have you tried using a TestFlight build? You can do sandbox IAP testing via TestFlight with a "normal" iTunes account that has a payment method. I would assume that means you could try out canceling the subscription.
Although I searched a lot on this site and used Google as well, I cannot find a good solution for my problem.
I'm creating an app that offers a paid web service as an option. I would like give away a initial period of this service and link this to the purchase date of the app.
The Daily app is doing something similar. After downloading the app, you can read The Daily for two weeks for free. After that time, you have to subscribe.
Your help would be highly appreciated!
From Apple's developer guidelines:
Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected
If your premium web service is at all useable outside the app itself, in-app-purchase won't be a solution, so you'll have to implement the logic on your server, based on user names, etc.
If, however, it's simply a web service that iOS accesses—think if Instagram offered a paid upgrade in the days before their Android app—then you could use IAP subscriptions to do the trick. Again, from Apple's documentation:
Auto-renewable subscriptions are delivered to all of a user’s devices in the same way as non-consumable products. However, auto-renewable subscriptions differ in other ways. When you create an auto-renewable subscription in iTunes Connect, you choose the duration of the subscription. The App Store automatically renews the subscription each time its term expires. If the user chooses to not allow the subscription to be renewed, the user’s access to the subscription is revoked after the subscription expires. Your application is responsible for validating whether a subscription is currently active and can also receive an updated receipt for the most recent transaction.
As a side note, it looks like Apple are about to implement free trials, but haven't quite done it yet (there are some interesting hints in some of the documentation, but there's not an option when creating an IAP subscription yet).
I suggest you put some UI in that invites users to subscribe to the free service, and save that YES/NO answer along with the [NSDate date] in a defaults variable synced to iCloud. This means that it will be tied to their Apple ID, and can't easily be deleted by removing the app—next time they install it, you can restore that preference key.
Then, once the trial period is up, bring up your custom UI (since all the IAP UI is custom!) that gives people the chance to subscribe to an ongoing service using the auto-renewable subscription.