StoreKit返回无效的产品标识符-仅在真实的App Store中，仅在iOS7中 [英] StoreKit returns invalid product identifiers - only on the real App Store, only on iOS7

问题描述

我们有一个应用程序可以查询StoreKit以获得正常的产品详细信息(您可以忽略它是Xamarin应用程序，除非Xamarin中存在错误，否则不会有所作为):

We have an App that queries StoreKit for product details like normal (you can disregard that it's a Xamarin App, it shouldn't make a difference unless there's a bug in Xamarin):

        var request = new SKProductsRequest( new NSSet( ... ) );
        _runningRequests.Add( request );
        request.ReceivedResponse += HandleReceivedResponse;
        request.RequestFailed += HandleRequestFailed;
        request.RequestFinished += HandleRequestFinnished;
        request.Start();

    // ....

    void HandleReceivedResponse( object sender, SKProductsRequestResponseEventArgs e )
    {
        ViewModel.IsProcessing = false;

        foreach (var item in e.Response.InvalidProducts)
            Console.WriteLine( "Invalid product: " + item );

        var products = e.Response.Products.Select( x => new InAppProductViewModel( x.LocalizedTitle, x.ProductIdentifier, x.LocalizedDescription, LocalizedPrice( x ), IsPurchased( x ), () => Purchase( x ) ) );
        var vms = products.ToList();

        ViewModel.UpdateProducts( vms );
    }

会发生什么:

• 在沙盒/测试环境中，我们可以在iOS 7和iOS8设备上查询商品ID并获得正确的响应
• 该应用通过了审核，我们已经成功销售了商品，因此它对某些用户有效.
• 但是，我们有客户报告说他们无法在我们的In App Store中看到任何东西.他们都拥有运行iOS 7设备的共同点.我们可以重现该问题-在控制台上App Store上发布的版本中，我们看到传递给 SKProductRequest 的每个标识符的输出无效产品ID".标识符与我们在代码中指定的完全匹配.

• In the Sandbox/Test environment we can query product ids just fine and receive proper responses, on iOS 7 and iOS8 devices
• The App passed review, we're already successfully selling items, so it's working for some users.
• Yet, we have customers reporting that they are unable to see anything in our In App Store. They all have in common that they're running iOS 7 devices. We can reproduce the issue - with the version released on the App Store on the console we see the output "Invalid product id" for each identifier we pass into the SKProductRequest. The identifiers match exactly what we specified in code.

这似乎仅在实时AppStore环境中的iOS 7设备上发生.我认为他们通过iTunes更新或其他方式破坏了iOS 7上的In App Purchase.沙盒环境没有显示问题真的很奇怪.我们已经在多个设备和多个iTunes帐户上进行了测试，并且安装了该应用的全新安装.客户也遇到了这些问题.

It appears this only happens on iOS 7 devices, in the live AppStore environment. I assume they have broken In App Purchases on iOS 7 with an iTunes update or whatever. It's really weird that the Sandbox environment doesn't show the issue. We tested on multiple devices and multiple iTunes Accounts, with clean installs of the App. Customers are having these problems too.

我已经与Apple开发人员技术支持和iTunes提供商支持一起工作，他们无法/不愿意与工程团队一起诊断问题.因此，在此处提出此问题以查看是否有人遇到相同的问题，或者是否可以使用其App进行检查.我们已经等待了超过24小时才能进行产品更新"，该更新应该可以解决该问题，但事实并非如此.

I have already worked with Apple Developer Technical Support and iTunes provider support and their unable/unwilling to diagnose the issue on their end with the engineering team. Thus asking this question here to see whether anyone else is experiencing the same issues or would be able to check with their App. We've already waited more than 24 hours for a "product refresh" that was supposed to fix the issue but it didn't.

拥有具有应用内购买"功能的应用程序的任何人都可以测试实时App Store版本是否仍可在iOS7上运行吗?

Can anyone that has an App featuring In App Purchases test whether the live App Store version still works on iOS7?

注意:就像这样超过72个小时，这表明它不是像这样的临时temporary幸:

Note: It's been like that for more than 72 hours, suggesting it's not a temporary fluke like in:

• iOS In App Purchase-无效的产品ID"；在发行版中，而不是开发版本中
• 仅在应用内购买无效的产品ID发布版本上

此后，我们已向AppStore发布了2个对该应用程序的更新，但没有一个解决问题.在iOS8上运行良好，在iOS7上运行无效的ProductIdentifiers.

We have since released 2 updates to the App to the AppStore, but none of them resolved the problem. Works great on iOS8, invalidProductIdentifiers on iOS7.

这是我们从应用程序中获得的控制台输出(略微修改了日志记录).可能是 TASK-ASSERT 错误提示，但我找不到关于该错误的任何信息.

This is the console output that we get from our App (slightly amended the logging). What could be a hint at something going wrong is the TASK-ASSERT error, but I couldn't find any info on that one.

Mar 10 08:08:28 iDevPad01 itunesstored[832] <Error>: TASK-ASSERT: cfurlcache - ProcessCacheTask - FAILED to get task-assertion, going commando with 1 items to process.
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Received SKProductResponse, debugdescription: <SKProductsResponse: 0x1776d950>
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Received SKProductResponse, description: <SKProductsResponse: 0x1776d950>
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Received SKProductResponse, products: 0
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Invalid product: coach
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Invalid product: boat
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Invalid product: com.rowinginmotion.mobile.boatapp.ios.solo.boat
Mar 10 08:08:28 iDevPad01 RowingInMotionMobileBoatAppiOSSolo[855] <Warning>: Invalid product: com.rowinginmotion.mobile.boatapp.ios.solo.coach

三天前，我们提交了支持DTS事件，并终于得到了回复.他们同意我们的观点，这似乎是处理InApp购买的iTC网络服务中的内部问题.我将使该线程保持最新状态.

We filed a support DTS incident three days ago, and have finally heard back. They agree with us that it appears to be an internal issue in the iTC web service that handles the InApp purchases. I'll keep this thread up to date.

推荐答案

好消息-Apple终于弄清了问题的原因.似乎Xamarin.iOS在构建过程中开始将 iTunesMetadata.plist 文件添加到App捆绑包中(即使我们不构建IPA也不是通过xcode档案进行部署).

Good news - Apple finally figured out what the cause of the issue. It appears that Xamarin.iOS started adding an iTunesMetadata.plist file to the App bundle during the build process (even though we're not building IPAs and deploy via xcode archives).

报价我们的iOS支持工程师:

Quoting our iOS support engineer:

问题似乎是，在您上载到iTunesConnect的可交付资产中，有一个恶意iTunesMetadata.plist"，在iOS 6/7下可以运行的其他应用程序购买应用程序中没有该"rogue iTunesMetadata.plist".这里的问题是，当应用程序从商店安装到设备时，应用程序中会内置相同的文件.由于此文件已存在于应用程序捆绑包中，因此未使用StoreKit安装的文件.这是有问题的原因，因为iTunesMetaData.plist缺少通常在调用SKProductsRequest时生成的fetchSoftwareAddOns URL请求中通常包含的2个字段值.

The issue appears to be that in the deliverable asset which you uploaded to iTunesConnect, there is a "rogue iTunesMetadata.plist" which is not present in other in app purchase apps that do work under iOS 6/7. The issue here is that there is the same file that is built into the app when the app gets installed from the Store to the device. Because this file is present in the app bundle already, the one the StoreKit installs isn’t used. The reason this is a problem is that the iTunesMetaData.plist is missing the 2 field values that are normally included in the fetchSoftwareAddOns URL request that is generated when the SKProductsRequest is called.

作为临时的解决方法，我修补了"_CompileITunesMetadata" msbuild任务，以防止生成iTunesMetadata.plist

As a temporary workaround, I've patched out the "_CompileITunesMetadata" msbuild task to prevent generation of an iTunesMetadata.plist

  <Import Project="$(MSBuildExtensionsPath)\Xamarin\iOS\Xamarin.iOS.CSharp.targets" />
  <!-- NOP out CompileITunesMetadata task, which creates a rogue metadata plist file that can break In App Purchases on iOS7 -->
  <Target Name="_CompileITunesMetadata" DependsOnTargets="_DetectSdkLocations;_DetectAppManifest;_GenerateBundleName;_CompileAppManifest">
     <Message Text="Skipping CompileITunesMetadata task, which creates a rogue metadata plist file that can break In App Purchases on iOS7" />
  </Target>

我们的iOS支持工程师向我指示，iTunesConnect可能会内置验证例程，以防止/拒绝包含流氓 iTunesMetadata.plist 的App提交，因此希望其他人不会对此怪异的东西打中行为.

Our iOS support engineer indicated to me that iTunesConnect may build in validation routines to prevent/reject App submissions that contain a rogue iTunesMetadata.plist, so that hopefully others won't be hit by this weird behavior.

这篇关于StoreKit返回无效的产品标识符-仅在真实的App Store中，仅在iOS7中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！