When using Apple hosted In-App purchase, is there any way to selectively download content, even though all content has been purchased? Let's say user purchased a set of PDF files, which contains hundreds of categorized PDFs, with total size over 100MB, but user only want to download some of them at any given time. Then he may delete or leave it and download more files. Does IAP API provide such selective way of downloading content from Apple hosted servers?
No, you can set one package for one IAP product.
The only solution I can think of (With out using an other server), is to use the new "free" products that has been added in iOS7.
If that is possible you can set a free product for every PDF file, and enable the "purchase" and don't show this products to the users. And then when the user buys the "All PDF's" product, you can show them the list of the free products and allow them to get them.
The downside is that they will have to pass the "Free Purchase" process for each file.
Related
I just launched my first app on the IOS App Store:) I noticed that the newly released app page on the app store is requiring users to purchase the app before downloading it, how do I change the set up in app store connect to allow users to download the app before purchasing their subscription?
So right now the button where it supposed to say GET is just showing the price of the app and requiring users to purchase. Is it something i'm missing on the Pricing and Availability tab, maybe does it need to include a free option there? Any advice would be much appreciated as I can't seem to find any info on this.
Set the price to zero (i.e. move it to the free tier) on the Pricing and Availability tab in App Store Connect and the button will say "GET", so the users will be able to download the app for free.
This however will not automatically mean that your users will be able to make in-app purchases in your app, you have to configure IAP products separately (and submit them for review alongside an application build for the first time) and write code to handle the purchases as well as to provide a UI that enables that.
not sure if this pass as a Stackoverflow question (close if not).
The problem we're facing at the moment is we have an app that we want to allow user to pay to unlock additional content space so they can create more content but be able to purchase multiple copies of that item without being charged twice unless they've exceeded what they've initially purchased.
So a concrete example is this:
Think of a item bag in World of Warcraft that lets user carry more items. (Our app isn't a game but it's the same concept). Users can buy many copies of the bag and at the same time, it doesn't matter if the user log into the app from their home computer or another computer, the bags are still tied to their account.
I'm aware that I have two options really:
Non-Cosumable In App Purchase
User buys the in app purchase item once but does not buy another copy. In other words, they can only ever have 1 copy of that item, not 10 or 20 copies (which our business logic requires in this case).
Consumable In App Purchase
Allows purchasing multiple copies of the item BUT they are non-transferable purchases. This would mean users would need to pay for the same item again even if they bought a new iPad, they can't transfer those "bags" to the new iPad or if they delete the app and reinstall the app, they would still need to pay for those items again.
Subscription based in app purchase doesn't exactly fit our model.
So is there a special type of non-consumable in app purchase but allows the user to buy multiple copies of that item/feature?
Additional Considerations
We do not have a third party server to track users and the number of copies of that item/feature they unlocked.
It also doesn't make sense to make a hundred copies of the in app purchase in iTunes Connect manually.
I think only making a consumable in app purchase is our only option. We're reluctant to force to user to have to pay for unlocking the same content twice but at the same time don't want users to be able to keep creating additional "bags" for free.
If user purchases a non-consumable purchase twice, I am sure Apple store has mechanism to prevent the purchase.
Instead, it would simply say: You have already purchased this product. It will be downloaded again. You will get all the delegates being called normally, and content delivery will happen as per what you have coded, but the customer will not be charged.
To avoid the payment flow, you can store the purchased item under itunes user's keychain, too.
With iOS 6, Apple provides free hosted content for in-app purchase using StoreKit.
I would like to understand the benefits of this, especially in terms of security!
If I have a pack of images to unlock, I can choose to host the images directly in the app, or in hosted content. Is it more secure to go with hosted content? My in-app purchase already verifies the receipt from Apple.
Is there a chance that a hack can unlock the images directly in my app?
If my pack of images is like 40MB, is it a good solution for the user experience to download the hosted content? With a not so good 3G connection it can be painful...
Thanks for your answers.
Apple offers some guidance on when to use hosted content or bundled content. I'm quoting from In-App Purchase Programming Guide: Delivering Products.
Embed smaller files (up to a few megabytes) in your app, especially if you expect most users to buy that product. Content in your app bundle can be made available immediately when the user purchases it. However, to add or update content in your app bundle, you have to submit an updated version of your app.
Download larger files when needed. Separating content from your app bundle keeps your app’s initial download small. For example, a game can include the first level in its app bundle and let users download the rest of the levels when they’re purchased. Assuming your app fetches its list of product identifiers from your server, and not hard-coded in the app bundle, you don’t need to resubmit your app to add or update content that is downloaded by your app.
These are guidance, not requirements, so if you have reason to believe that someone will make an in-app purchase with a large downloadable asset while they're on cellular, you might want to bundle it. However, this is wasting space on your user's device if they do not purchase to unlock it.
As for security, they have this note in the section regarding download objects.
Note: Download all Apple-hosted content before finishing the transaction. After a transaction is complete, its download objects can no longer be used.
This implies (although, does not explicitly state) that the downloads are only available with some internal authentication of the transaction. This means that it requires Apple's approval, which is actually more secure than checking the receipt locally (which can be bypassed using jailbreaks).
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 have been looking for a solution for a question for a while without any real luck. Is there a way to bulk create non-consumable in-App purchases via iTunes Connect? I have roughly 20,000 individual items within my app that can be unlocked via in-App purchase.
If there is not a bulk upload option, which I suspect there is not, is there a way to just place a single generic in-App purchase that will unlock a selected item? For example I would present a table view with items available for unlocking based on user search criteria, each has a unique ID, with a button that would purchase that item that is selected. All the items are the same price and of the same type. Seems like this should work but I have not idea how to implement it with the in-App purchase confines.
Any thoughts?
Thanks
There's actually a way: uploading a csv(comma seperated values) text file, containing the products' metadata, and uploading it through Application Loader.
Check This Post
Quoting:
You can use the Application Loader to mass import in app purchases: https://itunesconnect.apple.com/docs/UsingApplicationLoader.pdf
Read the "Creating a Package from a File" section on page 15:
You can create a package containing the In-App Purchase you want to submit to iTunes by importing details from an Application Loader file and adding and editing the metadata. When creating a package from a file, be sure to use the Application Loader template. To get a copy of the template, choose File > Open App Import Template in Application Loader 2.9. Application Loader creates the AppFileImportTemplates folder containing the AppMassImportTemplate.txt template. To always have an original version of the template file, be sure to make a copy of the template before editing.
Regards
I think, that making 20.000 items in iTunes Connect isn't a right choice for you,
You can try to combine Apple's iAP with your server — just make several tiers of IAP(1$,2$,3$), each responsible for a variety of items with the same price, and on your server take track of what specific item have user purchase.
Because there is no default solution, provided by Apple, to make such kind of Store.