使用新的显式应用程序 ID 和应用内购买更新了应用程序。 SKProductsRequest 返回空产品列表
背景：
我的应用当前的待售版本使用通配符应用 ID，且捆绑包 ID 很简单，不符合 com.companyname.appname 约定（这只是“应用程序名称”）。它使用的应用程序 ID 的形式很简单，即“bundleseed.*”，我相信在使用配置文件签名时会生成“bundleseed.appname”。 （为什么？因为这个应用程序自 2.x 早期以来就已存在，早在 Apple 推荐显式应用程序 ID 之前，并且在 XCode 引入 com.companyname 约定之前。）
我正在向该应用程序添加应用程序内购买，这需要显式应用程序 ID应用程序 ID。我已按照技术问答 QA1680 从通配符更新中的说明进行操作应用程序 ID 到显式应用程序 ID。结果是我有一个新的显式应用程序 ID，格式为“newbundleseed.appname”，并且用于签署应用程序的新配置文件指定了这一点。 info.plist 中的捆绑包 ID 保持相同的“appname”。
问题：
当我从 XCode 部署新应用程序到旧版本之上时，它似乎工作正常。旧版本应用程序实例已替换为新应用程序，并且所有新功能均已到位。 但是，当应用提交 SKProductsRequest 时，它会生成一个空的产品列表。如果我将新应用部署为全新安装（而不是复制旧版本），那么一切都会按预期工作 - SKProductsRequest 结果在我可用产品的完整列表中。
我还注意到升级后的版本继承了旧版本的某些方面，这对我来说很奇怪。具体来说，旧版本的应用程序有一个 default.png，新应用程序尚未将其作为构建的一部分，但升级后的应用程序在加载时会显示旧的 default.png。升级后的应用程序就像是新旧应用程序的合并。
我最关心的是应用内购买是否适用于我的升级用户。我是否对显式应用程序 ID 做错了什么，或者这只是我使用应用程序内购买沙箱的问题？在这种情况下，我如何确信它在发布后会起作用？
另外，关于新应用程序为何/如何似乎没有完全取代旧应用程序包的任何见解？
我唯一能想到的是，我应该在创建新的 App ID 时使用旧的捆绑包种子，而不是生成新的捆绑包种子（如 QA1680 中详述）。即旧的应用程序 ID 是“oldbundleseed.*”，我当前的新应用程序 ID 是“newbundleseed.appname”，也许应该是“oldbundleseed.appname”。但我无法执行此操作，因为配置门户不允许我创建仅因捆绑包种子而不同的应用程序 ID。如果这是我的问题，该怎么办？联系苹果？
TL/DR：使用新的显式应用 ID 进行更新以支持 IAP 的现有应用可以正常工作，只是应用升级时 SKProductRequests 会导致产品列表为空，而全新安装会导致应用列表变空。在已填充的产品列表中。
Background:
The current for-sale version of my app uses a wildcard app ID, and the bundle ID is simple and doesn't conform to the com.companyname.appname convention (it's just 'appname'). The App ID it uses is simply of the form 'bundleseed.*', resulting in, I believe, 'bundleseed.appname' when signed with the provisioning profile. (Why? Because this app has been around since the early 2.x days before Apple recommended explicit App IDs, and before XCode introduced the com.companyname convention.)
I'm adding In-App purchase to the app, which requires an Explicit App ID. I've followed the instructions in Technical Q&A QA1680 Updating from a wildcard App ID to an explicit App ID. The result is that I have a new explicit app ID of the form 'newbundleseed.appname', and the new provisioning profile used to sign the app specifies this. The bundle ID in the info.plist remained the same 'appname'.
Problem:
When I deploy the new app from XCode over the top of the old version it appears to work fine. The old-version app instance is replaced with the new app and all of the new features are in place. However, when the app submits a SKProductsRequest it results in an empty list of products. If I deploy the new app as a fresh install (not copying over an old version) then everything works as expected - SKProductsRequest results in a full list of my available products.
I also noticed that the upgraded build carries forward some aspects of the old version, which is strange to me. Specifically, the old version of the app had a default.png which the new app doesn't yet have as part of the build, yet the upgraded app displays the old default.png while it is loading. It's as if the upgraded app is a merge of the old and new.
My primary concern is that In-App purchase will work for my upgrade users. Am I doing something wrong with the Explicit App ID, or is this just an issue with the fact that I'm using the In App Purchase sandbox? In which case, ow can I be confident it will work when released?
Also, any insight on why/how the new app doesn't seemingly replace the old app bundle in-full?
The only thing I can think of is that instead of generating a new bundle seed (as detailed in QA1680), I should have used the old bundle seed when creating the new App ID. i.e. the old App id is 'oldbundleseed.*' and my current new one is 'newbundleseed.appname', and perhaps it should be 'oldbundleseed.appname'. But I cannot do this because the provisioning portal wont let me create an app ID that differs only by bundle seed. If this is my issue, what to do? Contact Apple?
TL/DR: an existing app, updated with a new explicit app ID as to support IAP, works fine except that SKProductRequests result in empty product lists when the app was updgraded vs. a clean install where they result in a populated product list.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你升级得怎么样了？如果您进行构建并运行，您最终会遇到应用程序未完全重写的问题。
Xcode 做出一些“优化”决定，并仅复制真正更改的文件，这会使事情变得混乱。
创建临时分发并将其下载到具有旧版本应用程序的设备。检查该临时构建是否正确枚举它。
How are you doing the upgrade? If you are do a build and run, you will end up with this problem where app is not completely re-written.
Xcode makes some "optimization" decision and copies only files that are really changed and it messes things up.
Create an adhoc distribution and download it to the device that has the older version of the app. Check if that adhoc build enumerates it properly.
您是否实现了 request:didFailWithError: 委托方法？它是 SKProductsRequestDelegate 协议所遵循的 SKRequestDelegate 协议的一部分。
我必须承认 StoreKit 没有充分记录。根据我的经验，如果 iOS 看到具有不同 appID 的同一应用程序，它的行为就好像它们是两个不同的应用程序，而不是覆盖（或部分覆盖）具有相同标题的应用程序。不过，如果您的开发设备已越狱：启动应用程序（处于有问题的状态），通过 ssh 连接到您的设备，运行
launchctl list并查看 iOS 如何在结果列表中识别您的应用程序。Do you implement the request:didFailWithError: delegate method? It is part of the SKRequestDelegate protocol to which the SKProductsRequestDelegate protocol conforms.
I have to agree that StoreKit is not adequately documented. It has been my experience that if iOS sees the same app with different appIDs, it behaves as though they are two different apps rather than overwriting (or partially overwriting) an app with the same title. Still, if your development device is jailbroken: launch the app (in its problematic state), ssh into your device, run
launchctl listand see how iOS IDs your app in the resulting list.