I have created an app in which I have category of images and every category has unlocked images. There are around 10 categories and each category has 50 locked images. User should be able to pay $0.99 for each image through In App Purchase. Since the price of each image is same so can I use the same product identifier for each image and make that Consumable? Or I will have to add 500 product Identifiers and make them Non Consumable? Please suggest.
I would create some kind of In-App currency which could be bought with In-App purchases (consumable) and could be used to buy the images. To prevent the user from losing already purchased images I would upload them to iCloud. If the user removes the app from it's device he will still be able to access the image on other device or on the same device after reinstalling the app.
Another advantage of this solution is that you can give away images/IA-currency for free, which wouldn't be possible with the alternative solution. Giving away could be very useful for marketing (for ex. giving away a free image when inviting friends to use the app).
Only weak point is when the user manually deletes the images from iCloud or the user disabled the iCloud feature the images will be lost when the user removes the app. But I ignore that issue and assert that that's the users fault. If you want to workaround that issue you would have to setup a central server and log which user has bought which image.
Related
For last few days this cat and mouse game is going on between me and App Store Reviewers. And despite searching everywhere, I have not been able to find an answer to this question, so seeking help here.
I have submitted an app with auto-renewable subscriptions in it.
My app requires that users sign-in in order to see additional options, which includes subscription option as well.
App Store Reviewers keep rejecting my app citing this same text every time:
Regarding 5.1.1, we continue to notice that your app requires users to register with personal information to purchase non account-based in-app purchase products, which does not comply with the App Store Review Guidelines.
To resolve this issue, it would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional iOS devices.
We look forward to reviewing your resubmitted app.
Best regards,
App Store Review
What is non account-based in-app purchase products by the way?
I have also made it clear in my app what App Reviewer have asked above, i.e. make clear to the users that registering will enable them to access the content from any of their iOS devices. I didn't say iOS devices specifically, but said other devices since I'll have the same app on Android devices as well.
While I appreciate App Store Reviewers to help me improve my app, but I am totally lost here. I have submitted two updates to my app but every time it got rejected with the same reason.
Over this period I have also read their guidelines, read many similar cases online, but am still not clear what is required of me here.
Do they want the users to be able to purchase subscriptions even if they are not signed in? If so then technically how does this work? First it'll break the core functionality of the app since without registration I don't have user's info to create an account for them. Secondly how will I know which user purchased the subscription? I have to tie the subscription to the user's account on my backend. This means first I need to create an account for the user before user can purchase a subscription.
Please help me to get this right.
Currently I am waiting App Store's reply and my screens looks like these, with all other options removed when not signed in, and added text bottom of the Sign-In option, and help icon on top right of the screen where there is more information available for the user; and the one when user is signed-in.
If I would be a user of your app, I think I would find this behavior quite odd.
I would expect a login/registration screen when starting your app. If I decide to create an account, the Subscription button would always be visible within the settings.
However, there would also be an option "Continue without registration". If you do not create an account, the settings page could show some info text like "Some features are only available for registered members. Please tap here to create an account". Tapping the corresponding cell would show the registration page that is also shown when starting your app for the first time.
Maybe some users created an account in the past but forgot their passwort? Then they would not be able to restore their purchases, right?
Your login/registration form should also contain a "Forgot Password" option.
My app was eventually approved last year. The change I made was to remove the Subscriptions button from the Settings menu. And move it inside the user profile page. This means that user can see the Subscription option only after signing in and by going to their profile page. While this doesn't make sense to me, but that's how probably Apple wanted it. Subsequent updates to my app were also approved without any problem.
I am trying to implement in app purchase for an iOS application
Did some googling and read this thread : Maintaining records of iOS in-app-purchases
It seems the way to go indicated is to use keychain
My in app purchase type is - Non-Consumables
Am wondering what is the best strategy for :
1
If a user has made an in-app purchase and resets the phone / deletes the app and then again downloads the app - do not want the user to pay up again
2
if the user does an in app purchase on an iPhone and then does an update on the iPad - he should get the in app purchase content without paying again
As far as possible do not want to store anything on my server if at all possible and am sure storing something locally on the device is useless for resets / multiple devices
Thanks!
akila
Apple keeps a record of what the user has purchased.
You also must implement a in app purchase restore button for the user in case of the two situations you mentioned above.
The inapp purchase restore button asks the App Store if the user has purchased before and sends you authorization if the have.
I recommend you use a library like RMStore on github to deal with in app purchases, the only big manual thing you need to do is obfuscate the in app purchase status as it stores it in the NSDefaults.
If a user has made an in-app purchase and resets the phone / deletes the app and then again downloads the app.... you want to restore the transactions by keeping an Restore button . Once you click on the restore button you want to connect with the storekit for restore the transactions. Their you can get the list of products that user has already purchased . Check the list of productids if your productid is match then unlock the content. All the best
I have a question regarding the apple licence over in-app purchases
I have the following scenario: I have a site that is a store of avatars (just like a mii or a xbox live avatar) where my users can buy items, just like hats or tshirts … all kinds of virtual goods for an avatar.
I want to make a game for iphone were you can load this avatar.
In this app, you login using you user account (I mean the user I have registered in my site), then your avatar is loaded and thats all.
As far as I know, I am not allowed to buy things if they are not bought using the apple in-app purchase system.
but certainly my users will be buying lots and lots of other things for their avatars in my site.
So the question is, will my app be allowed to be in the apple store?
I have read enough and I think that if I doesn't mention anywhere in the iphone app, that an external store exist, my app will be allowed or not?
If they can buy content outside of the application that will be used inside of the application, that's usually fine so long as the application doesn't provide a link for them to buy from outside of the App Store. If somebody can tap a button in your application and be taken to your website where you can buy things for use in the application, Apple will probably reject it.
I want to revamp the purchase model on one of my iphone apps to use in app purchasing to unlock the full featured app instead of having two separate apps. Is there a way to do this so that anyone who has previously purchases the app can get the purchase for free automatically?
The strategy that I used is to create a NSUserDefaults for previous purchasers of the application. Then I put that version in the app store for a month. I picked a month so that hopefully that all users had a chance to up date the app. After a month I put the in app purchase feature into the app and put that in the app store.
When I test to if I should use any in app purchase content I also check to see if the NSUserDetaults I created in the previous version is set.
There is not currently any way for the user to be given the In-App Purchase item for free.
However, if you can detect that the user upgraded from the old version (e.g. by examining NSUserDefaults) you can easily enough have your "did they purchase the full version?" check return true for that case too.
Has anyone seen iPad greeting cards app... what they have done is released the app with some limited greeting cards and now user can download the other cards from web by paying some amt.... I want to implement such functionality .. has anyone any idead about that.. I know that can be implemented by taking image from url recieved data and saving that image in app.... but i dnt know how i will establish connection between app and web that paricular user has paid the amount and so now card can be downladed into his app and also where will that card be saved whether in userbundle or somewhere else...please give me some direction....
What you are wanting is "in-app purchases".
See:
http://developer.apple.com/appstore/resources/inapppurchase/
By adding in-app purchases to your app you will be able to sell additional functionality to your users from directly within your app.