In one of our application, we are going to introduce digital content purchase mechanism with crypto currency. So here are my doubts:
1) Is it durable and achievable?
2) If yes, is Apple going to allow this kind of implementation and accept it to iTunes?.
The criteria is 'if goods cannot be used in the app'. Only then you can use a system other than IAP (including a system like Crypto Currency)
Digital Goods which are ment to be used within the App must be purchased trough In-App Purchase. If you use any other mechanism, then your app will be rejected.
From the official docs
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 use their own mechanisms to unlock content or
functionality, such as license keys, augmented reality markers, QR
codes, etc. 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
Someone has asked similar question on Apple Thread also. have a look at the following thread
Answer on the second question: if you want to implement some kind of purchases in your app you also should follow items from the review guidelines:
From the official docs:
3.1.5 (a) 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.
3.1.5 (b) Cryptocurrencies:
Initial Coin Offerings: Apps facilitating Initial Coin Offerings (“ICOs”), cryptocurrency futures trading, and other crypto-securities or quasi-securities trading must come from established banks, securities firms, futures commission merchants (“FCM”), or other approved financial institutions and must comply with all applicable law.
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.
I am writing iOS client-server game.
Client side:
- server comunication,
- game user interface etc.
Server side:
- logic for game
- responsible for delivering some data and logic for iOS client
- manage payments
- manage user privilages
In my system I have my own virtual currency. User can buy virtual money via payment system.
User can spent virtual money in game. For spending money he builds his own reputation in my own loyalty program. For some level of loyalty he will have some privilages, for example access for other functionality of app.
As I mentioned, server will responsible for payments, using variety of payments system (paypal, sms, etc.)
And now...
I have a question: Can I use in this case any other payment systems without Apple's IAP?
I don't want to use it, because my server manages payments for all platforms.
I would like to make payments in iOS app using WebViews. Is it possible?
Thanks for replies :)
You must use IAP, since you payments are providing functionalities to your game.
From apple review 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 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.
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.
I am developing an app for PDF and downloading PDF, I am using using Paytm - Third party payment gateway for payments on web view. Without using an "In-App purchase", will it affect the Apple review guidelines?
In-app currency is only used inside of your app.
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.
For third party payment.
3.1.5 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 IAP to collect those payments, such as Apple Pay or traditional credit card entry. Apps may facilitate transmission of approved virtual currencies (e.g. Bitcoin, DogeCoin) provided that they do so in compliance with all state and federal laws for the territories in which the app functions.
Apple has no issue implementing payment process in UIWebView but you have to provide very clear explanation of your payment process to get your app approved without any objection.
As per Apple guide lines given below, If you are purchasing physical goods which can be consumed out side of the App, then you can go for other payment gateway, else your App will be rejected.
3.1.5 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 IAP to collect those payments, such as Apple Pay or traditional credit card entry. Apps may facilitate transmission of approved virtual currencies (e.g. Bitcoin, DogeCoin) provided that they do so in compliance with all state and federal laws for the territories in which the app functions.
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.
We sell minutes to call other countries, and we want to allow users to make payments within the app. These minutes have a cost to us from wholesalers. Using in-app purchase will dramatically increase the cost to the user if Apple takes a 30% cut.
1 - "You must deliver a digital good or service within your application. Do not use In-App Purchase to sell real-world goods and services." (Source)
I'm not sure if this applies to me or not. Can anyone shine some light on this?
Only Apple can give you a definitive answer, but the way I would interpret the paragraph quoted below, you have to use IAP for purchasing credits, and you also have to be able to use those credits directly within the app (i.e. make phone calls):
Apps that use IAP to purchase credits or other currencies must consume those credits within the application
Section 11.2 of the App Store Review Guidelines says this:
Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
If the minutes you are selling are consumed by an iOS app (any app, not just the app in which the user buys the minutes), then this rule applies to you.
If you are selling minutes that are added to a calling card that the user physically possesses, then you might be able to bypass Apple's IAP, but you'll have to either submit your app or talk to someone on the review team to be sure.
What you're selling is a digital service - connectivity. Your IAP product is similar to credits in most games in available on the store.
The real-world goods and services they prohibit are things like you'd carry out of a store in a shopping bag, or having somebody carry that shopping bag. They don't allow the sale of tangible things, only electronic. Goods for sale should be transferrable between two different devices.
I don't think you can avoid in-app-purchase for what you're trying to deliver from inside the app.
I think your case is much like Skype iOS app. You will need to go through in-app purchase for your app as the credit will be used to make calls via app to other countries.