The service is for a digital option within the app but users are to be billed on a monthly basis, based on the activity they have actually made.
How do I make sure my app isn't rejected?
If you think to bill the user after the monthly usage of the service, you cannot do that. In App Purchase is a form of payment in advance, so you can ask the user to pay initially for a certain amount of service (e.g.: use the service for N hours) and then decrease the number of available amount until it reaches zero, after that the user will be requested to purchase a new amount of such a service to continue to use it and so on.
You can do that using In App Purchase "consumable" in apps. But the user should buy the items before and not after the usage of your service.
Of course nothing prevents you to give some "credit" to the user and then ask the user to pay back this credit using in app purchase. This is closer to what you need but of course nobody can prevent the user to delete and re-install the app to reset his/her credit.
Another possibility is for you to introduce in-app subscriptions: but they are based on time, so you can ask for 1-week or 1-month service, but you cannot control the amount of service used in this month (in theory you could add a monthly cap, but I'm not sure this would be accepted by Apple as the idea behind subscription is that you pay for full usage in the subscription period).
Related
In iTunes Connect it is possible to give a free trial period for autorenewable subscriptions.
App > Manage In App Purchases > Subscription Basic > 1 Month > Offer a free trial?
How can I get this information on the client? SKProduct does not have any information about this as I can see. Since we're having a marketing campaign it is very confusing for the end user to not see information about the product has a trial period.
Of course it is possible to fetch this kind of information from a server I maintain, but then we'll have the overhead with updating both our server and iTunes Connect. So I don't accept this kind of answer unless it is wired up to retrieving that trial period information from Apple's services.
TLDR; It is not possible. You need to manage this information yourself.
When you process an SKPayment you get back a receipt. You should verify those receipts regularly for subscriptions (e.g. before downloading new content) as the user might have cancelled the subscription. When the user does cancel the subscription or the subscription expires you get back a descriptive error when verifying the purchase's receipt.
Moreover the receipt gives you all the information you need: for a given product you know which trial period you grant. Therefore when a purchase is made you could store the purchase date given from the purchase receipt in your model object or in the NSUserDefaults or in the Keychain alongside the purchase data. At this point you know when the trial is expired and verify that the subscription is still valid. If you can't you might want to disable access to the content until you're able to do so.
For more informations about purchase receipts and subscriptions check out the In-App Purchase Guide by Apple.
On the client side you usually identify the different products and characteristics by their product identifier as the App Store does not deliver certain information such as subscription period and free trial period.
So if your product ID is for example:
com.domain.app.product_paid1month_free7days you split the ID on the client side and know that the paid subscription duration is 1 month and the product has a free trial period of 7 days.
Of course one approach would be to transmit the product ID to your own server to get its characteristics as response. This way you can maintain the product list continuously without updating the binary and across versions.
SKProduct > introductoryPrice
Available since iOS 11.2
https://developer.apple.com/documentation/storekit/skproduct/2936878-introductoryprice?language=objc
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.
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.