We have an application that offers audio and video streaming as a separate service and we'd like it to be an auto renewing subcription. The user might buy this service and not use streaming at all, anyway, the service is available all the time the subcription is active.
Now, I have problems to interpret this sentence from the Apple Review Guidelines for auto-renewable subscriptions:
"Apps may only use auto renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage) and media Apps (video, audio, voice), or the App will be rejected."
Would our app fit in this category?
Thanks in advance.
Auto-renewable suscriptions are meant for apps that deliver "periodical" content. Our app just offer the video and audio streaming service on-demand, thus, product should be non-renewable suscription.
Related
Can I do the auto renewable subscription to Apple without issuing any content? That is, the subscription to use certain features on my server.
From the Apple App Store Review Guidelines:
Apps may only use auto-renewing subscriptions for periodicals
(newspapers, magazines), business Apps (enterprise, productivity,
professional creative, cloud storage), and media Apps (video, audio,
voice), or the App will be rejected
Does your App fall into one of those categories? If yes, then you can use auto-renewing subscriptions.
I am developing he application which delivers audio clips as channel basis media over http streaming.
I am planing to use Auto-Renewable Subscriptions in the app and they are renewing on monhly basis as we are updating the contents(Audio clips) of the channel frequently.
I was going through the Apple policy for auto renwing subscription which is,
Definition
Auto-renewable subscriptions allow users to purchase dynamic content, such as magazine subscriptions, for a set duration of time. Subscriptions renew automatically unless the user opts out of the renewal. If the content you want offer doesn’t fit what’s outlined in the App Review Guidelines, consider offering the content through a non-renewing subscription.
Auto-renewable subscriptions can include an incentive to customers who share their contact information with you.
Review Guideline
11.15. Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
Its very confusing which method to use in my app (Auto-Renewing or Non-Renewing)
hense there are different types of thoughts/information shared on the internet.
So, my question is which method is appropriate to my app?
Can my product will get approval or not if I stick to use Auto-Renewable Subscriptions?
Further, if theres any complete tutorial/sample app for auto-renewable subscriptions please share with me.
Thanks
You can use the Auto-Renewable Subscriptions if you are going to change the content on certain time period basis.
But if this thing is going to be stopped in future then this way will not work for you. Any time Apple reject your application if he get complaints from any user.
To avoid this I will suggest to go with the Non-Renewing Subscription in that you are the one who is going to manage everything by your own. Apple will only provide facility to do transaction only. Rest of the things like management of time period will be on your hands only. In this case your application will not be rejected by Apple anytime in future as well.
Refer this link for sample code which manages everything..
We are in the process of developing a Cordova iPhone/iPad application, our plan is to release the app in the store as a free app.
We initially thought we would be able to offer full and free use of the app for 30 days, after which we would ask the user to pay to access the app.
The payment would be managed outside of the app (i.e. Not an in-app purchase), circumventing Apple's mechanism and the revenue split.
However from all the reading we've done around in-app subscriptions and taking payment outside of the app store it appears this may not be possible and we will struggle to get the app approved.
In an ideal world we would:
Publish the app
User download the app
User uses the app for 30 days
On day 31 we ask the user to pay for continued access
User taps a button and pays via our payment gateway
User returns to the app and can continue to use the app forever
We will also be releasing a web app, same functionality and same payment process required.
Im almost 100% sure that Apple will turn us down for this, we are essentially offering a trial of the app and then asking for payment simply to circumvent the revenue split - at least thats how it can be interpreted.
I'm trying to find a workflow (user journey) that would work in our case but also with the app store process.
Thinking something potentially like the Spotify model, where a subscription is required (Username/Password) and then the app is downloaded?
Your original idea is going to get you rejected for sure. What's wrong with offering some of the features through IAP?
From the submission guidelines:
2.9 Apps that are "beta", "demo", "trial", or "test" versions will be rejected
11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
Additionally, you can do the subscription model, but beware of this as well:
11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these purchases, as set forth in the Program License Agreement
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App
Seems like Apple become less strict to that rule. I can't find any mentions like this: "Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected" in current docs.
Here is a new one:
3.1.1 In-App Purchase: If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game
currencies, game levels, access to premium content, or unlocking a
full version), you must use in-app purchase.
https://developer.apple.com/app-store/review/guidelines/#in-app-purchase
Also, Netflix has launched the app with the ability to buy a subscription outside of the Appstore:
https://www.extremetech.com/mobile/276066-netflix-experiments-with-bypassing-apple-app-store-subscription-fees
I have a confusion regarding subscription in the app. I want to upload my app to the app store with some price tier. I want user to pay every month some subscription fee to use complete functionality of the app. I have seen apps that are available as free with subscription but my app will be paid with subscription.
Will Apple reject my app?
I have already asked this question on Apple developer forum. Here is the link:
https://discussions.apple.com/thread/5134928
Looking at the App Store Review Guidelines, the only rule I see that could affect you is:
11.15 Apps may only use auto renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity,
professional creative, cloud storage) and media Apps (video, audio,
voice), or the App will be rejected.
I guess you have to determine if you app fits in one of these categories. I always say that Apple can do whatever they want, so the only 100% way to know if you'll be rejected is to submit it. The review process is much faster than it used to be, so it shouldn't set you back more than a week.
Other subscription-related rules
11.6 Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
That's a straightforward rule.
11.12 Apps offering subscriptions must do so using IAP, Apple will share the same 70/30 revenue split with developers for these
purchases, as set forth in the Developer Program License Agreement.
If you want someone to subscribe within the app, you have to give Apple their cut by using IAP. Otherwise, you need your own website for sign-up, à la Netflix.
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a “buy” button that goes
to a web site to purchase a digital book, will be rejected
When you set up your own website for sign-ups, you can't even link to it. People have to know about it before using your app.
I am wondering what the rules are around using an external payment system (like Braintree) for in-app purchases on iOS. We already run a streaming music service that operates over the web, and we want to develop apps for Android+iOS. It's a subscription service, and we currently run all our payments through Braintree. If at all possible, we'd like to continue to do so.
I'm a little hazy on the exact details of when this is allowed and when it's verboten.
This would allow users to stream full tracks within the app (otherwise all they get are 30-second previews), but it also allows them to use the subscription online and on other platforms. So, would this therefore be an allowable use of a 3rd party payment system by the "law of Apple?"
From the guidelines:
11.1
Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
11.2
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
https://developer.apple.com/app-store/review/guidelines/