I'm walking through In App guide and trying to figure out how to deal with buying multiple products. Let's say I have 3 features available to buy via IAP and I want to have option to select which ones user is willing to buy, then buy all selected at once. Should I create only 3 products (for each feature) or should I create one product for each possible combination of available features (like: A, B, C, A+B, A+C, A+B+C...) ? I tried to google it, but I have nothing so far, not sure if I'm asking good question or what. Can anyone direct me somewhere, some tutorial or advice?
The In App Purchase SDK present only the paymentWithProduct: method which enable only one product as parameter. You may only set the quantity to be more than 1.
If you want to propose package of In-App you should register them as separate In-App on itunesConnect and propose them in your app. But if you don't set a price different than the sum of the separate products, I don't see a real advantage to the user.
Related
I need to create purchase system that allows user to use part of app for limited time (1 month), optimally with auto-renewal. My app is non-newsstand app.
Is there any possibility to accomplish this with auto-renewable/non-renewable subscription or should I use Consumable?
For better understanding, what I want to accomplish:
Lets say I have Facebook app. User want to search for another users, so he buys searching option for 1 month. Week later he want to put more than 10 photos so he buys another option. At this point he have 2 functionally independent options with different end time.
Yes. Set different product identifiers for each functionality you are offering. To those product identifiers based on the way you are offering give it auto-renewable/non-Consumable. You cannot use two options combined. You have to chose based on your requirement.
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.
From my understanding, Windows Phone now allows in-app purchases. I would like to empower my users to signup for one-of-three subscription levels within my app. However, I do not understand how to enable this type of scenario. I see the option to add an "In-app product". However, in my case, I'm not sure of the following:
Am I offering one product or three separate products (one for each subscription level).
I don't understand the "Product Identifier" is this an identifier for the subscription or the identifier of my app? If its the former, shouldn't I just toss a GUID in here?
Thank you,
It may be worth taking a look at the overview on MSDN - your product identifier is the one you submit (as a person) via the development dashboard - it's also the one that your app can enumerate to see the list of available products, and the product id you'd use to purchase.
As far as I'm aware, you cannot have products that are (for example) £10 per month though - of course you could do something like have bundles on a pricing structure that exchange for something within your app, maybe £5 for 5 music downloads, £9 for 10 etc. rather than "a £10 per month for unlimited" (difficult to give a generic example though)
I'm developing an app where the user can purchase digital maps, charts and so on. I'd like to wrap these in in-app-purchases. The thing is that I don't know beforehand how many charts there will be, as I'm getting them from another source from the net. There could be hundreds.
I have a server that periodically gets the charts from that source and stores them locally; there may appear new charts in the future or disappear existing ones. All this without manual intervention.
There are three distinct types of charts.
My first solution was to create three consumable items and let the user buy these; this was working fine but unfortunately Apple rejected it, since they require charts to be "non consumable".
But I'm quite at a loss how to implement what I want with the non-consumable type. If I create these three types as non-consumable, and the user buys one, he will get all the other charts in that group for free, since a non-consumable item can only be bought once.
The only solution I can think of is to create a non-consumable item for every single chart. But that's something I want to avoid at all costs: as it is now, the charts are periodically fetched from the remote source without any manual work on my side. I'd like to keep it that way. I don't want to manually create a new non consumable purchases every time a new chart appears.
Any ideas how to make this scalable?
I can't completely spell it out for you with code but you can handle this problem two ways:
Currency.
You do not sell non-consumable items such as maps. You sell currency. With that currency you purchase maps. The maps you feed dynamically whenever the user hits your store front. That way you only need to track a few purchase options.
The other option:
The company I worked for initially set this up very simply. Our app would launch and we would reach out for a php script that handed us back the app store IDs that we had sitting in it. At that point we'd verify them and use the valid returns. This option allowed us to change our in app purchases through iTunes Connect and then in the script and everything was great.
This is an older post, but I just had the same question and found out there is now a way to dynamically provide non-consumables by hosting the product identifier list on your own server:
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.
If your app has a fixed list of products, such as an in-app purchase
to remove ads or enable functionality, embed the list in the app
bundle. If the list of product identifiers can change without your app
needing to be updated, such as a game that supports additional levels
or characters, have your app fetch the list from your server.
There’s no runtime mechanism to fetch a list of all products
configured in iTunes Connect for a particular app. You’re responsible
for managing your app’s list of products and providing that
information to your app. If you need to manage a large number of
products, consider using the bulk XML upload/download feature in
iTunes Connect.
Apple Developer In-App Purchasing Guide
I think your limit on items is something massive like 10,000 or so.
Pre-create a big number of items, add some code to check your website to see what your highest chart number is and make sure the users can only buy charts that you have.
The app downloads the chart names and corresponding product id from your server and then you're just buying a product.
Apple doesn't care if the actual product is already in the app and unlocked by the purchase, downloaded from their server or provided from your website.
Whether you have these purchased directly via IAP or through some kind of in-app "currency" you could simplify the amount of work you'd need to do in the future by using a naming system which would guarantee a unique map name for each item you want to sell. For example:
NSString *myMapName = [NSString stringWithFormat:#"%#%#%#%#", app_identifier, map_type, top_left_corner_location, scale];
This way if your server passes that information for a new map, there's a programmatic way to know what the IAP identifier should be— just make it the value of the string myMapName.
In the case where you use currency (which sounds easier than the alternative option, and is what lots of big apps out there seem to be doing) you just need to make a hash with some data in your map so that people can't guess the code you're storing in their keychain/plist and magically get all your maps without paying :)
In the case where you actually have individual IAPs for each map, sadly you do have to make an IAP for every possible map once. (But you can hire some kid to do that part for minimum wage, right? It's just data entry) They can be basic shells, though, with the actual info provided via your server as described above, once it's verified that the map has actually been purchased.
Hope this helps!
I'm about to take my first foray into In-App purchases, and I'm not quite sure how to handle my situation. At top is my situation, with some actual questions in bold at the bottom. Any advice would be appreciated.
I'm designing an app that will have a LOT of in-app purchase content. Every day, around 20 or 30 new items will be generated for sale. 3 or 4 days worth of items will be for sale at any given time, and after that they go away.
So we're talking a lot of items. Way too many to add to submit to Apple for a unique ProductID each day.
Of all these hundred items, there are actually only 4 or 5 different types of item. So I'm thinking I'll need to make 1 SKProduct for each type. Under the hood (and invisible to the user) the will actually be buying a credit good for 1 item of type X. After the transaction goes through, I send the receipt AND the requested item to our server. Our server stores that and sends the file back. If they want a 2nd file, they need to buy a 2nd credit and repeat the process. Of course to the user it will be presented like they're buying Item 1, Item 2, and Item 3 directly.
To make this even more complicated, we also want to offer a 3 month subscription (at a significantly higher tier) for those who don't want to buy their items ala carte.
1. Does this sound like a good approach?
Will Apple be okay with this? If not, what possible alternatives do I have?
2. Optimally we'd like to allow people to re-download items they've already paid for.
Would a good approach be to make each credit non-consumable, and since I've already stored the receipt info on the server I can match it to whatever item they should get? If this is too complicated or against Apple's rules, we may just make the item consumable since the item is only good for a few days anyway...
3. Is there anything else I'm overlooking here?
Thanks for any insight you guys can provide.
Take a look about what the iOS Development Program License Agreement says about treating In App Purchases like credits:
2.1 You may not use the In App Purchase API to enable an end-user to set up a pre-paid account to be used for subsequent purchases of
content, functionality, or services, or otherwise create balances or
credits that end-users can redeem or use to make purchases at a later
time.
2.2 You may not enable end-users to purchase Currency of any kind through the In App
Purchase API, including but not limited to any Currency for exchange,
gifting, redemption, transfer, trading or use in purchasing or
obtaining anything within or outside of Your Application. “Currency”
means any form of currency, points, credits, resources, content or
other items or units recognized by a group of individuals or entities
as representing a particular value and that can be transferred or
circulated as a medium of exchange.
Correct me if I'm wrong, but if your approach does not unlock/add functionality or change the behavior of the app by buying an In App Purchase, my guess is that this could be problematic when trying to get Apple's approval.
Hope this helps,