I'm developing a Newsstand app which uses in-app purchases and auto-renewable subscriptions to unlock and display paid issues of a magazine.
I have access to the database of the magazine's print subscribers and mechanism to identify each one of them with a unique code. I would like to allow people with the code to download digital issues they have subscribed to in print for free. However, I am worried that my app will get rejected from the App Store.
Quote the App Store Review 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
Is allowing print subscribers to download issues they've already paid for a 'mechanism other than the App Store' or a 'system other than IAP'? Is there a best practice to accomplish this without violating the Guidelines? Has anybody solved a similar problem to this?
You should be fine unless you allow these users to register for said code inside your app. That means that you are circumventing in-app purchases and still using iOS to deliver content.
Say you have your own subscription service and people can purchase a subscription through your website. You are within your rights to allow them access to this subscription in the App.
What you are not allowed to do is allow them to purchase a subscription via your website in the App. In this scenario you must use In-App purchases.
Related
I have an app which has some purchase option. However, I don't want to make it through the app itself. For that, I already have a website for the purchase.
So can I create a redirection page from my app to the respective webpage?
Will my app get rejected?
or is there a better solution?
It depends on what you are selling, if you are offering "Physical Goods and Services Outside of the App" you cannot use IAP and must use something else as described in the App Store Review Guidelines
3.1.5 (a) Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
If not then you must use IAP and will be charged a 30% fee. However, if you are offering subscriptions this rate will drop down to 15% for users who have been subscribed for over 1 year. Check out Offering Subscriptions for more info if you are interested.
There isn’t any,
According to Apple’s official guidelines
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. Apps may use in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
You must use in-app purchases and Apple’s official API’s, if it’s not a physical item
Otherwise your app will be rejected
if you want to sell tokens/credits/gold coins/gems or whatever as consumables in a game they also must be through In App Purchase. Meanwhile for Physical elements that we brought from any e commence app that must should go through your requirement.
hope this work
for more info refer this link blog post describing it
Firstly, let me answer your question based on my experience(bad :( ) with Apple
So can I create a redirection page from my app to the respective webpage? - NO
Will my app get rejected? - YES
or is there a better solution? - Depend on types of app.
The In-App guidelines are recently updated with few more changes so it's depends on what kind of feature you are subscribing. For example:
3.1.4 Hardware-Specific Content: In limited circumstances, such as when features are dependent upon specific hardware to function, the
app may unlock that functionality without using in-app purchase (e.g.
an astronomy app that adds features when synced with a telescope).
To be honest, DON'T trust these exceptions and build your app based on this. In our case, app works exclusively based on a connected physical device device. After rejection from Apple, we appealed with this exception but we didn't hear from Apple for more than a month..!
Using subscription through website
Many thinks that they can get away In-app purchase by offering subscription through website and removing t from app. But Apple will still reject your app and confirmed with Apple team. If you are thinking about Spotify and Netflix cases, there is a category of apps it's only permitted called "Reader app". Please refer 3.1.3(a) of Apple guidelines.
Here's a scenario that's not clear to me in terms of whether it's allowed by Apple (even though I've seen other apps that actually do this):
User purchases or subscribes to a web app.
User then downloads related iOS app (i.e., it has the same functions and shares the same data with the web app) and can access the iOS app only by entering their user ID and password from the web app (so essentially the iOS app is free to download but not free to use).
According to the Apple Developer FAQ page for in-app purchases:
"Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected"
"Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected".
"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"
"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"
Does the last point contradict the other three?
Does the scenario I've seen where an iOS app is activated using the user ID and password from the developer's web app fall under the first three points, or under the fourth point? Why?
I presume it's also possible that the apps I've seen are violations that fell below the Apple radar, because the FAQ page also states the following:
"In general, the more expensive your App, the more thoroughly we will review it."
I'm really having trouble untangling what's allowed and not allowed and appreciate help getting a more clear understanding of these important rules.
I'm speaking from experience here, I worked for two clients who each have an app available in iTunes, Google Play, and on the web. Both apps are monetized from subscriptions which can be purchased with in-app purchases from iTunes and Google Play and via credit card on the website.
Each app from their respective app store only offer the appropriate and allowed purchase method, e.g. the iOS apps only offer in-app purchases from iTunes, they never offered credit card purchases, nor do they link to directly to a webpage to pay by credit card.
Users are required to login and the subscription status (notably the expiry date), regardless of where they purchased from, is associated to their account in the database. This allows the users to access paid content from any device without having to subscribe again with a different payment provider. e.g. The user buys a subscription on Google Play and they can access the paid content in the Android and iOS app or on the web.
Both clients have server-side receipt validation in place which checks the status of the subscription on the expiration date.
Apple and Google seem to have no problem with this and there are many notable examples of apps doing exactly this; spotify and skype are a few that come to mind and they are big players. If your app is rejected for using this same practice then those apps are in violation too.
We are considering incentivizing users to download our iOS app by offering premium content (informational text) to those who download within a trial period, share the app, or redeem a custom code. However, in order to comply with the App Store Review 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
it appears all content unlocking should proceed via the App Store, and especially the In-App Purchase API if any cash changes hands. My questions are:
Is it acceptable unlock premium content for users who meet our (non-monetary) qualifications while displaying a paid In-App Purchase option for everyone else?
Are there any app developers who have dealt with this issue in the App Store Review Guidelines?
Any advice would be appreciated. Thanks.
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 know that Apple has a great way to add monthly subscription IAP's to your app in the App Store, but I have a client who would prefer to use a different service to charge for this subscription that could tie in to their website. Does anyone know if Apple allows you to charge a monthly subscription inside your app via an online credit card processor (like Stripe or Chargify) rather than being required to do so through the app store?
I doubt that Apple would let you do this as you are then circumventing the IAP program. You could possibly redirect the user out of the app like Spotify does, but this could still get the app rejected - a small part of the review process depends on which reviewer you get!
Reference in the app store guidelines:
11.2 (source)
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected