Distributing my app to App Store without using in-app purchases. Isn't a Reader App? - ios

I developed an iOS app for my client which consists of three primary functionalities:
Masterclasses
Clever Closet
Vision Board
I have a website from where you can purchase the masterclasses. So, the Clever Closet and Vision Board are free of charge. You can login with the credentials from the website, but also you can register a new account (without access to masterclasses or external links to payments). Firstly, I tried to use buttons with external redirect to the website, but I found out this is not allowed so I removed them.
Right now, my app was rejected from the App Store submission based on:
Hello,
Thank you for your resubmission. Upon further review, we
identified an additional issue that needs your attention. See below
for more information.
If you have any questions, we are here to help. Reply to this message in App Store Connect and let us know.
Guideline
3.1.1 - Business - Payments - In-App Purchase We noticed that your app includes or accesses paid digital content, services, or functionality
by means other than in-app purchase, which is not appropriate for the
App Store. Specifically: Your app accesses digital content purchased
outside the app, such as memberships and courses, but that content
isn't available to purchase using in-app purchase.
Next Steps
The paid
digital content, services, or subscriptions included in or accessed by
your app must be available for purchase using in-app purchase.
Apps that offer paid digital services and content across multiple platforms
may allow customers to access the content they acquired outside the
app as long as it is also available for purchase using in-app
purchase. See Guideline 3.1.3(b) Multiplatform Services for more
information.
If you have any additional information to provide
regarding the digital content and services in your app and how the
guidelines apply to them, please reply to this message in App Store
Connect and let us know. If there is information you'd like us to
consider in our review of future submissions, please feel free to
include it in the App Review Information section of App Store Connect.
My client doesn't want to use in-app purchases, we are providing purchasing these masterclasses on our website. Isn't my app a Reader App?
3.1.3(a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines,
newspapers, books, audio, music, and video). Reader apps may offer
account creation for free tiers, and account management functionality
for existing customers. Reader app developers may apply for the
External Link Account Entitlement to provide an informational link in
their app to a web site the developer owns or maintains responsibility
for in order to create or manage an account. Learn more about the
External Link Account Entitlement.
Also, I do not want to use the External Link Account Entitlement, so it should be simple. What do you think?

My app was finally approved, because I mentioned that is a Reader App using their guidelines, so I had right about it and regarding the fact that Apple try to force you to use their IAP!

Related

iOS subscription payment

I have a question about apple review system.
I have a website where user can subscribe to different plan through 3rd party (the subscription is linked to user’s account) to access to some content.
I have also an iOS application that not let user subscribe to this plan directly from the app (just an informative message to says user that subscription must be made from my website, and their is no redirection to my websites like spotify do it).
Is the application will be rejected because it’s not use In App Purchase ?
Thank you for answer
You should use In App purchase for this purpose. If you don't, your app might get rejected with the following response from Apple.
We noticed that your app contains a payment mechanism other than in-app purchase for digital content or to unlock features or functionality within your app, which is not appropriate for the App Store. In-app purchase is the only valid in-app payment mechanism for digital content.
Note: Continuing to hide functionality within your app or other dishonest acts may result in the removal of your apps from the App Store and termination of your Apple Developer Program membership and all associated memberships.
Next Steps
To resolve this issue, please remove all external or third-party payment mechanisms and implement in-app purchase to facilitate digital good transactions, including unlocking features or functionality within your app.
If you believe your use of an alternative payment mechanism is a permissible use case, please respond directly to this message in Resolution Center with detailed information.
you may visit it for further information and guidelines.
https://developer.apple.com/in-app-purchase/

Is Apple In-App Purchase required for apps using auto-renewing subscription?

I am developing an iOS application where all payment related things are on existing website, our app don't have any payment related thing in it. A user adds payment details on website and select appropriate plan and can use it on both website and iOS app.
So please tell me that if i have nothing on app for using In-App purchase then it will be get approved on app store or get rejected just because app is not giving them their 30% share?
I need some expert advise...
I just read through that exact section of the developer guidelines, and it confirms that that is prohibited. A recent example of such apps being rejected: apps using Dropbox were being rejected (the Dropbox API had a button that could navigate users to their website to upgrade their account instead of having it take place in-app, where Apple would have gotten a percentage).
A quote from that article:
In case you’re wondering what the reasoning these apps are getting for rejection, here’s what Apple is responding with:
11.13
We found that your app provides access to external mechanisms for purchases or subscriptions to be used in the app, which is not in compliance with the App Store Review Guidelines.
Specifically, your app enables to user to create accounts with Dropbox and Google.
Well that sucks. Apparently at some point when using an app that utilizes the Dropbox SDK, you can create an account for the service if you don’t already have one. At that point, there’s a link to a desktop version of Dropbox that lets you upgrade your account. That’s exactly what Apple isn’t a fan of.
My suggestion would be to make them available for purchase via an in-app purchase, charge 30% more for it (so you make the same amount as if the user made the purchase on the web or on Android), but make the user's job post last for 30% more time. This isn't quite fair for you because, if you make $100 off John for an 30-day listing, you would still only make $100 off me for a 39-day listing (assuming I bought the listing via the iOS app). That said, there is no incentive for me to pay for the listing via the iOS app because I am paying $130 (30% more than John) for it and the additional days.
Best of luck.
http://thenextweb.com/apple/2012/05/02/apps-using-dropbox-are-being-rejected-because-apple-is-playing-hardball/
The link on App Store Review Guidelines mentions:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired
elsewhere, including consumable items in multi-platform games, provided those
items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
I am not sure how Netflix does this. New users cannot signup on iOS App, but can sign up on website, purchase subscriptions and use in iOS App.

