Right first of all I have tried all kinds of tutorial but they only show how to get the purchase information and display it as a tableview then get the purchase to work, plus this is only for non-consumable or one consumable. As per the image above, I have created this in the XiB and would like to just initiate the consumable purchase when the user taps the button. I would not like to get the purchase info from iTunes Connect then display it as I am already displaying it offline.
I have created the App ID and the App in iTunes Connect and have created 5 in-app purchases. (as per the image below.) I would like the buttons to call for each of these. Does anyone have any suggestions?
I have no experiense in working with consumable purchases, but I don't think there is a large difference. I hope, you've already read Apple In-App Purchasing Programming Guide: http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008267-CH1-SW1
So, what is your problem? If you need to show multiple products in one viewController, you need to take somewhere a list with productIdentifiers (strings, unique for each product in you app at iTunes) for each product. You can hardcode these productIdentifiers, or, better, if you are using server, request them (because, if you hardcode your productIdentifiers, and then add/remove/edit product and it's productIdentifier changes, you'll need to publish a new patch for your app).
To show actual information about each product (price, name), you need to request it. You do it by creating SKProductRequest (for each product) and adding it to your paymentQueue. You'll get price in response. If you don't - don't even show that product in your viewController, because it's something wrong with that product.
To show the products offline you can implement some cache. May be it looks nice, but does it make sense to show "Buy" button if you are offline?
Probably there will be some kind of cell for each product in your viewController. In that case, that should be not a problem to determine, which productIdentifier to use, when user taps on some of the cells.
What to do after that? IMHO it's nicely described in Apple's guide.
If you need more help or some more specific questions - please, comment my post, or edit your question.
P.S. Be aware: in iOS 7 there are some number of changes in working with in-app purchases. Anyway, you can find all information at http://developer.apple.com/library/ .
P.P.S. Check this post: https://meta.stackexchange.com/questions/182266/how-much-research-effort-is-expected-of-stack-overflow-users/182380 . I hope you know, what I mean :) You can try to find some help at #iphonedev # irc.freenode.net , for example. And search and search again. Good luck.
You need to get product information via SKProductsRequest, because you need and SKPayment instance to make a purchase, and SKPayment can be created only with existing SKProduct, not just productIdentifier string.
You can use local cache to show prices to the user even when he is offline, but Apple forces you to get product info every time user tries to purchase something.
Taking product info is not a problem, anyway.
How to store a set/array of productIdentifiers? Read my previous answer.
Related
I want to know that in iOS is that possible to change type from Auto-renewable to Consumable Or vice versa , after product configuration completed and tested with sandbox user?
Any help will be appreciated.
Thanks
Short answer: no, you can't.
Here is the Apple documentation about it: Create an in-app purchase.
If you really need to change the In-App Purchase Type, you have to add a new In-App Purchase in AppStore Connect and set the right configuration for it, then remove the old one.
No, you can not.
It lets you change the product prices without updating the app, but those you setup in the console are final.
You may create other products at any time, they would have nonetheless, a different ID which you may be required to update depending your Apps needs.
In a nutshell, prices and features, you can. The nature of the product itself you can not, 1$ to 3$ is OK. Consumable to Non-Consumable Nope.
I quote Apple:
Before you start coding, you need to configure products in App Store Connect for your app to interact with. As you develop your app, you can add and remove products and refine or reconfigure your existing products.
Products are reviewed when you submit your app as part of the app review process. Before users can buy a product, it must be approved by the reviewer and you must mark it as “cleared for sale” in App Store Connect.
Therefore, it's a sticky and cumbersome process, no changes allowed.
I hope I helped, if you need any further help please comment. Good luck!
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 implement the in app purchase mechanism for my app and have a hard time to figure out the right way.
My app provides a service which can be used for as many items the users wants. He can add more over the time as he wish. The service is a yearly service.
From what i understood in the documentations it should be a non-renewing subscription.
The issue is that let's say a user bought the service for item A.
After a week a wants to add a second item to the service,item B. Then when he buys it ios pops up a window and says he already bought it and asks if he wants to renew.
This window isn't correct ! he hadn't bought the service for item B but for item A. This would confuse my users very much and i really need to avoid this.
I've looked and found also no solution to switch subscriptions, for example between a product called "Manage 1 item" to product called "Manage 2 items" which could have been a solution.
Another solution would be to create multiple in app products with the exact name and description and manage which one to buy from within the app. Would that be ok with apple ?
How should i handle in app purchase for my application needs ?
Thank you,
Tom
First of all, have you read iOS In App guide? This should be first stop for you. Secondly, you cannot have two In App products with the same id, so I don't get why adding second product would prompt user about already purchased product? Could you clarify that? In general, if I buy your product, you should keep data about my purchase and i.e. block this feature, so I it will be enabled once again only when I cancel subscription/my subscription expired.
Not sure about non-renewing, but it seems quite fit for situation, I guess. You can always consider buying consumable and store somewhere information how long you enable some features. Plus, when user buys a subscription he/she cannot get money back (except few scenarios, like mistake), so once you decide you don't need it, you cancel it. This way you can detect in receipt if product expired or not, but user cannot just swap in middle time from one product to another.
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.
I need to set a global variable when a user makes an in-app purchase. I could use NSUserDefaults, and just have a key called "Purchased", but that doesn't seem very secure.
What is the best way to securely store data so that I know whether or not users have made a purchase?
For example in a particular view I need to know whether or not to display a "Purchase" button. Obviously it should be hidden if they've already made the purchase.
For secure data you should use the iOS keychain. Here's the documentation:
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/keychainServConcepts/iPhoneTasks/iPhoneTasks.html
Hope this helps.
There is no need to store that information. There is a method to restore all the user purchases. Look for restoreCompletedTransactions.
You can check all the user's purchases in your view and then show the "Purchase" button for all the items that can still be bought.
UPDATE:
Oh! I misunderstood your question. The above method will get you the purchases the user has made in case of an app reinstall for instance. Regarding your question, it is completely fine to store information relative to the purchased products in NSUserDefaults to give the user the goods, levels or whatever he has paid for.
I recommend this step by step tutorial that helped me implement in-app purchases to answer all your questions.