I am developing an application in which user can purchase any image he likes. For this i have implemented the in app purchase functionality as consumable products. That means if user purchase the same image again, he has to pay for that again. But apple rejected this application by saying that the product should be non-consumable in this case.
Now the problem is i have to create unique product id for every image and the number of images are around 1800. So, do i need to make the 1800 ids in the itunesconnect?
Also, there is a parameter in itunesconnect that:
For Review
When you have tested your in app purchase and are ready to approve it and submit it for review, upload a screenshot below. This is for review purposes only and will not be displayed in the Store.
For this do i need to add screen shot by testing each and every image?
Please provide any simple solution for the problem.
Thank s in advance...
If you have 1800 unique products, you will need 1800 entries in the store.
There isn't an automated means for uploading product information so you will have to do it all by hand.
Note that you maybe also come away with a generic image IAP object, that's consumable. But you have to provide additional server infrastructure to make sure a account can be created and purchases can be restored.
And even then, it seems to be a thin line. There are however apps in the store that work this way.
Update (Feb 2012): It's not working anymore. Apple rejected the latest app using this technique. I'm sorry.
Related
I have implemented In-app purchase functionality in my iPhone app. In that I have given Restore Option. Sometimes, when I tapped restore button, I am not getting any product ids from App Store. But I have done purchases using Apple ids (Test User Account).
But sometime it works with some-other Apple Ids (Test User account). Why is this behaving differently?
How long should I wait to restore the purchase once after purchase is done. I use to check it on after 10min. Is that OK?
Apple (and Google) does give the option to 'save' the purchase history for you so a user can restore it if he deleted his app or switched to a new device. The functionality given by Google and Apple is very limited, however and you can easily implement a better functionality on your own.
Set up a server side for user verification
Make your own restore purchase function
Apply some rules on top of it (fraud protection, expiration, logs, ...).
To do that, you need to configure all products as "consumable" or in Google "unmanaged" and basically manage everything on your side.
I really wouldn't worry about it. No one is ever going to make an in-app purchase and then delete and re-download the app in the span of 10 minutes. If you have gotten it to work, you should be fine for any realistic case.
I have been stuck in a strange situation, according to my requirement, I need to track the resellers of my app, i.e. I will be publishing link of my app in the iTunes-Store on 3 or more different sites(The re seller's sites).
According to my promise which I made to these resellers, I will provide a share of my profit.
So here I have to track from which link did the user came to the APP-Store.
Any suggestions or solutions will be Thankful.
I think the only way to do it will be server-side. Links at your resellers should point to your server, where you log the source of link (resellers web page) and redirect request to AppStore. But you'll have no way of knowing, which of this requests ended up with a purchase.
The only way to do this for real is to get them to become iTunes affiliates and provide reports back to you. They should use the iTunes referral to make the sale (they will get a small cut from Apple) -- Apple will report that back to them, and then they can prove to you that they made a sale, and then you pay based on that.
Reserve the right to audit them -- meaning that they will have to show you the report directly from the iTunes affiliate site.
I assume that iTunes actually tells them what they sold, but you would need to check that.
Another idea (which may or may not make sense based on what your app does) is to make personalized versions of your app for each reseller. If there's some way to incorporate a very simple feature that is personalized (and makes sense), then you can upload the same app multiple times and assume all sales are coming from that reseller.
So, for example, if the app were an exercise tracker, and the resellers were gyms -- you could customize the app for each gym and add their schedule and contact info to it. Then, sell the app as an Excerise Tracker for XYZ Gym and let them promote it and get a cut of sales.
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
I uploaded one of my app before couple of weeks and it is available on the App store now. It has 2 In- app purchase. In app purchase logic is totally from remote server as we wanted to add new pack without updating binary file so we did everything on server side.
So, here is my actual question. Now I want to add new pack. so here is my confusion/question.
I made on inventory.xml file for all the In app purchase id for validating in app id. and I am displaying only those Items which are valid from App store.
Also, when user purchase any pack I am downloading contents from the server and they will have new pack after successful purchase.
So, how do I make it available to Apple for submission purposes without also making it available to the general public? That is, if I add the new pack to the inventory.xml file which lists all the packs, everyone will be able to see it before Apple even approves it. But if I don't add the new pack to inventory.xml, then Apple will have nothing to look at in order to approve it.
Thanks in Advance.
When you submit new in-app purchases to Apple, you upload screenshots and descriptions of the new content to iTunes Connect. That should be all they need for review, and you can wait to update your inventory.xml file until they have approved the new content.
I found answer for this question from other sources. So I am posting it here what I have found and I believe that is the correct answer. This is my opinion it may be wrong..
So, in my situation I can add new item in my inventory.xml file as well as in iTunes account and put it new item for the review.
The reason why General public (users) will not see my new pack because I have only show valid products which I got from SKProductResponse. So in the review process it will not be valid product and it would not show in the list of available items to the users.
Now, We and Apple tester can see it because we both are using In-app test user account to test new items and I believe In-app test user account returns all the product as valid.
So, from this flow I decided to move forward with this and hopefully it should work.
OK so have a problem with the whole in-app purchase review process and hope someone can shed some light/experience on it.
We have a project which is a magazine for the ipad. Each issue requires an in-app purchase before it is downloaded. The issues are served from an XML feed when a new one is published.
The problem is, how can we have Apple review an in-app purchase without displaying the new issue. They wont be able to see it in the live binary. If we publish the issue we have to say "unavailable", which looks extremely unprofessional to the customer, until the in-app purchase is reviewed.
We dont want to have to publish a new binary each time a new issue is published as thats a pointless exercise for the customer
Thanks, any suggestions apart from change message to "coming soon" would be apprciated. The only other thought we had is a flag in the app settings which displays "unavailable issues"
If you login to your iOS developer account, you'll find this Getting Started with in App Purchase pdf file, which has information that you'll need in your setting up with your iAP item.
Specifically, I think what you need is an item belongs to the category named Subscriptions. This should solve your problem.
You can use consumable purchases, i.e. right to download 1 article. 5 purchases - 5 articles.
Or, give a user subscription for month or so.
You could always just keep some kind of "sample" issue available for the purposes of the user demoing the software.
That, or a few select pages from the active issue could be specified as "demo pages", as in they would be viewable from a demo version of the software.