iPhone 应用程序的应用程序内购买服务器

发布于 2024-09-10 15:44:03 字数 284 浏览 3 评论 0原文

我的公司正在寻求为 iPhone 应用程序实施大规模的应用程序内购买模式。 我们最大的问题是,我们不想使用像 Urban Airship 这样的服务,因为它不能很好地与我们的业务模式和应用程序本身的性质集成。

因此,现在我们希望建立自己的服务器来处理应用内购买通信并提供所购买的内容。我们不会解锁应用程序中已存在的内容,并将下载相对较大的附加内容。

是否有任何好的资源可以帮助您了解有关服务器端组件的更多信息。我非常熟悉 StoreKit 的工作原理,但服务器端通信对我来说是一个谜。

任何帮助将非常感激!

My company is looking to implement a large-scale In-App purchase model for an iPhone app.
Our biggest issue is that we don't want to go with a service like Urban Airship because it doesn't integrate well with our business model and the nature of the application itself.

So now we're looking to set up our own server to handle the In-App purchase communication as well as serving down the purchased content. We are not unlocking content that already exists in the app and will be downloading relatively large add-on content.

Are there any good resources for learning more about the server side component to this. I'm very familiar with how StoreKit works but the server side communication is an enigma to me.

Any help would be very much appreciated!

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

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

发布评论

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

评论(1

じ违心 2024-09-17 15:44:03

我通过对可购买内容进行简单的 plist + zip 文件下载来实现这一点。该 plist 包含可用产品的列表。应用程序的每个版本都有一个 plist 文件,就像我的情况一样,有时根据用户拥有的版本,内容会有所不同。

此方案还支持单个内容项的版本控制,因为有时您想要更改商店中的其中一项。

我不遵循苹果公司的购买然后下载指南。我是下载-购买-解锁。我对有人购买内容然后不得不等待下载感到非常紧张。 (我的内容文件非常大)。

它的工作原理如下:

  1. 应用程序为自己下载 .plist。 (MyApp_2.1.plist)
  2. 打开 .plist,检查每个内容项的版本。假设应用程序当前有内容 A 的版本 1 和内容 B 的版本 5。上面的 plist 文件告诉它当前店面应该有 A 的版本 1、B 的版本 6 和 C 的版本 7。所以应用程序下载 B 和 C 的内容。
  3. 内容存储在 zip 文件中。就我而言,这些是带有 XML 文件、音频和图形内容的游戏关卡。还有一个 .plist,其中包含该游戏级别的元数据,其中包括版本号以及该项目的 AppStore ID。该应用程序解压缩内容,然后将其作为锁定项目显示在店面中。如果用户已经购买了它,那么他们会自动获得更新的内容。如果他们购买了,我就会在那时解锁内容。

这很简单,可以使用任何 CMS(甚至是基于文件的普通 Web 服务器)来完成,并且支持跨应用程序的多个版本的多个版本的内容。

如果您想查看 UI,我执行此操作的应用程序是一款名为 Lexitect 的游戏,您可以从 UI 角度看到这一切是如何组合在一起的。 (免费)

I implemented this by doing a simple plist + zip file download for purchasable content. The plist has a list of products available in it. There is a plist file for each version of the app, as in my case there are sometimes differences in content based on the version that the user has.

This scheme also supports versioning of individual content items, since sometimes you want to change one of the items in your store.

I do NOT follow Apple's guideline of purchase-then-download. I do download-purchase-unlock. I'm too nervous about someone purchasing the content, then having to wait for it to download. (My content files are pretty big).

Here's how it works:

  1. App downloads .plist for itself. (MyApp_2.1.plist)
  2. Opens up .plist, checks to see what version of each content item it has. Let's say the app currently has version 1 of content A, and version 5 of content B. The plist file above tells it that the current storefront should have version 1 of A, version 6 of B, and version 7 of C. So the app downloads content for B and C.
  3. Content is stored in a zip file. In my case, these are game levels with XML files, audio, and graphical content. There is also a .plist with metadata for that game level, that includes the version number, and the AppStore ID for that item. The app unzips the content and then presents it in the storefront as a locked item. If the user has purchased it already, then they get the updated content automatically. If they purchase it, then I unlock the content at that time.

This is simple, can be done with any CMS (even a plain file-based web server), and supports multiple versions of content across multiple versions of your app.

If you want to see the UI, the app I did this for is a game called Lexitect, you can see how it all is put together from a UI perspective there. (It's free)

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