I have an iPhone app with an in-app purchase and I want to be able to release the app independently from it (the in-app purchase). In other words, there could be times where the in-app purchase is "waiting for review" state and shouldn't be displayed by the app.
If I understand correctly, in this situation, the SKProductsResponse object (returned by the Apple App Store in response to a request for information about a list of products) will have the particular product listed under the invalidProductIdentifiers array. Thus, before displaying the in-app purchase, I could inspect the array to check for the existence of the product. This should still allow Apple to test the in-app purchase with the released version of my app since I assume their testing is done in a sandbox where all the in-app purchases are valid.
Is this correct? Should I follow a different approach?
You describe the proper workflow for displaying IAP content to the user. Put up a modal dialog or a UIActivityIndicator telling the customer that IAP content is being downloaded. Use the productIdentifiers that are returned to populate your store gui.
I discourage you from hard coding in a specific view for a specific in app purchase, and then attempting to populate that view. You can do that if you're smart about it and check for valid content ahead of time, but checking after the customer is already expecting to see something can end with both Apple review and your customer thinking your app is broken.
The least pretty implementation would be a tableView displaying the returned productIdentifiers and their respective prices, allowing the customer to pick from a familiar list.
Related
To be clear on my question, I am in the process of implementing a iOS IAP receipt validation (consumables) and I was not expecting more then just the item(s) the user 'currently' purchased in the 'current' transaction.
So lets say the user purchases one (1) $0.99USD item that gets them 100 coins I am expecting to see in the receipt using my validation code the one (1) transation detailing the one (1) product they purchased not an array of items from previous purchases which I found out that:
With iOS 7, Apple started using something they call the “Grand Unified Receipt”. Apps retain one receipt that contains information about the purchase of the app itself, as well as IAPs.
So my question is if anyone else has an issue with the receipt format and how have everyone been validating the purchases for consumables when the entire user purchase history is always present?
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.
Have any of you implemented something similar to the below scenario?
Consider an app which provides audiobooks:
The books are maintained dynamically from a web based UI by the authors.
The books become available for users of the iOS app, as in-app purchase items.
By default Apple guidelines suggests using non-consumable IAP, and adding continuously as many IAP items as many books we have. But this is not proper for us, as the authors won’t have access to iTunesConnect, so it cannot be dynamic, “self-serving”.
Therefore we are planning to create a set of generic "consumable" IAP items like “Book worth $0.99”, “Book worth $1.99”, and so on. Then in the app we’ll show the corresponding IAP item for the books as specified by the authors, when they added it to our system.
Of course we store the purchased items on the server side, so the user will always have access to the purchased items -- even if they access it later from another device.
Will Apple approve this implementation?
Does it fit with their IAP policy?
I’ve found some similar quite old topics in the forum but the answers were confusing.
Have you implemented something similar and get approval from Apple?
Apple has accepted our solution, as described in the question.
The point is, as highlighted correctly by #RomOne and #ge0rges that you need to provide the possibility to restore the items later.
As we are storing every purchase in our database, and our users are authenticated (they need to register and log in to purchase), we are able to provide them access to the purchased items forever, even when accessing the app from other device.
We are also storing the associated in-app-purchase's ProductID from iTunesConnect, plus the userID, the price, and the date, to have a detailed register of all purchases.
Important: Apple has rejected our first solution, because they didn't understand how it works, and how a purchase can be restored.
The key to success was describing in detail how the system works and providing a test user access to our web admin site. This allowed the Apple reviewers to see the whole system.
Yeah in my point of view they will accept it. As long as you allow users to retrieve their purchases later on. Your system make me think about a virtual currency I have made where I had to make generic consumable that needed to be actually saved for the user. Apple approved it (and still does) because I was saving all purchases, even if it didn't fit perfectly with IAP policy ;)
The key here is to make sure these purchases are restorable, always. So make sure to store the "IDs" or however you identify the different item in a way that is associated directly to the Apple ID (not account, but Apple ID).
I'm trying to add purchases to my application. But I don't know how to check if purchase is already bought. As far as I understand when somebody bought purchase I need to store this into UserDefaults or KeyChain and then check if it is already there (it mean that this purchase is already bought). But what about when user bought this purchase prom another device?
I have code that give me information about all purchases in iTunes.
func productsRequest(request: SKProductsRequest!, didReceiveResponse response: SKProductsResponse!) {
}
Response object have two variables: "products" and "invalidProductIdentifiers". But as I understand products contain all products from iTunes and invalidProductIdentifiers contain all identifiers that I was asking to check for but Apple can't recognise them. So where I can check if purchase was already bought or not.
Assuming iOS 7+, you should be validating the receipt, ala A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7 to determine what's purchased, what's valid (in the case of subscriptions or consumables), and as noted in the other comment, offer a "Restore Purchases" UI element which allows users to cleanly propagate sharable purchases to a newly restored/acquired device.
AFA the response object, that is catalog (purchasable items) information, not info on what has been purchased. In order to have IAP work correctly, assets are to be approved by Apple similarly to the app itself as well as being under "ready for sale" control of your own in iTunes Connect. For that pass, you send Apple a complete list of the times you want to offer and Apple returns to you the list split into the "if your user tries to buy this, they will succeed" (the products) and "if your user tries to buy this, they will fail" (the invalidProductIdentifiers).
When you're testing with sandbox/iTunes Connect Test users, your products do not need to be approved by Apple, but for production code they do.
When a user of an iOS app purchases a non-consumable item, then installs that app on a new device, it is possible for them to again go through the standard purchasing logic for that item. The app store will ask them if they wish to spend $0.99 on the item, but if they click "Yes", it will inform that they already own that item, and ask if they wish to download it for free.
I would like to track new purchases in my analytics, and not have them conflated with re-purchased items that a user receives for free. Unfortunately, it seems that this behavior is indistinguishable from a genuinely new purchase, (to the client app). Apple seems to say as much: "Note: If the user attempts to purchase a product that’s already been purchased, rather than using your app’s restoration interface, the App Store creates a regular transaction instead of a restore transaction. The user isn’t charged again for the product. Treat these transactions the exact same way you treated the original transactions."
In discussing this issue, most posts (and Apple's documentation) say that I should offer a 'Restore Transactions' button to the users. I do offer this button, but it is always possible for users to circumvent this logic, and go through the traditional purchasing route. This is where my tracking will become inaccurate.
Do I have any options? Thanks!
I am pretty sure you don't have any options for tracking a new purchase versus downloading a previous purchase for free when a user does an in app purchase. I have looked into this for the same reason of analytics and I could not find a way to do it. IAP is set up to make sure that you honor purchases made by the same iTunes account on other devices.
If your users are required to have an account specific to your app to make a purchase you could use that to know if they already have made the purchase or not. But requiring an account for purchase can lower your conversion rate.