When you first create an in-app purchase in iTunes Connect, it is listed as â€œPending Developer Approvalâ€. This means that if you ask for info on that product id with a SKProductsRequest, youâ€™ll get the info for the item only on development builds, not in distributions builds.
Once your in-app purchase item is ready, you need to upload a screenshot of it working in the app, and approve it yourself. At that point it enters the queue to be approved by Apple. Once an item has been approved by Apple (marked as Ready for Sale), it will appear both in development and distribution builds.
This behavior is very convenient because you can add in-app purchases normally for development, and not worry about them showing up for all your existing users until theyâ€™re done. Just make sure to keep around a distribution build of your app to test what the end user sees.
In addition to that, you can flag items as available for sale or not. That way you have the added flexibility of temporarily removing an item from sale, or making it available at a later time.
The first time you submit any in-app purchases, youâ€™ll probably do it along with a binary update (since you need to code in support for displaying and allowing the purchases of items). Youâ€™ll have an option to mark the items to be approved along with the binary, so everything will become available on the App Store at the same time. In that case, the approval process is just like for a regular binary update (it seems to be averaging a week lately).
You can also submit in-app purchase items by themselves, without an app binary update. I did this for the Seeds of Winter pack in Flower Garden. Somehow, I was expecting a turnaround time of a day or two. After all, I figured they would look at the provided screenshot and approve it. Unfortunately, that wasnâ€™t the case. In this particular situation, approval took almost a week, and Iâ€™m not sure it was because of the normal process, or because I emailed Apple asking what the procedure was to submit a product by itself (the product was approved within an hour of me getting a response from them saying they would look into it).
I was monitoring iTunes Connect pretty obsessively at the time it was approved (because it was right before my two-week break for the holidays) and I saw that the Seeds of Winter pack went from â€œWaiting for Reviewâ€ to â€œIn Reviewâ€ to â€œApproved for Saleâ€ in a matter of two minutes. That was one quick check! (Iâ€™m not complaining though).
Whatâ€™s even more interesting is that I didnâ€™t know that an item wouldnâ€™t appear on a distribution build unless it was approved by Apple, so I had added an extra layer on the shop catalog file on my server that allowed me to prevent an item from showing up on the Flower Shop until I turned it on myself. And since that check wasnâ€™t turned on, it means that Apple approved the in-app purchase by looking at the provided screenshot, without running it in the app.
This shouldnâ€™t be too surprising. After all, Iâ€™m not even sure what the point is for in-app purchase approvals. For content that comes from the server, I can change it at any time, so the only thing they can approve is the name and description provided in iTunes Connect. I suppose the screenshot is fine for that, but I would also expect really speedy approval times. After all, not having to wait for lengthy approval processes is one of the big draws for in-app purchases.
I did learn one important lesson from going through this process. Next time I submit a binary prepared for more in-app purchases, Iâ€™m going to create stand-ins for all possible in-app purchases Iâ€™m considering and submit them for approval at the same time as the app binary, but marked as not ready for sale. That way they will all be approved at once, and I can take my time creating the final version for those items and making them available instantly whenever I want.
The same way that non-Apple approved items only show up in development builds, the only accounts that can purchase any items on development builds are test accounts using the sandbox environment. These are accounts you create on iTunes Connect and allow you to purchase items in your programs without spending real money (otherwise Iâ€™d be in trouble considering how many times I ended up purchasing items during the development of the Flower Shop!). Conversely, distribution builds only work with non-test accounts and non-sandbox environment.
One thing that threw me off was that I started getting support requests from people who had trouble logging in with their account to make in-app purchases. They claimed they were being asked about this â€œsandbox environmentâ€. That threw me in a panic for a second, because I thought that everybody was somehow accessing the sandbox environment and nobody could make any purchases (because they had full iTunes accounts). It turns out, thatâ€™s a problem that happens with jailbroken phones with a particular app installed. Itâ€™s nicely documented here so Iâ€™ve been pointing people in that direction.
Finally, I believe thereâ€™s no provision in iTunes Connect to deal with different binary versions, but thatâ€™s something thatâ€™s very important to handle. If I release a new binary with some new feature built into the app, and an in-app purchase to unlock it, I donâ€™t want people with an earlier version purchasing it and getting mad that itâ€™s not working. Ideally this should be an option in iTunes Connect, but in the meanwhile, I build a version check into the shop catalog itself. That way only apps with that version or higher can even display a particular item. Or I can even take it a step further and display the item but notify the user that they need to update the app before the purchase it.