iOS StoreKit 旧版/升级支持的最佳实践是什么?

发布于 2024-12-02 19:36:40 字数 659 浏览 3 评论 0原文

我正在开发一款 iPhone 应用程序,迄今为止,该应用程序使用统一定价模式。在下一个版本中,计划是减少基本功能集和价格,然后为用户提供应用内购买功能包的选项。

添加应用内购买似乎非常简单。我担心的是,我应该如何处理当前拥有该应用程序的用户的遗留支持并不明显,因为在升级时,他们仍然应该可以访问所有功能。即旧用户不应该失去对功能的访问;他们应该被视为已经支付了费用。

我认为,处理这个问题的最简单方法是对 plist 文件(或 NSUserDefaults)中是否存在标志进行一些例行测试:如果该标志不存在,则它是从以前的版本升级的。

另一个是当内核检测到应用程序更新版本的首次启动时触发的回调。然而,我在此类支持的可用文档中找不到太多内容。

有人可以提出建议吗?


编辑:还有两个相关场景需要解决:

1)用户安装了旧版本的应用程序。他们升级了应用程序,但后来卸载了该应用程序。当他们重新安装(商店中的新版本)时,他们应该仍然可以访问旧功能。

2) 用户卸载了旧版本的应用程序,但决定从商店安装更新版本。就应用程序而言,这是一个全新的安装。

(1) 似乎可以通过让升级过程在 StoreKit 中创建许多 0 美元购买来解决。这样,Apple 对恢复应用程序(和购买)的支持就应该正常工作。

至于(2),我不知道是否有任何方法可以解决这个问题。

I'm working on an iPhone application that, to date, has used a flat pricing model. In the next version the plan is to reduce the basic feature set and price, then give users the option to make in-app purchases for feature packs.

Adding in-app purchases seems very straight forward. My concern is that it's non-obvious how I should handle legacy support for users who currently own the app because, on upgrade, they should still have access to all of the features. I.e. legacy users should not lose access to features; they should be treated as if they already paid for them.

The simplest way to deal with this, I think, is to have some routine test for the existence of a flag in a plist file (or the NSUserDefaults): if the flag isn't there, it's upgrading from a previous version.

Another would be some callback that's fired when the kernel detects the first launch of an updated version of an application. I can't find much in the available documentation for this kind of support, however.

Can anyone make a recommendation?


EDIT: There is also two related scenarios that need to be addressed:

1) User has the old version of the app installed. They upgrade, but later uninstall the app. When they reinstall (the new version from the store) they should still have access to the legacy features.

2) User uninstalled the old version of the app, but decides to install the updated version from the store. As far as the app is concerned, it's a brand new installation.

(1) seems addressable by having the upgrade procedure create a number of $0 purchases in StoreKit. That way, Apple's support for restoring apps (and purchases) should just work.

As for (2), I have no idea if there's any way to work around that.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

倒带 2024-12-09 19:36:40

我尝试了第一个路线(检查 plist 文件值是否存在),它对正在更新的人有效,但对那些删除了应用程序然后下载并尝试使用更新的人不起作用。 (或者,如果他们在任何时候删除应用程序并重新安装,他们就会失去该功能)

幸运的是,我有一种使用“促销”代码激活功能的机制,因此当一些用户抱怨他们已经为以前的版本付费但当某些功能成为应用程序购买时,它们不再具有某些功能,我向他们发送促销代码以激活该功能。不太理想,因为我无法验证他们是否确实购买了它,但只有少数人询问过。

I tried the first route (checking for the existence of a plist file value) and it worked for people who were updating but it didn't work for those that had deleted the app and then downloaded and tried to use the update. (Or if at any point they delete the app and reinstall, they would lose the feature)

Fortunately, I had a mechanism to activate features using a "promo" code, so when a few users complained that they had paid for the previous version but no longer had certain features when they became in app purchases I send them a promo code to reactive the feature. Not ideal because I had no way to verify that they actually purchased it but only a few even asked.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文