I'm developing a chat application. I have a different content that users can buy. But $0.99 is too high price for it. I want to provide some local currency (diamonds / coins or something like that). For example, user can buy 100 coins for $0.99. Therefore, he can buy something with this 30 coins, then buy another one for 10 (for example).
Can I do it?
Of course I can (technically), but will I get the rejection from the AppStore later?
There is an application Line. For Android, it has its own internal currency. But for iOS, purchase content only for real currency.
You can do this. Lots of apps Uses this technique for motivating users for in-App Purchase. But all the updations upon coin expenditure should take place on application level (and your server if you are using server)
And coins only purchased from in-App Purchase
There are a lot of apps that provide its own "currency", for example some games can sell you coins, and with this coins you can do some other things.
The only thing you have to be careful with is that those coins are only bought inside your app trough In-App purchase. If they are not, Apple will reject it.
Related
I am developing an iOS app and i want to sell that app to certain amount for example 100$ so is there any limit to sell or no limit and i want to sell products from my app so i am using in app Purchase so here also is there any limit can any one please answer me waiting for your positive response thank you.
There are a couple of points apple wants you to keep in mind before you go for selling through in app purchase.
It should be a digital content that you give away or unlock for the user upon purchase like the full content of your app, or more levels in a game, more ammunition, subscription to the appstore etc.You can't sell like a gym membership, or any physical product using Apple's in-app purchase.
There are specific price tiers to which apple restricts you to sell. You can find a complete list of them here.
https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/ng/pricingMatrix
However, You can sell items by including payment gateways like ccavenue, stripe, paypal, and sell whatever you want.
i want to build the app and it has consumable in-app purchase feature.
Users can buy coins (consumable in-app purchase), and spend their coins to buy some virtual goods.
The question is, can i build my own store for them to spend their coins?
Every item has each price, users tap on it to buy and pay with coin. All those items on this store can be remote updated online by me, i can change the price, data, add new item every time i want.
So will it fit with Apple policies? Or each item on my store have to be approved by Apple?
And if it works, when user switch the device (change their phone) , how can i do the restore purchase feature?
AS long as your user buy coins, what he does with it is not the matter of Apple. A good example is Free-2-Play games like "Clash of Clans". You only have to create an inApp for each pack of coins you want to sell.
In short, you have to store the coins credit of each user on server side and restore it when your user is authenticated.
If you need a simple solution without any server of yours, I recently used Parse (parse.com) that let you have a database without having your own server.
I am implementing ios app in which I want to add In-App purchase (IAP).
I want to use in-app purchase for below situation:
1) User will make registration and pay $10.
2) Now, my app will allow user to download songs. (For ex. 10 songs of $1. So user can download 10 songs.)
3) User can add more credit by again making purchase of $10. (So if user wants to pay 2 times then he/she will get $20 in his/her account. And he can download 20 songs of $1.)
4) While downloading song, my app will check whether user has enough balance or not, then only he can download data. (If there is no balance then it will ask to make payment of $10 first.)
I have make research for above situation and also looked into in-app purchase guidelines from Apple.
From that, I come across below:
1) If I will use subscription: But in that case, user will be charged after some duration (for ex. monthly payment, 3 month payment). Which I don't want. Because I want user to pay only if he wants to download data and not have balance. So I think, subscription is not ideal.
2) If I will user Consumable in-app purchase: Here, I can use it, so user can pay as many times as he want. And I need to track his balance from server side. So, from server APIs, I can check user's balance. But I think, it may conflict with Apple rules.
"Consumable items are the one exception to the requirement that your content be available on all the user’s devices. Consumable items are digital items that are used up or disappear after use and can never be reused. Examples of consumable items include virtual poker chips, in-game ammunition, or virtual supplies such as construction materials."
So, user can make payment from his iPhone device. And he can download songs from his iPad device as well. Means, purchase is sharable.
But,
Consumables are device-by-device items, so their purchase needs to be made with the understanding that they are tied to the specific device. Apple does not let you restore a purchased consumable. You should warn your users that consumables are not shareable, and make it easy for users to purchase smaller blocks of items.
So can someone helps what kind of in-app purchase is suitable for above and also according to Apple Rules regarding in-app purchase.
Thanks in advance.
User "Non-Renewing Subscription" should fit your requirement https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/CreatingInAppPurchaseProducts.htm
In my iOS app, photographers can upload photos and other people can buy a digital copy of the photo. After researching, I discovered that buyers must use In-App Purchase rather than Apple Pay because In-App Purchase is for digital goods, while Apple Pay is for physical goods.
I've run into a problem with using In-App Purchase to buy user generated content. The documentation says:
For each app, you can create up to 1000 separate In-App Purchase
products. Every product you want to offer in your store must be
configured in iTunes Connect.
My community of photographers will be creating more than 1000 photos.
I, the app developer, must go into the iTunes website to submit each individual product. This is not scalable for a user generated app.
The documentation of In-App Purchase makes it appear that I can only set up a small static list of products. If anyone has experience with letting users purchase over a thousand user-generated digital goods, please let me know.
Possible Solution
I'm thinking about creating In-App items based off of a price tier:
$1 Photo
$5 Photo
$10 Photo
etc...
I'll only let my photographers sell photos within a static price tier. Does anyone know if creating items based on price, rather than what is actually being sold, will be approved by Apple?
Very interesting question! In my opinion, you should go more with physical-style purchases. Why? In-app purchases are designed for buying functionality of an app and ready packages, but not particular photos. The good solution for this will be to sell "bundles" or create an in-app currency. For example, you can sell bundle of 10 photos and user can spend them on photos. But no tiering here.
If you decide to create an in-app currency, e.g. points, you can sell point bundles for some money (e.g. $10 = 100 points, $50 = 700 points) and then let users set the price for their photos. It is pretty obvious, that you can take some extra from each purchase of the photo or when user decides to withdraw in-app currency to real money.
This technique already works in games and in this dating app: https://coffeemeetsbagel.com
The only thing you should care is the implementation of in-app currency "buyback". As far, as I know, there is no way to sell it to Apple again, so you need to set up custom backend for the billing.
If you go with your idea, you can use the same approach, as I described, but instead of currency, users will buy tiers. And then spend "one $10 photo coin" on one photo. But the idea of currency is better as for me.
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.