问题
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.
回答1:
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.
回答2:
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 list and see how iOS IDs your app in the resulting list.
来源：https://stackoverflow.com/questions/7180782/updated-app-with-new-explicit-app-id-in-app-purchase-skproductsrequest-returns