I'm new to iOS development.I'm working on a music app that has provision for registered users to sell music (from web) and buy music from app.Means, registered users can upload their music from web side and can put a specific price for that music for others to pay and download.
My doubt is that,when i searched for it,i saw as per Apple guidelines,we can't include any payment gateways like paypal to purchase a function or service within the app.Here i think,i cant use paypal for buying a music of 2$ from app without using IAP.
But there are only a few pricing options available in IAP in itunes.
Then my question is,Is there any way to buy or download music with the price those music owners set for that particular music using IAP or using paypal or other gateways.
The price of music will be different as the one who uploaded it.how can buy those from iOS app.Please do help.thank you.
Related
I need help, working on Music App where user can buy individual Song or full Album. can we offer different payment methods like Apple Pay,Google Pay,PayPal and Cards to purchase that song/album. Will apple approve it? because in their documents they mention to use In APP Purchases (IAP) for digital contents. But here our requirements is to purchases songs/albums using different payement Methods except In App Purchases.
We are handling app Plans subscriptions with In App Purchases (IAP).
My application have video list available for uesrs if user like particular video he can purchase video and once payment done he can download it.
My question is does it comes under in app purchase of IOS ? Can I use pay pal as payment gateway instead of in app purchase ?
If a part of your app is being purchased from within the app, Apple requires that you use their app store to charge the customer. This is an inconvenience for most developers, but big companies like Spotify can have big problems with that. Using PayPal to purchase a part of your application would be grounds for an immediate refusal of your app in the review process.
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 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 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.