Is it possible to use StoreKit (In App Purchase) inside a static library?

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:

1. 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)?
2. 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:

Let the user and the developer sign up to your server.

The developer should tell you what id he is using for your content in his App, and what is his App bundle id.

After a user bought your content, your SDK should use the App id and IAP product id to find out what the content is, and then save the information on your server.

After the user login into another App, your SDK should check the server for the information. Provide the content to the user.

It sounds complex...

For Q2:

According to Apple's Review Guidelines,

 11. Purchasing and currencies

 11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected

It's also impossible to provide your own payment system in App Store's App.

So, basically the answer for your questions is ... NO...