iOS App allowing news users to sign up for free accounts

We are a website based service. We do not charge for accounts. We charge for services the user selects to do (such as exporting data). We collect money through our website and store that as credits in our system.
We have built a free app app and have been updating the app.
We would like to provide a user sign up in our app. We are having troubles figuring out if Apple will take issue with that. We understand if we sign up a new account in the app, Apple will take a 30% cut (ala Spotify).
The question is how do they handle free accounts?
EDIT:
Our app currently lets the user charge for services against their current credit balance (such as exporting a file) and have not had an issue with that in 4 years we have been doing it.
EDIT 2:
At one point, they did reject our App for hot linking to our website. That was 3 years ago and I forget if it was because they could create a new accout or could add credits to their account. I can't find a way to go back and look up the rejection notification.
Accounts are unrelated to purchases. Purchases and accounts are often used together, but this is a convenience and not strict requirement.
In your case:
The user may access the app with an account.
No payment is asked for the account.
Through this account, the user may receive content which has been paid for by credit card.
Credit card details have been submitted through your web site.
This is ok, as long as you do not take credit card payments in the app, or provide any buttons or links to credit card payments, from in the app.
According to the App Store Review guide.
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. Apps may not include
buttons, external links, or other calls to action that direct
customers to purchasing mechanisms other than IAP. Any credits or
in-game currencies purchased via IAP must be consumed within the app
and may not expire, and you should make sure you have a restore
mechanism for any restorable in-app purchases. Please remember to
assign the correct purchasability type or your app will be rejected.
Apps should not directly or indirectly enable gifting of IAP content,
features, or consumable items to others. Apps distributed via the Mac
App Store may host plug-ins or extensions that are enabled with
mechanisms other than the App Store.
And
3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or subscriptions (specifically:
magazines, newspapers, books, audio, music, video, access to
professional databases, VoIP, cloud storage, and approved services
such as educational apps that manage student grades and schedules),
provided the app does not direct users to a purchasing mechanism other
than IAP.
In other words, users may access content that has been paid for outside of the app.
If the user is directed by the app to pay for something, then you may not use external payment services, and you must use In App Purchase.
So, hot linking to your web site from your app to accept payments is not allowed, whereas downloading content which has already been paid for through your web site outside of the app is allowed.
If in doubt, contact Apple directly through their support form, or the Apple developer program technical support.

what is the apple review guideline for money wallet apps like paytm?

I have developed an app like money wallet (e.g. paytm), where user can request money to each other and transfer money to each others account. with every transaction of user, Admin will get some fixed percent commission.
As app is for one small town only,right now user will have to manually contact admin to load money in his wallet or to withdraw it.
I want to submit my app on iTunes store. I know to use any digital content, services, unlock features we need to use In App Purchase. And for any physical good we need to go with any other third party payment gateway.
So I am confused that will apple approve my app or not. Please help.
Thanks,
First, you never know if Apple will approve or not. The only way to know for sure is to submit and see what happens.
Your description of features sounds like you are probably taking the correct approach.
Its important to use In app purchase for unlocking content/features:
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
And equally for real world purchases to use something else:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
The complete guidelines can be found here https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
And again, its Apples own words:
This is a living document, and new Apps presenting new questions may
result in new rules at any time. Perhaps your App will trigger this.
I tried to submit using paytm integration sdk, and after that my app got rejected
following is reply from App Store
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app or its metadata enables the purchase of content, services, or functionality in the app by means other than the in-app purchase API, which is not appropriate for the App Store.
Next Steps
While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines.
Please see attached screenshots for details.
Since your App Store Connect status is Rejected, a new binary will be required.

Is iOS in-app purchase not required if purchase or subscription happens in web app?

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.

Resources