We plan to implement all the subscription server-side services. Here is the flow for our client iOS app:
The registered user enters phone number, we check if the number is valid and if it is, the user can subscribe and thus use some features of the app that an user without an active subscription can't. The subscription is not free and it doesn't go via AppStore; the user is charged at the side of his/her provider, based on his/her phone number. The user isn't asked to give any of his/her credit card data. One of the features that gets unlocked when user subscribes is the possibility to download digital content.
The question is: would Apple approve this flow? I know for subscriptions as in-app purchase types, but the plan is to have something different in our iOS app.
And what about promo codes? Is it possible for vip users to use our promo codes in order to subscribe..?
Apple will not approve any purchases that get added to an iOS device, are initiated on the iOS device, and don't go through the app store. You can do purchases through your web site; in that case you will have to avoid links to your website from the app.
On the other hand, physical purchases must not go through the app store. So if you have an app for buying hand bags, you can not get payments through the app store.
Apple will also give you a very hard time if you ask users for their personal information, like their phone number, and if there are features they can't get without giving you such information.
Related
my name is Antony Basta and I am the developer of an app called SecuriKey. SecuriKey allows any old apartment building intercom to be controlled from an app. Users can create entry codes that work once, up to a certain date, or are instantly revokable. There is no need for any new or additional hardware – it works with the buildings existing intercom.
Currently, the app is using Stripe for subscriptions and it was initially approved 2 months ago for the App Store. I pushed an update a few weeks ago and Apple Rejected it because I am not using In-App Purchase (IAP). I submit an appeal, mentioning that we offer a consumable service that takes place outside of the app (guideline 3.1.3(e)), it is effectively a "Reader" app since we provide VoIP numbers to our customers (guideline 3.1.3(f)), and SecuriKey requires hardware to function – that is, it will not work without a physical intercom (guideline 3.1.4). Additionally, we do ship physical goods to our customers (NFC tags and Security Signs) monthly and require monthly service personnel to service the building using the physical goods for our own back end workflow. A lot of back and forth has occurred between the review team and at the time of this post, the app is still being reviewed by the board. I thoroughly believe we fit within all of the mentioned IAP exception guidelines – but that's a conversation for another day.
As I wait, I began to delve into using IAP for this product. I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made, and I am able to create an account and collect a payment. But there's one huge oversight. This is a cross-platform app. Meaning, roommates or family members who use different mobile operating systems, can be logged into the same account. A user may sign up from the iPhone but his/her roommate/family member may have an android that also has access to the service under the same account. Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either.
Has anyone ever dealt with something like this? How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)?
If Apple says you have to use IAPs, you should leverage IAPs and not a payment service provider like Stripe.
I'm confused with what
I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made,
means but does not sound like the right thing to do.
Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either
Your user will have to use Apple's Platform (i.e. an Apple device that they are signed into) to cancel the IAP subscription.
How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)
You can't. Take a look at the IAP experience for subscription services like HBO Max. Accounts are all ultimately provisioned through the same system, but the funding source may differ. When you attempt to manage your subscription, the website or android app could inform you that the subscription is billed via Apple, and send you to a page like this: https://support.apple.com/en-us/HT202039.
If the user has no Apple devices, they can contact Apple Support:
If you don't have an Apple device or Windows PC
You can cancel Apple Music on the web.
You can cancel Apple TV+ on the web.
If you want to cancel a different subscription from Apple, contact Apple Support.
First of all, my app include contents which are only allow to watch or access for membership subscribed user. It include 1 week, 2 weeks, 3weeks, 4 weeks and user have to pay it via other payment gateway which was popular at our country instead of IAP.
I can't use IAP because clients(users) at my country have problem with using IAP services because there is no international credit card services or payment services such as MasterCard,VIZA,etc are not supported as well. Also we can buy iTunes Gift Cards of course. But, compare it to our price subscription list, it is really too much
Here our subscriptions prize and it doesn't include auto-renew
1 weeks subscriptions -> $0.5
2 weeks subscriptions -> $0.9
3 weeks subscriptions -> $1.3
4 weeks subscriptions -> $1.5
So compare it to Apple Store Gift cards $10, that is not possible to use IAP. And at our country, giftcards are hard to buy because there is no Official Apple Store or authorized store.
To explain you about my popular payment gateway, it was like using Apple Gift Cards. It was just purchasing PIN codes from nearest Mini-marts, cafe and other shops. You can see the detail here.
http://reddotpayment.com
At my app, I included internal web view and it leads to reddot page which include textfield for PIN codes. After user fill the pin code which they bought and click subscribe, it can now part of our membership subscriptions. That's how it goes.
But Apple didn't allow and reject my app. They respond me like that.
Guideline 3.1.1 - Business
We noticed that your app 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.
Specifically, your app uses Red For pay to purchase subscription
outside the app.
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 through in-app purchase, within the app - unless it
is of the type referenced in guideline 3.1.3 of the App Store Review
Guidelines.
Was it because I do the transaction outside of the app? I mean even internal web view? What if I make the transaction inside the app with UITextField call to our API for making the purchase?
Any Suggestions?
Only two ways to solve this case.
Use their In-App Purchase
Else try to trick the Apple with Server-side control especially when they are reviewing your app for App Store Distribution approval.
Please note :
Using No.2 might get your app rejected when they detect your app is
using 3rd party payment service instead of their because they want the
money for each subscriptions as long as your app meant for using only
at your country or specific territories not international.
Because if you app meant for using at world-wide like Uber or Instagram, then you are at dead end.
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.
I'm about to develop an app (for iOS and Android) that allows users to create a collection of digital content from their phone (e.g. some videos and pictures), and send that content to other users who can consume that collection on the same iOS/Android app. I'd like to bill users for sending a collection, because this process involves uploading and processing the collection to the cloud (which I pay for) and the recipient's app downloading it again (causing traffic costs). Note that I don't want to charge any money from the recipient!
The way I see it, producing such an iOS app is not possible (because Apple will reject it, see App store guidelines and In App Purchase Guidelines) for the following reasons:
Setting a fixed price for the app ("paid app") is not reasonable, because I want to charge the user each time he sends a collection, so IAP (In-App-Purchases) would be more reasonable
The IAP-logic/flow would be that a user can create the collection in the app for free and then, when he clicks the "send collection" button, he is asked to approve a purchase, in return he gets the link that he can send to his friend. The logic would essentially be the same in the Android app, using Google's "In App Billing"
Such an app could be rejected by Apple because of rule "11.3. Apps using IAP to purchase physical goods or goods and services used outside of the App will be rejected" - because the user essentially paid for hosting the collection, and that collection can be used outside of the app (by an Android app user for example)
OTOH it's also impossible to use external means of payment. For example, I was thinking about forcing users to first create an account on my website, where they can pay for a voucher (with Paypal, say) that enables users to send collections. They'd first need to log into their account in the iOS app and then they might see a warning that they have not yet purchased (or no longer have) any credits for sending a collection. The IAP guidelines forbid me to directly link to my website with a note saying that users can pay for additional credits by other means. When Apple engineers sees that message during review (assuming they aren't putting very bright people in charge) the app might be rejected, too. Even if it were not, this work flow is very uncomfortable for the user, I'd prefer IAP as this also makes accounting (taxes and earnings for my company) a lot easier.
I'd like to get your opinions on this. Please note that I might be "too hard" on myself. As a matter of fact, I do know apps that have been approved to the store that do exactly that, see e.g. here and here. Maybe they have been approved because paragraph 11.3 actually just forbids the ability to purchase the functionality of uploading (converting a collection to a link) and then use this functionality somewhere else - effectively that would mean "to buy credits for an external service" mechanism. My app wouldn't do this. You'd have to do the purchase and the upload/convert-to-link functionality would only work on that device where you did the purchase.
Any thoughts?
I have similar experience with an app i worked on. It was a GPS device showing tracking data in the app. The device uses cellular data to send tracking information and we need to collect a fee to pay the SIM provider which is an external service. We did this using Stripe payment but Apple rejected the app and asked to implement In-App purchase. Because we were blocking the user and asking to pay in the app that looks like we are asking payment for app digital content.
Based on my experience, to answer your question :
Yes you have to use In-App purchase and it can be Consumable type. When user try to send a collection, show a consumable purchase type. Keep track of the purchase in the server using purchase receipt, collection id etc.
Even though the amount collected is used for hosting and web traffic, you can term this as a service fee for managing/sending the collection. Behind the seen, you use this fee to pay your hosting provider or anyone else, that's up to you. Apple won't reject the app for this reason. Because you are charging a fee for digital service you are provided in the app. In apple guidelines, external physical service means, for example taxi charge in Uber, shopping goods price in amazon etc.
This is very common mistake developer often doing while choosing the payment options for any Payment related feature into application. Specifically in iOS there are new rules defined by the Apple for choosing the payment model for your application.
Here are some important points :
If your application having some points system or coins system for which you needs user to pay for than you must use the inApp purchase. And inApp purchase must be of type Consumable. So it will be purchasable multiple times
If your application offering any pro features or facility inside the application you must use inApp purchase. Type will be non consumable. (Note : For Non Consumable inApp purchase you must give Restore Purchase option into your application other wise your application will get rejected.)
If your application is providing any feature or any internal content access for limited time than you must use the subscription based inApp Purchase.
If your application is selling any physical goods than you must use any third party payment options. You can't use inApp purchase for it.
If your application is selling external services or any donation related feature then you can't use inApp purchase for it. This will be a complicated case & in this case according to the apple guidelines you should use the Payment gate way with Webview redirection. So the user will do the payment from the Webview redirected component.
Hope this helps to everyone.
I am stuck with one of the in-app purchase rejection issue in my app and need some help on this.
What this in-app for?
In our app we have options for user to become premium user. A user can become premium user to enjoy some benefits and it is tied to time. There are two in-app products which defines them
One month premium service.
One year premium service.
Since these are time based service, user expects these service should be made available for that user once he/she purchase the product for the specified time, from all his/her other devices. In order to track whether the user is premium service user or not, once the purchase is done, the app writes a entry in server about premium service. So when user uses other device and logs in, he/she can enjoy the premium service without any issues. For this reason I created the above mentioned products as "consumable", thinking that it is controlled by our server there will be no issues. But apple came back with rejection and asked me to change the products to "non-renewing subscription".
Here is what apple says about this
We found that the Purchasability Type for one or more of your In App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
"Premium account service for 1 month and 1 year" IAPs are set to Consumable.
However, based on product functionality, it would be more appropriate to use the Non-Renewable Subscription In App Purchase type because the service offered by your application requires the user to make an advance payment to access the content or receive the service.
The Purchasability type cannot be changed once an In App Purchase product has been created. Therefore, you will need to create a new In App Purchase product with the correct Purchasability Type. To create a new In App Purchase in iTunes Connect, go to Manage Your In App Purchases, select your app, and click "Create New". The current product will show in iTunes Connect as "Rejected".
Non-Renewable Subscription content must be made available to all iOS devices owned by a single user, as indicated in Guideline 11.6 of the App Store Review Guidelines:
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
If you choose to use user registration to meet this requirement, please keep in mind that it is not appropriate to require user registration. Such user registration must be made optional. It would be appropriate to make it clear to the user that only by registering will they be able to access the content from all of their iOS devices; and to provide them a way to register later, if they wish to access the content on their other iOS devices at a future time.
For more information about Purchasability Type, please to refer to the iTunes Connect Developer Guide.
Now I have created new in-app products which are non-renewing. But this works the same way as I mentioned earlier, i.e. the server keeps track of whether user is premium user or not, expiry date. When user goes to other device and does login, the app comes to know whether user is premium or not and based on that app works.
But I have couple of questions on this,
Should I need to provide the "Restore" button in the app? If so what is the purpose and how it works?
Since the user can access this service only after doing login to the app (it is different from app store account). Will these two logins make any issue?
Please share your valuable inputs.
It is highly unlikely that the user will end up in a situation where they won't be able to use your app unless they restore their purchases, however it is still possible. Imagine your server goes down for a day and during that day some user purchases a subscription, gets a new iPhone, installs your app on the new device and then wipes their old iPhone. I can think of a couple of other, equally unlikely, but still possible situations (Apple receipt validation server going down, etc) in which the purchase receipt will get lost in transit. It's best to provide the button, and if Apple thinks that you need it in your app, you will have a hard time convincing them otherwise.
If by "two logins" you mean user having to log in to your system and then log in to the App Store to purchase the subscription, that should not be a problem.
I recommend you make the changes Apple requested to the Purchasability Type and then re-submit. If you need to clarify a lack of a restore button put it in the notes for the reviewer