iOS/Xcode: Concurrent builds for Debug, Ad Hoc, and Release *w/ In-App Purchases*

Question

I've followed this tutorial to allow for my app to have builds for DEBUG, ADHOC testing (for my beta users), and RELEASE. Everything works great except for my in-app purchases.

My Bundle IDs after this setup are:

• Debug: com.mycompany.myproduct.debug
• Ad Hoc: com.mycompany.myproduct.adhoc
• Release: com.mycompany.myproduct

(The RELEASE ID is the same as it was before this new setup.

Since this method changes the Bundle ID based on the build and since In-App Purchases are tied to a specific Bundle ID when I run my app as DEBUG or ADHOC my product identifiers come back as invalid when I call requestProductsWithCompletionHandler.

I have tried adding new In-App Purchase products prefaced with the new Bundle ID like so: com.mycompany.myproduct.debug.iapname, but since the In-App Purchases are tied to a single Bundle ID this doesn't work.

My question is this: In order to accomplish what I'm trying to accomplish, do I have to create 2 new apps in iTunes Connect for each of my new Bundle IDs and then add In-App Purchase products to each of those for each Build Configuration? Or, is there another way to accomplish what I'm trying to accomplish?

Extracurricular

Why do your different builds need different bundle IDs? – Stun

So that they're installed as separate apps on a device. This way I can have a release version on my device concurrently with a debug and/or beta version. – Extracurricular

Hmmm. Not sure of the value of that. Anyway, it looks like you can't do it if you use in-app purchases. – Stun

There is definitely value if it fits your use case. It allows to have beta testers and yourself using a different version of the app than the release version. Check out the link if you haven't. – Extracurricular

Answer 1

The answer is yes, As store kit gets the in app purchases from the iTunes store the easiest way to do this is to add separate apps in iTunes connect and keep them up to date.

The other approach you could take could be to abstract store kit away from your app in your own class. Then you can check the bundleIdentifier property of [NSBundle mainBundle] and either ask for your products from the store if your bundleIdentifier is the one you expect, or return mock SKProducts that you create yourself if it is only for testing purposes.

I guess it depends on how committed you are to your testers but obviously your custom classes would be scalable to n bundle identifiers whereas dummy apps in iTunes connect isn't scalable at all

Avuncular

Thanks for idea of creating mock SKProducts. – Extracurricular

When adding separate apps, is it ok to just have an app that never gets submitted? This guide suggests that you need to actually submit the "ad-hoc" build (and then reject it). – Infuriate