I want to sell a tshirt for my app. I have a button that goes to a webview ( my website)
If people buy from my website in a webview, is that considered an in app purchase?
This is not In App Purchase. In App Purchase does not allow to sell physical product, which you need to ship the physical product to your buyer.
Most of the time will be virtual items, e.g. newspapers, book, game levels, music, those can be delivered by "DOWNLOADING"
Apple and Google treat Virtual Goods and Physical goods differently. The good news is that you don't have to pay the 30% toll to use their system. There are many ways to do it either as native code or as a webview. You should also look at pre-made solutions/SDKs like:
SellInApp
Zooz
Paypal
You will need to trap the URL when they click the item in the Webview and proceed with Apple StoreKit to do a In App Purchase with Apple.
Your App will get rejected if you are giving away Digital items from your Webview using your own payment provider.
Related
I know that IAPs can be used only to sell "digital" products.
But I want to offer a subscription in the app, that will both have new features available in the app (more photos that can be uploaded) and a discount on a physical book in my bookstore.
Is it considered as a digital and physical product combination, or just a digital product?
Is that possible to do through Apple IAPs?
And if not, can you plz suggest a way to bypass the restriction?
If I switch to credit card subscription (using Stripe to handle it), wouldn't Apple ban my app for trying to sell both digital and physical product?
Thanks.
Also, in the most expensive plan, I want to offer free shipping of books for those who have the top subscription.
Among the questions that I've checked, this one seems close, but does not give an answer.
You cannot sell physical items through Apple's IAP. If your app provides services outside of the app itself, you can use your own payment processing within the app.
For instance, the Fandango app allows the user to purchase movie tickets through their app. Because of this, they are allowed to handle payment processing for buying movie tickets using their own mechanism instead of Apple's IAP.
I would suggest using Apple's IAP for digital purchases and a third party for physical sales.
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 new to iOS programming and I know very little about their admissions policy applications. I have an application made in phonegap and there is a section where if you click menu, shown inside a shop made an iframe in prestashop. I wonder if the fact of having a store within an app without having to iTunes connect iOS is cause for rejection.
Thank you very much.
As far as I know it depends on whether you sell physical or digital goods.
Digital goods have to be sold via Apple's "In App purchase" (IAP) and are charged with a 30% commission.
Physical goods cannot be purchased by IAP and thus you're forced to provide a different payment method (like PayPal), hence not paying the IAP commission.
So long story short: if you sell psysical goods, your app will not be rejected for providing another payment method than IAP.
For further information please read here: https://developer.apple.com/in-app-purchase/In-App-Purchase-Guidelines.pdf
I am working to develop an iOS mobile app version of an online game that uses in-game coins to enhance game play. Ideally, I would like to sell these coins through both IAP and through the user's account on the web version of the game. I am having a difficult time parsing together whether or not this is allowed by Apple and am wondering if anyone has similar experience.
According to Apple's terms:
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
But also:
11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) 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 not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app. [This last is from an earlier version of the rules, but it still seems to be the case -- I can purchase a subscription to Pandora on the web or through IAP, right?]
I know I can't put a link to the web version in the App, and I can't advertise within the app that they can purchase coins online, but is it possible to sync the two accounts across platforms? Will Apple allow this, or do we need to re-evaluate?
Thanks!
The current top-grossing game, Candy Crush Saga, appears to do this, so that seems to be a good precedent. It can be synced with the Facebook version of the game where items can also be purchased.
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.