So, I’ve decided to add In-App-Purchase support for one of my apps. I’ve researched about the subject a few times but it always seemed quite a bit of code for a lazy-driven project until I found a quite nice tutorial that at the bottom included a utility library that packaged everything you need to do it with no more than a couple lines of code. If you want to read it go to MK Blog and download the MKStoreKit that is quite easy to use. Tip: find the com.mycompany.myapp.myfeature strings and replace them.
However, this blog isn’t about how to implement In-App-Purchases but one of the most annoying requirements of the process, the AppId (or Bundle ID) can’t have wildcards. My original AppId was wildcarded, iAdSense.*, and since I had to change it I tried something new and fun: com.alexandre-gomes.iAdSense and that should be it. I generated the certificates (you can actually modify them and redownload them) and went to ITC (iTunes Connect) to add my In-App-Purchase items, obviously I named them like com.alexandre-gomes.iAdSense.Charts … or did I?
First thing causing trouble was that unlike on the Provisioning Portal you can’t have ‘-‘ on the In-App items, so there I went to go change every certificate and In-App item to com.alexandregomes.iAdSense and after all that stress I thought I was ready to go. After quite a bit of pain I realized that it wasn’t working, the error I was getting was a simple “Cannot connect to iTunes Store” and although not very helpful it led me to trust Google and the huge amount of ‘fixes’ in there, including a full restore. Turns out the problem was much simpler than that, when you create an In-App-Purchase item on ITC you’re assigning it to an existing app in there, so if you change the the AppId/Bundle ID there’s no way for ITC to know about it. The clue that led me there was a crude attempt at uploading a new binary which ITC didn’t allow on that obvious grounds of switching Bundle IDs.
Long story short: if your old AppId is abc.* and your existing app was named abc.xyz just create a new AppId abc.xyz, modify your certificates (and download them again) and you’re done. My guess is that if your AppId had a ‘-‘ in the name then you can’t have In-App-Purchases though.
Thanks for the heads up. As my app uses MonoTouch, I just read that tutorial (with some others) and implemented my own subset of a framework in a single C# class, as my scenario is quite simpler (just one consumable implied product, so that I don’t even download the list of products). I’ve also had those “Cannot connect to iTunes Store” problems which are totally misleading, until I found that the productId should be just the code I’ve registered in ITC, which was a three digit number in my case. Nevertheless, the point is I’ve just avoid the problem you are depicting, from the start but by just luck, as I never got certificates for wildcarded AppIds, always for fully specified ones.
a question for you. When you said, “when you create an In-App-Purchase item on ITC you’re assigning it to an existing app in there, so if you change the the AppId/Bundle ID there’s no way for ITC to know about it.”, did you have to upload a new version with a SWITCHED App ID, and THEN add In-App Purchase to solve the problem?
Right now, I have a similar problem. I already had done everything you said, but keeps returning invalid productID, I’m guess my in-app is connecting to the Old Version of the app? So, should I have to wait to get the new version Approved and THEN, add in In-App?