I’m working on an SDK, distributed as a static library, for iOS developers to use in their apps. I’m interested in offering non-consumable downloadable and built-in content directly to users via an interface included in the SDK. Ideally, when a user buys something from my SDK’s interface within one app, it would then become available to them in any other app also using the SDK. Does anyone experienced with StoreKit know if it would be possible to use Apple’s In App Purchase framework to accomplish this? Would I be violating Apple’s TOS if I roll my own in app purchase system?
I should add that my goal is to avoid rolling my own custom account/payment infrastructure if I can help it. Using StoreKit would be much simpler and more reliable.
tl;dr:
- Is it possible to use StoreKit at all without an app ID, or using a non-deployed app ID (it looks like it might not be)?
- Does Apple place any restrictions on custom in app purchase implementations (would I be violating the TOS)?
Sorry, but I think the answer for two of your questions will be NO.
For Q1:
There is no way to do so in a SDK. Since the IAP need both product id and the App Bundle id, both of those id are unique. That means, if one of your users added the id in his iTunes Connect, no one else can use it again. And you also need to know the user’s identity. This is impossible since Apple don’t want developers to do so.
Of cause you can identify devices by using some unique identity of devices, but you still cannot identify a specific user. And from iOS 5, the API to get UUID is also going to be removed, it’s much hard to identify a specific device.
If you are doing something that Apple do not want developers to do, I am not sure what’s gonna happen.
The only thing you can do is:
It sounds complex…
For Q2:
According to Apple’s Review Guidelines,
It’s also impossible to provide your own payment system in App Store’s App.
So, basically the answer for your questions is … NO…