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.
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 have developed an app like money wallet (e.g. paytm), where user can request money to each other and transfer money to each others account. with every transaction of user, Admin will get some fixed percent commission.
As app is for one small town only,right now user will have to manually contact admin to load money in his wallet or to withdraw it.
I want to submit my app on iTunes store. I know to use any digital content, services, unlock features we need to use In App Purchase. And for any physical good we need to go with any other third party payment gateway.
So I am confused that will apple approve my app or not. Please help.
Thanks,
First, you never know if Apple will approve or not. The only way to know for sure is to submit and see what happens.
Your description of features sounds like you are probably taking the correct approach.
Its important to use In app purchase for unlocking content/features:
Apps that unlock or enable additional features or functionality
with mechanisms other than the App Store will be rejected
And equally for real world purchases to use something else:
Apps using IAP to purchase physical goods or goods and services used
outside of the App will be rejected
The complete guidelines can be found here https://developer.apple.com/app-store/review/guidelines/#purchasing-currencies
And again, its Apples own words:
This is a living document, and new Apps presenting new questions may
result in new rules at any time. Perhaps your App will trigger this.
I tried to submit using paytm integration sdk, and after that my app got rejected
following is reply from App Store
Guideline 3.1.1 - Business - Payments - In-App Purchase
We noticed that your app or its metadata enables the purchase of content, services, or functionality in the app by means other than the in-app purchase API, which is not appropriate for the App Store.
Next Steps
While the payment system that you have included may conduct the transaction outside of the app, if the purchasable content, functionality, or services are intended to be used in the app, they must be purchased using in-app purchase, within the app - unless it is of the type referenced in guideline 3.1.3 of the App Store Review Guidelines.
Please see attached screenshots for details.
Since your App Store Connect status is Rejected, a new binary will be required.
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
Our app is moving from paid to free, and in the process, moving a key functionality from being included to activating via In-App purchase. Obviously, we don't want current users who paid for the app functionality to be charged again in the In-App purchase for functionality they already had. So on the update by the user, we want to 1) identify current users and 2) make it so they don't see the In-App purchase in the first place, sort of 'faking' the In-App purchase so that the app will appear to them exactly as it did before.
The app does not have a backend, so we have to determine current users from new by examining the saved user data fields for certain values. I do understand that if a previous user has deleted the app from their device that nothing can be done, and I don't mind charging them for the In-App purchase, since they never used the app anyway.
But for those current users who update and assuming we can examine the saved user data and determine that they are current users, what would be a good way to bypass the In-App purchase and make the app look like they already got it, when in fact they never paid for it? Thanks!
Here's what I would do - keep in mind this will take some time:
Set up a server (I prefer EC2) with mySQL on it. Plenty of tutorials about this.
Submit an update to your app that sends the user's UUID to your server.
Wait. This is the hardest part. You'll need to wait until satisfactory majority has updated to your app. That majority percentage is up to you to figure out. It could take months for this to happen.
Make your new, free, app send the UUID to the server.
Check to see if the UUID is in the DB.
If it is, set whatever you would have set when an in-app purchase was made to true.
You have several options:
Free in-app purchase for a limited time:
You would create a free tier in-app purchase content and release an update that somehow makes the user sign up for it. This way, when your user switches devices they can restore the purchase and regain the functionality.
Wait for a period so most people use the in-app purchase content
Change the tiers and release your app as free
Dual versions
Make a demo version of your app. Note this can be rejected by Apple.
Create a file in the filesystem
Make a file in the filesystem and save into iCloud. The app will check for the file and thats how you would determine if the user has paid for the app (or should buy the in-app purchase).
iCloud will synchronise the file between user's devices and it will make sure that whatever device the user uses the app will see the user as 'paid'.
I hope this helps, currently having this problem myself.
We have two targets from the same code. Reason is to be able to localize the icon in the app store and on the device. They have different App IDs, but we was hoping to use the same IAPs for both.
We use Urban Airship to look after the IAPs, but iTunes Connect doesn't allow us to enter the same Product ID in the different apps.
We don't really want to keep different sets of codes and IAPs, so is there any way of getting this to work?
Thanks
No.
In-app purchases require non-wildcarded App IDs (foo.bar.bang, not foo.bar.*).
App IDs must be different.
In-app purchases can only access their own App IDs available purchases.
I suggest you rethink the need for localized icons. (If there is text on your icon, you should definitely rethink it!) Otherwise, genericize the icon.
Possible workaround (i think you can do this): both apps can use iCloud to access shared defaults. Unlock purchases made from one app in the other as identified by defaults.
No you can't use the same subscription as #bshirley mentioned - according to https://developer.apple.com/app-store/subscriptions/
But you can create two subscriptions and sync between the apps so your users will not pay twice for the same thing.
Offering Subscriptions to Multiple Apps
You can offer auto-renewable subscriptions to access multiple apps in your portfolio. Each app must be approved to use auto-renewable in-app purchases and must be published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent auto-renewable in-app purchases in each app offered in the multi-app subscription so that users can subscribe from any app. To avoid users paying multiple times for the same offering, you are responsible for verifying that they are subscribers in one of the apps before showing any subscription options. To do this, consider maintaining an account management system in which users create an account with your business to sign in to each app.