I'm making a game that has a few levels that are available as in-app purchases (non-consumables).
I'm getting closer to submission time, and I really have a deadline I need to hit, so I'm running into this issue:
Can I submit In-App purchases to iTunes Connect AFTER I have submitted the app for review? I know I can add them to iTunes Connect before, but not all of the levels are ready yet, so if they tried to download them from my server they wouldn't actually get the level and would likely get rejected.
Is there any way I can add them to iTunes Connect after submission, when each one is done so the content will be live on the server?
Essentially, the app will be done a week or two before the levels will be complete, and I don't want to wait until the levels are done to submit to the app store.
The big issue I see here is I don't want to have the game released without all the In-App purchases available.
I was thinking about making a generic "token" that a user can download and redeem it for a level, but I'd rather stay away from that in case I want to have different prices for them.
Any help would be greatly appreciated!
Thanks.
For those who stumble upon this, I figured out the answer. As long as one in app purchase is submitted with the first bundle, you can add other ones along the way, even when it's waiting for review.
Related
We want to add in app purchase (auto renewable subscription) to our app. We do it on a separate branch and don't want it to be part of the app until implemented and tested thoroughly.
To support it, we need to define a IAP on app store connect.
Of course, other features are implemented simultaneously, merged to master, and we submit the app to review once a week.
We are scared that if we'll define the IAP, when submitting to review the IAP will be submitted automatically with the app, before the feature is ready on the client side.
Is it possible to exclude the IAP from review until we are ready to submit it?
If not, how would you approach this?
When you view your IAP on App Store Connect there is a checkbox, "Cleared For Sale". You can keep that unchecked to be safe that your in-app-purchases won't be visible anywhere.
I just made my first IOS app which has an IAP option and today it has been approved by iTunes Store. After I got the email, I had to wait another 4 hours before the app actually has been added to the App Store.
After I search for it and download it on my phone I decided to test the IAP option, but it doesn't seem to work. I am using my original Apple ID email and not the one I used for testing.
My question is, if the app has been added to the store, does the IAP has to work ? Or you have to wait awhile ? Just like waiting for the app to be added to the store after it has been approved.
PS: both the app and IAP has been approved by Apple and the status of my app is Ready For Sale.
edit:
If I run my app now from Xcode I get the following output from my code:
About to fetch product
Fetching products
Got response from Apple
Black Edition Theme
Black theme
0.99
Sending the payment request to Apple
Received payment transaction from Apple
Received payment transaction from Apple
Restored
Received payment transaction from Apple
It works how it should, but it keeps asking me for my Apple ID password continually and at some point said Cannot connect to App Store even if everything was successful, and after I click Retry I get the Confirm Your In-App Purchase screen but it also says Environment: Sandbox
I'm really confused why the sandbox screen is appearing.
Apple's servers often lag behind directly after updating an app with a new IAP (the product will not be found by the API). Waiting a few hours usually resolves the problem. We've had this with every new IAP we added.
You say the IAP "doesn't seem to work" ... what do you mean by that? You are charged for it, but you don't get the new content / feature / whatever it is? Or you select Purchase in your app but nothing happens?
It's been a while since I worked with IAP, but back when I did you had to submit at least one IAP component at the time you submitted your app for review. So both were reviewed at the same time.
If that's what you did, the IAP should be available immediately - if it's not, yeah... something's wrong.
Apple just rejected my app saying the following:
"Upon further review, your app's previous submission was improperly rejected for 11.1. Since the sensor functionality of your app is dependent on the associated hardware, it would be appropriate to offer the sensor functionality to all users through achievements or In App Purchase."
Does this mean, I should resubmit the first version because it was ok?
If not, do I have to implement achievements from the Game Center, or what kind of achievements do they mean?
Any thoughts that can help me to get this app on the App Store?
Thank you
Additional information:
first version
In the first version I had "a kind of"-achievement, where users can provide a code they receive with the purchased associated hardware. And they could buy this functionality if they wanted to test for example the device of a friend or a public one.
Rejected: Because they claimed that the user can bypass the purchase of the function by providing a code.
second version
In the second version I took out the In App Purchase because we do not want that our clients need to pay again.
Rejected: see above.
From my experience with the App Store I can say that except for some definite rules (no pornography, hate speech, etc...) most of the review process and decisions are ambiguous and inconsistent.
In fact Apple's App Store policy is vague on purpose so they can exercise a bit of freedom with App rejections. However, from my own anecdotal experience and research, they've always been fair. I have yet to come across an issue where they've rejected an app without having a valid reason for it.
In your case, I believe your app was rejected the first time around since a user could bypass a purchase through purchasing something outside the App Store environment. This means you could sell your code without going through in app purchases and having Apple get its 30% share. This will most likely get rejected again if you submit it.
I'm a bit unclear on what happened with the second case..
Our app is moving from paid to free, and in the process, moving a key functionality from being included to activating via In-App purchase. Obviously, we don't want current users who paid for the app functionality to be charged again in the In-App purchase for functionality they already had. So on the update by the user, we want to 1) identify current users and 2) make it so they don't see the In-App purchase in the first place, sort of 'faking' the In-App purchase so that the app will appear to them exactly as it did before.
The app does not have a backend, so we have to determine current users from new by examining the saved user data fields for certain values. I do understand that if a previous user has deleted the app from their device that nothing can be done, and I don't mind charging them for the In-App purchase, since they never used the app anyway.
But for those current users who update and assuming we can examine the saved user data and determine that they are current users, what would be a good way to bypass the In-App purchase and make the app look like they already got it, when in fact they never paid for it? Thanks!
Here's what I would do - keep in mind this will take some time:
Set up a server (I prefer EC2) with mySQL on it. Plenty of tutorials about this.
Submit an update to your app that sends the user's UUID to your server.
Wait. This is the hardest part. You'll need to wait until satisfactory majority has updated to your app. That majority percentage is up to you to figure out. It could take months for this to happen.
Make your new, free, app send the UUID to the server.
Check to see if the UUID is in the DB.
If it is, set whatever you would have set when an in-app purchase was made to true.
You have several options:
Free in-app purchase for a limited time:
You would create a free tier in-app purchase content and release an update that somehow makes the user sign up for it. This way, when your user switches devices they can restore the purchase and regain the functionality.
Wait for a period so most people use the in-app purchase content
Change the tiers and release your app as free
Dual versions
Make a demo version of your app. Note this can be rejected by Apple.
Create a file in the filesystem
Make a file in the filesystem and save into iCloud. The app will check for the file and thats how you would determine if the user has paid for the app (or should buy the in-app purchase).
iCloud will synchronise the file between user's devices and it will make sure that whatever device the user uses the app will see the user as 'paid'.
I hope this helps, currently having this problem myself.
I have a magazine app, and I want to provide users a one year auto-renewable subscription, and for non-subscribed users, they can use non-consumable IAPs to pay for each issue and then download it. What is the best way to implement it?
For auto-renewable subscription I don't think it's a problem. I can follow the tutorial at http://www.viggiosoft.com/blog/blog/2011/10/29/at-newsstand-and-subscriptions/ to finish this part. But for the non-consumable IAP part, I'm not sure. Do I need to add all the non-consumable IAPs for future issues before I submit the app? If I do this, how could Apple review my IAPs, because the future issues are not prepared at the reviewing time. Or, can I add non-consumable IAPs after my app is published to the App store? For example, every time when a new issue is ready in our server, we add a new non-soncumable IAP in iTC, and also set the product id to the issue in the server. When the non-subscribed user click that issue, the purchase for the specified product id will start. Is it possible?
After some research I found that the best way to implement it is to set up a new non-consumable IAP at each time when you want to publish a new issue.
The only problem is that, each IAP needs to be submitted for review, and before it is approved, the users who try to buy the issue will get an error message: "Cannot connect to the iTunes store". I haven't figured out how to know that the IAP is in review, so I can popup a nicer message like "Issue is review, please wait" other than a confusing error message.
I have a magazine app, and I want to provide users a one year
auto-renewable subscription, and for non-subscribed users, they can
use non-consumable IAPs to pay for each issue and then download it.
What is the best way to implement it?
You should accept your solution, but here is another case, maybe it helps you or others:
The subscribers can have they magazines, which are not in at iTunes Server, but at your hosting. Those magazines not need to bypass the apple review.
It depends whether you want a user to be able to permanently have a record stored in their app receipt of the issues they have bought. You might want this, if you want a user to be able to delete the app, with all associated content, then later re-install the app, and be able to download the specific back issues they purchased previously—all without having any user account on your own server. The use of a non-consumable in-app purchase also enables you to give them access to these issues across multiple devices that are signed in to that Apple ID, again without having to run your own user account-server combination to track purchased issues.
If these features don't matter to you, then there is a solution you could consider that is much simpler where you don't have to keep creating new in-app purchase products. Have a consumable in-app purchase product that is called something like Purchase One Issue. When a person buys this product, they get one credit and they can use this to select the issue they wish to be given access to. Your app then gives them access to that issue. You could also of course reverse this process in the UX: they pick the issue, click buy, you send them into the purchase process for the Purchase One Issue product, and you automatically give them access to the selected issue since they already selected it.
Note: consumable in-app purchases are not stored in the app receipt, so a user couldn't use this approach to 'restore previous purchases'. In scenarios where this is acceptable however, this is a much less labour intensive approach once set up.