考虑以下示例。假设我们有一个应用程序，专业作家可以在其中通过基于 Web 的 UI 编写故事。然后这些故事可供 iOS 应用程序的用户使用，就像在应用程序购买项目中一样。
如您所知，我们需要提前创建应用内购买产品。但在我们的情况下，这意味着对于作者创建的每个故事，我们都必须创建一个新的 IAP 产品并等待 Apple 批准。
为了避免这种情况，我计划在 IAP 中创建通用的“消耗性”产品，例如价值 1.99 美元的故事、价值 2.99 美元的故事等等。然后在应用程序 UI 中，我将显示作者创建的故事列表，并显示作者在创建故事时指定的故事的相应价格。一旦用户点击购买按钮，我将显示购买相同价格的通用消耗品，并完成应用内购买流程。
现在的问题是苹果会批准这样的实施吗？它符合他们的 IAP 政策吗？我在问，因为我找不到这样的工作流程指南。
实现这一点的另一种方法是实现应用内信用/货币系统，如游戏使用。人们购买积分/硬币的地方，然后他们用硬币购买物品。这是一种久经考验的方法，但它不适合我对应用程序的类比，因此是问题所在。
您想要实现的目标是完全可行的，唯一的问题是您的可购买内容必须是动态的。您必须从服务器下载产品 ID，而不是将它们硬编码到您的应用程序中。
参考您的示例，我可以想象一个表格视图被提供了一个对象列表，这些对象列表中存储了 SKProduct ID。您必须这样做，因为在撰写本文时，您无法从 Apple 服务器检索应用程序的所有可用产品 ID。我知道他们没有实现这个功能很痛苦，但老实说，如果他们还没有实现，我认为他们永远不会这样做。
这是我指的方法：initWithProductIdentifiers
您为它提供了一个 NSSet，其中包含您要检索的所有标识符，但如果您提供一个空集或 nil，它不会回复所有现有的。如果您觉得这不起作用，您可以向 Apple 提交错误。如果您仍有任何疑问，请查看此 SO 答案：链接
另一个需要注意的重要事项是，您必须手动上传您的产品。Apple 没有公开任何 API 以使流程自动化。这意味着，每次作家向您的服务器上传内容时，您都必须登录 iTunes 连接并创建产品。此外，您将被限制为 10,000 种产品，因为这是您可以向 Apple 注册的不同产品的最大数量。我还建议您快速阅读 iTunes Connect 指南，其中包含一些重要信息，例如我刚才提到的：iTunes Connect
关于 3rd 方框架，如前面提到的 UrbanAirship，它们只会让您不必在服务器上实施收据验证。除此之外，我没有看到任何主要优势。
Said this, I'd recommend you to reconsider your business model. Is it really worth it all the hassle of uploading the products one per one? Or is it better to go the subscription way, in which your users pay a fixed amount of money for downloading a number of articles per month. You could have different tiers, like, basic, premium (unlimited downloads) an so on and control the delivery of the articles from your servers. That's up to you, but for me the answer is pretty clear.
普里坦
对于交付动态内容，您应该使用订阅，而不是消耗品。使用订阅通过允许您为每次更新收费并同时分发新内容来解决您的问题。
您可以查看 UrbanAirship 等 3 方服务，这将显着减少您尝试动态交付内容、跟踪订阅和到期等所花费的时间。