I am developing an iOS app which allows in-app purchases.
The in-app purchases are basically different themes/characters for the app.
I offer the default for free (obviously), and some more paid themes.
I implemented the store UI as a table view.
Now this is the part I'm concerned about: I added a free in-app purchase entry for the default theme. My code can identify the free products when it gets the product list from Apple infrastructure, and I treat the free ones as if the user has already purchased them (UI is set as product was purchased, user can use the theme).
My question: is this behaviour is acceptable by apple reviewers or my app/in-app purchase will be rejected for this?
What is the purpose of adding the free in-app purchase? I don't know much about the review guidelines, but it sounds like the kind of thing they would reject your app for. It would probably be easier to detect the default kit in some way other than a free in-app purchase.
EDIT: An alternative would be to add the default theme to the list after the list is retrieved from IAP. You could create a class that holds all the same information, but can be constructed with either data from IAP or from the default theme data.
I do something similar, and it's been approved by Apple for a long time now. However, for my "free" content there is no actual SKU in the Apple infrastructure. Rather than create a SKU with some 'dummy' price (since you can't make an in-app purchase any less than Tier 1), I just present the free option in the UI as a peer of the purchasable options.
I would worry that if you do have an actual SKU with a price, but you give away that SKU, Apple may reject your product out of concern that you are doing an end-run around Apple payment and depriving them of their percentage of the sale. It's also possible they may not reject your app the first time, but will reject some later version when a more thorough tester pokes around. (Yes, really. I have twice had apps rejected that had had the offending behavior through three or four approved versions. Consistency? What?)
Relevant references:
11. Purchasing and currencies
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
...
11.7
Apps that use IAP to purchase items must assign the correct Purchasability type
from App Store Review Guidelines
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.
For example, having all these 3 models inside one app.
Non-Consumable: Pay once to hide ads.
Non-Renewable Subscription:
Receive premium and personalized content for a set period of time.
Consumable: Buy tokens to use in the app.
Thanks
There are no restrictions (technical notes / review guidelines) that would prohibit you from using all three types of IAPs as long as you provide value to a user, who did not purchase anything. (e.g. your last example might not go through review)
4.2 Minimum Functionality
Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn't provide some sort of lasting entertainment value, or is just plain creepy, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes store. Apps that are simply a book or game guide should be submitted to the iBooks Store.
Source: https://developer.apple.com/app-store/review/guidelines/#minimum-functionality
I tried setting up the different IAPs in iTunes Connect, which is possible. The only limit you will find is a maximum of:
[...] 10,000 in-app purchase products across all the apps in one account.
Source: https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/CreatingInAppPurchaseProducts.html#//apple_ref/doc/uid/TP40013727-CH3-SW10
I have used consumable virtual currency purchases in my game.
The user can use that currency to unlock different types of jetpacks.
Apple rejected the game saying it requires a restore purchase button.
But apple's documentation says that consumable products does not require restore.
Why is apple considering the unlocked jetpacks as non-consumable products?
Following is the message that i have received in iTunes connect.
From Apple
10.6 - Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are
worth it. Apple sets a high bar. If your user interface is complex or
less than very good, it may be rejected
10.6 Details Your app uses intermediary currency to purchase items that function as non-consumable products but does not include a
restore mechanism. Users restore transactions to maintain access to
content that they’ve already purchased. Next Steps Please modify
your app to include an optional user registration feature that allows
users to restore their purchases to all of their iOS devices. We
recommend indicating that account registration is necessary to restore
previously purchased In-App Purchase products, and providing a way for
users to register later if they wish to access this content in the
future.
Should i make a restore mechanism for the jetpacks ?
I am using Soomla and unity3d for iap.
In summary, what Apple are saying is that you must include some kind of user registration / account feature where you are storing the users items on your server.
When they sign in on a new device, they should still have everything they have bought in your game.
It seems that Apple considers these purchases as non-consumable products because they are non-consumable products, no matter how you try to handle them in your app. If you define them as consumables, that means a customer loses them when they uninstall and reinstall the app, buy a new phone and restore their old phone to the new one, use the app on several phones, and so on. In other words, Apple considers your use of a consumable purchase to be cheating.
Your customers would feel exactly the same. If your marketing people try to maximise the flow of money from customers to your company, they should consider methods that Apple and your customers don't consider to be cheating.
Building an iOS App in Swift. Quick question about IAP's I want to implement. Currently, I have my In-App Purchases fixed in my app. Meaning, I would have to push an update to the app in order to change the visible information about the IAP, etc.
Does Apple allow me to store this In-App Purchase data in my cloud(Parse), or does it have to be local? Of course, the IAP's would have to be approved in iTunes Connect, but don't have to be used if they are approved.
My goal is to alternate through different plans without having to go through an entire app update.
I feel like the answer is a big obvious yes, but I just wanted to confirm before I begin coding it all in.
Thanks!
It's up to you to decide where to store In-App Purchases.
Here is Apple documentation about storing in-app purchases data.
How to store product identifiers:
Every product you sell in your app has a unique product identifier.
Your app uses these product identifiers to fetch information about
products from the App Store, such as pricing, and to submit payment
requests when users purchase those products. Your app can either read
its list of product identifiers from a file in its app bundle or fetch
them from your server.
How to store associated content for purchased package:
You can embed that content in your app’s bundle or you can download it
as needed — each approach has its advantages and disadvantages.
Embed smaller files (up to a few megabytes) in your app.
Download larger files when needed.
Personally I want to say that all projects I was working on used remote server for getting in-app purchases data.
You don't need care about app approval in this situation.
Yes, It is possible to store In-App Purchases on the Cloud(Parse).
The in-app purchases for iOS are done through the Apple app store. We do not take a cut or interact with the transaction in any way. We simplify the process of setting up in app purchases, take care of interacting with the Apple server, perform receipt validation to ensure your purchases are done securely, take care of delivering the purchased content through PFFiles if you choose to use this mechanism and also provide an easy to use UI component for use in your app.
if you want to know in detail visit here http://blog.parse.com/announcements/in-app-purchase/
Yes, you can do that using parse in swift(youtube)
and parse doc.
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.