我有一个非常严格的前瞻性问题（是的，我看过苹果文档，看看这是否有答案，但没有运气......我可能不小心错过了它）
这是我的计划：
我一直试图找到解决方法的问题是，如果管理员想要添加产品，他将不得不登录iTunes connect添加它并将其添加到自定义控制面板中。显然，我们不想让他受苦，所以我一直在寻找解决方案，但我需要你们告诉我苹果是否允许这样做。基本上我将接管我们服务器上的大部分产品处理，并且只会通过交易转到苹果。这意味着苹果将不会为所有产品设置应用内购买...每个订阅长度（1个月，3个月等）只有一个，以及一些消费类应用内购买问题/单打的价格
附注：我将每月销售包含多个单打的月度问题。如果用户愿意，用户可以一次下载整整一个月或一天。
消费品购买的定义 - 每次用户需要购买产品时都必须购买产品。例如，一次性服务通常作为消费品实施。
所以我会在服务器中存储有关产品的所有信息，如果有人选择购买设置为4.99的单月问题（在我们的服务器上，而不是苹果），那么应用程序将运行应用内购买列为4.99等级的苹果。每当一个人第一次打开应用程序时，他们的应用程序会向我们的服务器发送一些信息，他们将为他们预留一行，其中将记录有关他们购买的所有信息，以便他们可以在他们切换时恢复它们到另一台设备。
如果你们认为我这样做是安全的，请告诉我，以便我可以继续。此外，如果这种方法可以帮助任何人，请随意使用它！
谢谢， 马特
答案 0 :(得分：1)
我认为您的恢复过程可能存在缺陷。您谈到应用程序将一些信息发送到您的服务器，但那些信息是什么？没有可靠的方法可以跨不同设备唯一标识用户。
如果您想继续这条路径，您需要确保恢复和故障转移过程非常可靠。尝试所有可以想象的场景。从应用商店提交的角度来看，您需要考虑基于令牌/硬币的方法。当然，Apple的指导方针相当宽松，可能会发生变化，因此您可能会被拒绝，但令牌肯定比仅使用相同的通用应用内购买更为可靠。
在令牌系统中，您可以针对不同数量的令牌设置应用内购买，用户可以将其作为仅在您的应用中有效的种类虚拟货币购买。然后，用户可以将这些令牌用于您动态创建的任何项目。
服务器端这意味着您需要某种方式来存储用户当前拥有的令牌数量以及跨设备唯一识别用户的方式，这是一个相当不确定的主张。您可以实现某种哈希算法，而不是存储每个用户拥有的令牌数量，该算法可以从应用内购买收据生成哈希值，然后将其发送到您的服务器。如果应用程序崩溃或网络在购买后但在发送哈希值之前死亡，则下次打开应用程序时您可以重新计算所有哈希值，发送它们，如果服务器无法识别哈希值，则只需添加它到数据库。然后，如果用户想要恢复他们的购买，您只需使用您将收到的应用内购买收据重新计算设备上的哈希值，然后将其发送到您的服务器并要求服务器找出每个哈希值，如何用户离开的许多令牌。您可以将其视为礼品卡系统，其中每个哈希是一张礼品卡。
同样，应用程序商店规则也会发生变化，如果苹果认为您正在尝试游戏系统并且没有提供有用的体验，则他们有权拒绝您。打开开发人员技术支持请求并查看苹果工程师是否可以为您提供更好的解决方案或告诉您审核人是否可能接受您的申请可能是值得的。