I have an iPhone/iPad application that offers a monthly subscription to a service. Although, this service is totally useless during 2 months in the whole year.
Is there any way to either suspend all my users subscription for 2 months, or give them a 2 months refund every year so they don't pay for a useless service ?
After a good talk with an Apple employee, it is not possible to suspend an auto-renewable product.
Also, 0$ subscriptions do not exist outside NewsStand apps for the moment.
In order to solve our problem, we will have to delete the in-app product in iTunes Connect. This will automatically cancel all active subscriptions we have so the users will not be charged for nothing.
A big downside to this solution is that we will lose all current subscribers, so next year we have to build up a new subscriber bank from scratch.
Maybe you can give two months for free to your users instead of refund them.
Have you found any better alternative, since posting your answer about canceling all subscribers every year?
In addition to 1-year subscriptions, apple lets you do other terms as well, including 1-month subscriptions, for both renewable and non-renewable subscriptions.
Maybe you could make your in-app UI look as if the user is signing up for a long-term subscription, but behind the scenes, your app only sends a 1-month non-renewable subscription request to apple. Then, each month, your app automatically requests another 1-month subscription, and another... just skip the months you want to skip.
The user fills out the subscription form in your UI 1 time. Your app logic remembers how many times to start a new 1-month subscription.
Related
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.
A question regarding in-app purchase auto-renewing subscriptions:
I'm unclear how to handle the case where a user purchases multiple subscriptions of differing durations. It seems that Apple will recognize if the user has already purchased a given SKU (based on product-id) and prevent re-purchasing (my app gets a failed-transaction event in this case), but if I offer the same content using different product-ids having different durations, then the user can potentially purchase twice or more.
Even if I hide the additional purchase options once the user has subscribed once, they could potentially buy another subscription on an alternate device, and that purchase would/could ultimately be restored to the other device already having a subscription.
Am I supposed to track purchased subscriptions by transaction-ID and product-ID, and calculate an ultimate expiration date? That seems complicated.
Before I proceed, please see the comments on this linked post on why it may be a bad idea to use auto-renewing subscriptions.
Stop me if you've heard this before.
When you choose Auto-Renewable Subscriptions in iTunes Connect, you are given the opportunity to add multiple durations, with different Product ID's to one subscription Family. Apple won't allow a user to purchase multiple, overlapping subscription durations within one family. (If you're using multiple families in your app, please explain the reasoning, so I can give you guidance based on that).
In fact, Apple won't let the user stack different durations of a subscription within one family.
Here's an example.
I (as a user) download the hypothetical Acme app and subscribe with a 1-month subscription. If I do nothing, my subscription will automatically renew at the end of the period with another 1-month subscription. And so on.
But instead I go back in and purchase a 6-month subscription. Apple will tell me (with an alert) that my 6-month subscription will begin at the completion of my current 1-month subscription, and would I like to proceed. If I say yes, Apple will make note of it, but they won't charge me until my current 1-month is up.
Now if I go back in again and purchase a 1-year subscription, then again Apple would respond with an alert telling me that it will begin at the end of my current 1-month subscription. It won't get added to the upcoming 6-month subscription. It will replace it.
In Summary
So a user can only have one Current subscription and one Upcoming subscription (within a family. This is why you use a Family of product durations within a subscription. If you create multiple subscription families then they can exist simultaneously, and you loose that protection.
If, as a developer, you'd like to manually extend, shorten, cancel or stack subscriptions, you should be doing it with Non-Renewing Subscriptions. And if you read the link I posted at the top, you'll realize that Apple may force you to do that.
try using MKStoreKit 4, it has support for auto renewable subscriptions http://blog.mugunthkumar.com/coding/mkstorekit-4-0-supporting-auto-renewable-subscriptions/
Please consult Appstore Subscription page for latest information https://developer.apple.com/app-store/subscriptions/. The gist is to use group to define multiple subscription channels
Creating Subscriptions
Users can only buy one subscription within a subscription group at a time. If users would want the ability to buy more than one type of subscription — for example, to subscribe to more than one channel in a streaming app — you can put these in-app purchases in different subscription groups.
Upgrades, Downgrades, and Crossgrades
When a user upgrades to a subscription of any duration, or crossgrades to a subscription with the same duration, the service level change goes into effect immediately. When a user downgrades to a subscription of any duration, or crossgrades to a subscription with a different duration, the change goes into effect at the next renewal date.
Having a similar issue. Had an app approved with two subscription groups (for annual and monthly). They are auto renewing subscriptions. We have hundreds of users and they want us to change by deleting subscriptions groups and create a new one. Is it possible to create a new group and move existing products to that? Not sure what to do here and what happens next.
In an app that is free, but has in-app subscription purchases I would like to allow a user with a paid subscription to receive x number of free months on top of the paid subscription if he refers someone that purchases a subscription.
For this to work it would have to be possible to track some sort of unique token through the Apple App Store in order to reliably assign credits.
To "Refer a friend" the app would allow the user to send an email to one or more people. This email would contain a link to the app store that also contains a unique key that I would generate to track the lead.
Is this possible?
Our app just got rejected yesterday regarding this kind of functionality.
We had an application which includes yearly subscriptions to access premium features. We also had a way for users to refer 5 friends to get a free access for life to our services. Apple rejected the app stating that this was against their rules for IAP.
Specifically, they referred us to the section 11.1 of the guideline which states :
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
Unfortunately, apple doesn't offer that functionality. One option is to offer 2 different subscriptions - paid and free.
Hide the free subscription portal until they refer someone - then allow them to see the free subscription option.
A couple problems:
The user will have to manually cancel auto-renew on their current paid subscription and then manually sign up for the free subscription.
I don't think you will be able to disable auto-renew on the free subscription option, so it would probably end up being permanent.
You could skip the free subscription official IAP and just make your own time-limited "back door" letting the customer continue downloading subscription content without verifying their App Store receipt. This would still have problem (1) above with the customer needing to manually cancel their auto-renew and then repurchase the subscription when their free time runs out.
My gut tells me this is going to be REALLY hard to pull off in a satisfactory way.
It would be much easier to reward one-time exclusive content for referrals. E.g. Give X for the first, Y after 5 referrals, Z after 10 referrals, etc. This is actually an easier value proposition to present to the users too; make a nice icon or something with an "Invite Friends to Unlock!" call to action.
I have an app that I plan to introduce soon, but I still have a couple of questions even after reading everything I could find. Maybe I'm just missing the obvious. The App requires a service subscription, because of the server monitoring and analysis required in the background.
I'd like the original App purchase to include a one year subscription to the service and then allow the user to renew (preferably I'd like to use the auto-renew option) towards the end of that period.
Can I just note the in the iTunes Store App description that the purchase includes a one year subscription, then prompt with a renewal notice after that period?
I've seen some comments about offering the App for free with limited usability, then doing an In-App Purchase, but I'd like to avoid having customers downloading the app, going through the initialization steps, but then not subscribing.
Any suggestions will be appreciated.
Can I just note the in the iTunes Store App description that the purchase includes a one year subscription, then prompt with a renewal notice after that period?
Yes.
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.