I am having the below concern when implementing auto-renewable subscription - in-app purchase inside my app.
I am finding the difficult scenario on offering the poems under auto renewable subscription.I have referred this url.By reading this i am got confused that whether i can offer poems via Autorenewable subscription or not?
Please let me know.
Whether Apple lets you do auto-renewing subscriptions or makes you do non-renewing subscriptions is less about your content and more about how it is delivered. I assume you have already read the information in the iTunes Connect Developer Guide. You should also watch the WWDC Video from 2012 about Supporting Subscriptions (it is 308) and it will give examples about when to use what kind of subscription.
I have recently done an app with subscriptions and we were initially rejected for auto-renewing and told to use non-renewing subscriptions. As best I can understand, you will use auto-renewing if you are creating original content on a set, regular basis and have built your app so that there are logical units (like a monthly newsletter or magazine). In my case, the user was subscribing to a series of blog entries that are updated every few days. However, the entries are presented in a single table view listing sorted by date and not separated into any kind of daily or weekly units.
Again I cannot tell from your question how the poems will be presented, but my suggestion would be to review the above documentation and if you are not 100% sure that you clearly fit into one of the auto-renewing subscription categories, submit your app with non-renewing subscriptions.
Related
Is there some new subscription mechanism requirement on iOS? So far we handled the subscriptions without involving Apple, but this (https://developer.apple.com/appstore/in-app-purchase/subscriptions.html) is saying something different:
If you offer auto-renewable subscriptions, you can also use other
methods to acquire digital subscribers outside of your app. You can
sell digital subscriptions on your website or provide free access to
content for existing subscribers. In these cases there is no revenue
sharing since Apple was not involved in the transactions. Developers
keep 100% of the revenue. If you would like to make a subscription
offer outside of the app, the same (or better) subscription price must
be offered inside the app for users who wish to subscribe from within
the app. In addition, you may not provide links in your apps which
allow the customer to purchase content or subscriptions outside of the
app.
I understand the In-app purchase is mandatory for one-time payments, but so far we were not forced to offer subscriptions over In-app purchase mechanism...
BR
STeN
My historical understanding as well as my understanding of that specific text is that, yes, they require you to offer the IAP subscription inside your app since you're offering it outside as well. I think you've just gotten lucky so far that they haven't noticed.
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.
We want to sell digital content through subscription model in our app. Is it possible to support a subscription bundle? Let's say content in question is magazine subscription for $0.99 a month. Is it possible to support a bundle of subscription such that user can subscribe to any three magazine by buying a bundle for let's say $1.99? Or is it possible to support eat-all-you-can model - $3.99 for subscribing to all magazines in our app?
According to the official documents from Apple, yes you can. What you need to do is design your iAP store and items according to Apple's requirements.
Getting Started with In App Purchase
on iPhone OS (Version 2.0)
...
Subscriptions
Subscriptions and subscription
renewals to content or services can be
offered to customers for purchase. You
can offer customers the opportunity to
renew their content or service
subscriptions using In App Purchase,
but be sure to define a reasonable
renewal frequency to avoid bothering
users with unwelcome reminders. Be
aware that you are responsible for
both tracking subscription expirations
and for renewal billing; the App Store
does not monitor subscription duration
and does not offer an automatic
billing mechanism. Be sure to indicate
when an item is a subscription when
entering its product information into
iTunes Connect.
Both of these features are supported, they are called consumable and non-consumable in-app purchases.