Resolved StandardPurchasingModule.appStore returns AppStore.GooglePlay on iOS

Maybe there is no big use for

StandardPurchasingModule.appStore

on platforms other than Android. But I still would expect this property return correct value on all platforms. Especially, because it was renamed to have platform agnostic name.

I [tried to] use this property in

switch

statement. Of course, there are easy workarounds by checking platform at runtime or using preprocessor checks, but it makes code uglier.

Package: 2.2.1
Plugin: 2.2.4

 

I'll take a look.

 

Indeed we are aware and fixed this in IAP 3.0.0 (which is in preview) but you should wait for the official release before releasing a product in production using 3.0.0

3.0.0 is the top priority for the team right now. Although very unlikely that we will be releasing before the end of the year, I can saw that early 2021 we should be releasing the new version.

For more information: https://forum.unity.com/threads/a-c...rges-the-unity-iap-plugin-3-0-0-soon.1009678/

 

Hello,

Small change of plans, we will actually be releasing a IAP 2.2.5 soon, end of week or beginning of next week, which will contain this fix.

 

2.2.6 has this bug.

 

Sorry for the delay, I will test and confirm.

 

@amjaliks It's working for me on my iPhone 7 with IAP 2.2.6. Please share the code that you are using, and the iOS device you are testing on.

MyDebug("Store = " + StandardPurchasingModule.Instance().appStore.ToString());

Prints

Store = AppleAppStore

 

Code:

Code (csharp):

1. var module = StandardPurchasingModule.Instance();
2.  
3. string storeKey, storeName;
4. switch (module.appStore) {
5.    case AppStore.AppleAppStore:
6.       storeKey = "appstore";
7.       storeName = AppleAppStore.Name;
8.       break;
9.    case AppStore.GooglePlay:
10.       storeKey = "googleplay";
11.       storeName = GooglePlay.Name;
12.       break;
13.    case AppStore.AmazonAppStore:
14.       storeKey = "amazon";
15.       storeName = AmazonApps.Name;
16.       break;
17.    case AppStore.UDP:
18.       storeKey = "udp";
19.       storeName = UDP.Name;
20.       break;
21.    default:
22.       Debug.LogError("Unsupported store: " + module.appStore);
23.       _status = StoreStatus.Failed;
24.       return;
25. }
26. Debug.Log("Store1: " + storeName);
27. Debug.Log("Store2: " + module.appStore.ToString());

Debug output:

Code (csharp):

1. Store1: GooglePlay
2. Store2: GooglePlay

iPhone 11 Pro, iOS 14.3
Unity 2019.4.18f1
Unity IAP 2.2.6, In App Purchasing 2.2.1

 

Unfortunately I don't have an iPhone 11 to test on, I'm on 14.3 also. I'm using Unity 2020.1.6f1. Those are the only differences I see.

 

What is MD5 for Stores.dll you test?
Mine is de6502c0ff425d100606352d33096b6c.

 

Same here.

 

A freshly initialized

StandardPurchasingModule

returns an incorrect

appStore

value. It gets fixed by

ConfigurationBuilder

.

Code (csharp):

1. var module = StandardPurchasingModule.Instance();
2. Debug.Log("Store 1: " + module.appStore);
3. ConfigurationBuilder.Instance(module);
4. Debug.Log("Store 2: " + module.appStore);

Debug output:

Code (log):

1. Store 1: GooglePlay
2. Store 2: AppleAppStore

 

Ah glad you figured it out!

 

Just to be clear. I still think it is incorrect behavior and needs to be fixed.

 

Perhaps as a feature request, in the meantime just use the code you shared. Can you elaborate why this would cause issues in your code? This would help to drive priority.

 

Of course, it isn't the highest priority. But it just need to be fixed. Why should

StandardPurchasingModule.appStore

return some (not so) random and unrelated value? Make it at least to return

NotSpecified

, if it is impossible to make it to return correct one from the beginning.

I found this bug only because it created issues in my code.

It isn't a big deal. There are a couple of simple workarounds for this. But it would save me some time, while a needed to figure out, why my code worked perfectly with Google Play and UDP builds, but started to fail in iOS build.

 

Why are you not able to use the syntax mentioned above that works? We likely won't make any changes with such an easy workaround, which also may be by design.

 

Bad response. @amjaliks is correct about this being a bad behavior. The correct question is why Unity has not been able to fix this simple, yet annoying issue in such a long time... that is beyond me. And yes, this bug is still there.