How to programmatically enable/disable Unity IAP at build time?

What is Unity's recommended way to handle enabling/disabling IAP within the same project but across different builds?

The goal is to enable/disable IAP during the build process, for instance in OnPreprocessBuild(), or in OnActiveBuildTargetChanged()

The manual way to disable (then re-enable) IAP is described by @ap-unity in "IAP Troubleshooting - Remove and Reinstall Unity IAP". Can this be done programmatically?

Disabling the IAP might have to not even include the DLL in the final build to avoid auto-detection of IAP code by the store, which might lead to a store listing an app as containing IAP when it actually does not.

Some use cases:

• Disabling IAP in QA builds
• Enabling IAP in one Store (ex: Apple) but disabling in another (ex: Android)
• Free/Paid version of an app (IAP disabled) vs IAP version of the app

Thanks

 

Hey @JeffDUnity3D, we actually do what you suggest to enable and disable IAP from code when building for several platforms, so I can chime in.

I strongly believe there is something wrong with the compilation of the UnityPurchase package. We've always had problems with enabling or disabling the IAP, even manually in the inspector (i.e. not from code), such as errors that won't go away until the UnityPurchasing folders are reimported, or until we restart the editor. We also commonly get errors of broken DLLs in the Bin folder (Editor.dll, Stores.dll) that we don't touch at all, when simply changing that setting.

These problems seem to be harder to reason about when using custom assembly definitions or when trying to create builds, as is our case. Actually, just trying to force Unity to compile scripts after we change UnityConnectSettings.asset is not exactly smooth sailing, since there seems to be a bug in the compilation.

I've submitted a bug report (case 1136555) but I'll reproduce the text contents here:

-----------------------------------------------------------------

1. What happened

When trying to enable/disable the IAP system from code, we found a compilation problem with UnityPurchasing, where at a specific point some assemblies see the UNITY_PURCHASING define enabled and others disabled.


2. How we can reproduce it using the example you attached

The project runs the most up to date IAP system version, 1.20.1 and contains the imported UnityPurchasing system (UnityChannel and UnityPurchasing folders in Plugins) and a single editor script in Editor/Commands.cs. This script sets two menu items on the top Unity toolbar, under "Commands". IAP is enabled in the Services window.

NOTE: You may need to log into your organization in the Services tab and create a project for this, enabling IAP afterwards. The example project uses our info.

1. Go to Commands in the top bar and select "Write UnityConnectSettings". This reads the UnityConnectSettings.asset file and writes it back EXACTLY as it was. It will print to the console.

2. Nothing happens since we haven't forced scripts to recompile, so open Commands.cs and comment out [MenuItem("Commands/Dummy!")]:
// [MenuItem("Commands/Dummy!")]

3. Return to Unity.

4. Commonly, a dialog appears saying "Compiling scripts", which finishes very quickly. Go to "Commands" at the top, you should see that the Dummy command is gone, as expected, and there are no errors. If the dialog does not appear (it can happen), go to step 6.

5. Return to Commands.cs and uncomment [MenuItem("Commands/Dummy!")] again.

6. Unity will recompile (now without the dialog) and you will get a warning that is defined at the top of Commands.cs and appears when UNITY_PURCHASING is disabled:
Assets\Editor\Commands.cs(6,10): warning CS1030: #warning: 'UNITY_PURCHASING is disabled! (but is it really...?)'

7. Change something in Commands.cs again and the warning will go away because UNITY_PURCHASING is enabled for this assembly (Assembly-CSharp-Editor) from this point on.

The problem is that IAP was actually always enabled throughout this process, and the UnityPurchasing folder seems to think so too, since PurchasingCheck.cs prints this in case it isn't: "Unity IAP plugin is installed, but Unity IAP is not enabled. Please enable Unity IAP in the Services window."

-----------------------------------------------------------------

I'd also like to add that the IAP system still causes warnings on an empty project:

> Assembly: 'Assets/Plugins/UnityPurchasing/Bin/Stores.dll' uses obsolete Unity API (UnityUpgradable)
> Assembly: 'Assets/Plugins/UnityPurchasing/Bin/Editor.dll' uses obsolete Unity API (UnityUpgradable)
> Finished updating scripts / assemblies
> Assets\Plugins\UnityChannel\XiaomiSupport\Editor\AppStoreSettingsEditor.cs(36,18): warning CS0649: Field 'AppStoreSettingsEditor.ReqStruct.currentStep' is never assigned to, and will always have its default value null

Daniel

 

Updated the text with the case number.

 

Would this help in addition to the bug report from the editor? I ask because the Project dropdown in that link doesn't seem to show the project I created for the example project, which is called "Change IAP setting from code" and although the problem can happen in any of our projects I would like to keep it simple for the team and not ask for support for a much more complicated project.

The "Change IAP setting from code" shows just fine in the organization's project list:

 

I noticed there was no way to attach files in the support ticket. I will send it with the code in the body.

I'll leave it here too. The code is the following, on a Commands.cs file (inside an Editor folder):

Code (CSharp):

1. using System.IO;
2. using UnityEditor;
3. using UnityEngine;
4.  
5. #if !UNITY_PURCHASING
6. #warning UNITY_PURCHASING is disabled! (but is it really...?)
7. #endif
8.  
9. public static class Commands
10. {
11.     private const string filePath = "ProjectSettings/UnityConnectSettings.asset";
12.  
13.     [MenuItem("Commands/Write UnityConnectSettings")]
14.     public static void WriteUnityConnectSettings()
15.     {
16.         string content = File.ReadAllText(filePath);
17.         File.WriteAllText(filePath, content);
18.         Debug.Log("Wrote file at " + filePath);
19.     }
20.  
21.     [MenuItem("Commands/Dummy!")]
22.     public static void Dummy()
23.     {
24.     }
25. }
26.  

 

@JeffDUnity3D I submitted the ticket using the green button but it didn't confirm the sending. It actually left me in the same page but now displaying this:



The grey button doesn't seem to change even after changing fields. I don't know if it actually sent anything.

Nevertheless, everything is here in this thread. If you need the project for clarity let me know.

 

Fantastic, thanks for looking into this!

 

Hello @JeffDUnity3D. Are there any updates about this?

We are going mad with this issue. It breaks our build process -- building for all platforms one by one -- because after changing the IAP setting from code (we disable IAP for desktop builds) it usually fails the next compilation.

Reimporting scripts in certain assemblies works, but only under specific circumstances, since the Unity IAP must fail a compilation before we can reimport a script to fix it. It's really strange. We have wasted many days over the issues with the IAP system...

Daniel

 

I don't know if this is the same issue, but I managed to hack the IAP to not be included for certain platforms but to be included with other platforms. Not sure if this is what OP wanted but here goes:

1. #if define out all calls to UnityEngine.Purchasing for the platform you want to exclude in your own code. (Obviously.)
2. In Plugins\UnityPurchasing\script\*.cs #if define out every file for the platform you want to exclude.
3. In Plugins\UnityPurchasing\Editor\*.cs #if define out every file for the platform you want to exclude.
   
4. In \UnityPurchasing\Bin\*.dll and every subdirectory, exclude for your platform. Press Apply.
5. BEWARE: In \UnityPurchasing\Bin\Facebook\*.dll and Facebook\live\*.dll exclude for your platform. Press Apply. If a dialog asks you to apply changes again, hit Revert. (There seems to be some Editor Script the likes to change these settings out from under you.)
6. Go back and double check all the DLLs under Facebook are excluded for your platform and not magically turned back on.
7. Select a file to make sure the inspector is no longer on a DLL under Facebook (as the magic script will run as long as the inspector is open.)

I can now build for one platform with IAP and another platform without IAP (and actually I completely disabled Facebook too for the non-IAP platform as I didn't need it. Similar steps of excluding FacebookSDK plugins.)

 

The IAP compilation issue that I reported more than a year ago (issue 1136555) is still open and seems to have got no updates!

We have lost dozens of hours working around this in our custom build pipeline (it now involves restarting Unity twice before AND after a build for a certain platform, to guarantee that all assemblies see the correct state of the IAP system) and we STILL encounter it in other random situations where we don't even touch the setting.

Can't anything be done, @JeffDUnity3D? I generally have only good things to say about the Unity team's response to bug reports, and from all my dozens of reports over the years, this is the only one that is still open.

@DoomGoober solution may work for some users (thank you, by the way!) but not for us, since we have macOS builds for the App Store and other macOS builds for release elsewhere that don't use IAPs, among other problems. Besides requiring changes to your package's scripts, at best it would need us to activate a custom define for some builds, always leave the IAP system enabled in the connect settings, and get IAP dlls included on some builds that don't use them.

 

Bump! @JeffDUnity3D Any news?

I just found out there is another issue that I feel is related to this problem. (Mine's here.)

 

I noticed that this problem is tracked as a known issue in 2019.4.x release notes, but not in 2020.1.x.

However, the problem is still is present in both, right?

 

The last remaining IAP known issue disappeared from the release notes in 2020.1.6f1, but the notes don't say anything about a fix. 2019 also has only one of the two IAP "known issues" now. Has anything changed? Thanks!

 

Hi Jeff, I'm referring to these 2:



They were marked as known problems some versions ago, but by now both disappeared from 2020's release notes and only one is present in 2019's, and I'm not aware if any fixes exist already since I don't see anything in the notes of the version where they disappeared. We are still using 2019.4.8f1 for now. (Although the second issue may be an issue for the IAP package itself, perhaps.)

 

We do have another issue (probably) related to the first, where we can't build for iOS on our macOS machine because although IAPs are enabled in the services menu, UNITY_PURCHASING is still seen as disabled for some assemblies when we build, so it's impossible to complete the build.

 

Sorry, I didn't see your reply until now. We don't usually build on macOS (our work machines are Windows) but in this case it would help. We gave up for the time being and have no time right now for a reproduction project. If we ever try again we'll let you know. I suspect the other issues may be related to this.

As for the details:
- We were building in the Editor and the errors were in the Editor, not related to Xcode.
- We probably won't update IAP until we see the assembly fixes in the release notes, for fear of getting problems in other things, of which there have been some, so we're on 1.23.4.
- At the time we were using Unity 2019.4.10, LTS.

I'm not able to provide more info at this time.

 

Hey @JeffDUnity3D, I submitted a bug report on Windows (case 1301448). The newest version(s?) of the IAP system are worse than before. Now we just can't create builds or recompile without getting errors. That was maybe what we were seeing on Mac before. Reproduction is really simple, too.

Just have a script in an assembly definition that references classes in the UnityEngine.Purchasing namespace. For example:

Code (CSharp):

1. #if UNITY_PURCHASING
2. using UnityEngine.Purchasing;
3.  
4. public abstract class ScriptThatUsesIAP : IStoreListener
5. {
6.     public virtual void OnInitialized(IStoreController controller, IExtensionProvider extensions)
7.     {
8.     }
9.  
10.     public virtual void OnInitializeFailed(InitializationFailureReason error)
11.     {
12.     }
13.  
14.     public virtual PurchaseProcessingResult ProcessPurchase(PurchaseEventArgs args)
15.     {
16.         return PurchaseProcessingResult.Complete;
17.     }
18.  
19.     public virtual void OnPurchaseFailed(Product product, PurchaseFailureReason failureReason)
20.     {
21.     }
22. }
23. #endif
24.  

Let it compile. If you get no errors that's okay. Just make a change to the script like adding a new line and you will get errors that say that IStoreListener cannot be found. Same if you build for a platform, since it causes a recompile. Asmdef files are supposed to see precompiled assemblies, so this should never happen.

Btw, both the IAP installed from the Services window and the one in the package manager are the most recent ones. I'm not sure which one does what, but yeah.

We have been dealing with this for 2 years, but now it's really worse than before and reproduction is easy. Maybe this will help solve this. Please do not ignore this error. We have lost countless hours due to IAP compilation problems...

 

Thanks a lot, Jeff. Please let me know if anyone finds anything. This has always been a weird problem.

Happy holidays to you and the team, if applicable.

 

I have so many questions... Let's see.

1. Upon opening the project I immediately got the usual

, which is a temporary error we've learned to ignore in our project (not sure what consequences it has). Why does it happen?

2. Do you have access to my report (case 1301448) to compare with yours? I didn't want to place the project here in case the services connection leaks something.

3. When I said "Just have a script in an assembly definition that references classes in the UnityEngine.Purchasing namespace", I meant the script references the classes (i.e. uses them), not that the assembly definition gets a reference to the IAP package from the package manager. I realize now that that wasn't clear.

4. Now the really important part. For the love of all that is sacred, since when is the UnityEngine.Purchasing asmdef reference required in the custom assembly? Was it always needed? We have NEVER used this reference AFAIK. It always works in the editor and in builds without that reference. Errors happen in some situations like disabling IAP by writing the UnityConnectSettings.asset file (a bug that I believe is now fixed), or in the editor recompilation after a build, or sometimes after adding a new assembly or something similar. In my bug report project you can see that even without that reference to UnityEngine.Purchasing there are no errors in the editor UNTIL a build or recompilation happens. I was always under the impression that no references were needed... For years.

5. In your project, if the asmdef reference is not present, I simply can't get it to compile, which I suppose is the EXPECTED behaviour that we never saw. I found no differences to my bug report project (same asmdef settings, IAP enabled, same IAP versions, equivalent files) but something is definitely different. I just don't know what...​

This all got confusing from the point where 2 different things receive updates: the plugin installed from Services and the package from the package manager. If the reference has always been required then something may be wrong with the compilation process, which has always allowed us to use IAP in some situations without the reference being there. This is really strange.

 

No problem, it seems ok!

3. I figured that that sentence may have been why you added the assembly reference while I didn't. Maybe not, but I wanted to clarify.
4. That is the weirdest thing. It may very well be "required", and it could make sense, but before we could definitely compile without the reference. That may have set us off in the wrong direction with the wrong assumptions. I'd have a very bittersweet laugh if I find after all these years that when we DON'T get compilation errors is the time when Unity is wrong, and not when we do.
5. Yep, but in that case I always get the errors and maybe that isn't a problem. Restarting doesn't help either, unlike in my project. In my project, errors are only there after a build/recompilation, which is different and more like what we see in our actual full project.

 

@JeffDUnity3D Happy new year! Please let me know if you have more info about this.

Some provisory tests we did at work didn't generate any compilation errors as long as we use the reference to the UnityEngine.Purchasing dll. We'll let you know if this changes.

This is amazing if it is the source of all our problems but we still want to understand what is causing Unity to NOT report errors without the reference. That should definitely be fixed.

 

@JeffDUnity3D Yeah, I mean compilation errors of the type that block the build from happening, or that forced us to restart Unity probably hundreds of times to magically fix them.

I didn't notice if the "Could not load signature" error happened after the upgrade, but either way it didn't seem to cause problems before. But since it happened on your repro project it probably happens here too.

 

I am experiencing similar issues, I need to build 2 different products from the same repo, one product includes IAP and the other one doesn't. I modify UnityConnectSettings.asset just like you do and I also delete Assets/Plugins/UnityPurchasing at PreProcessing for the product without IAP.

Code (CSharp):

1. #if UNITY_PURCHASING

still returns true when the IAP folder is deleted, because is defined in the package I guess.
Is there any other similar Define I can check against, that would be false when the Assets/Plugins/UnityPurchasing folder is deleted? That would help with some of my issues

 

@arnaldoGaroto
Sadly I don't know of anything you can do. There isn't an option to disable IAP programmatically, so as far as I know the only way to do it is as you say and then somehow deal with the fact that all hell breaks loose and some assemblies will still see UNITY_PURCHASING enabled. We had to resort to making a Python script that restarts Unity about 4 different times to make a single build, to "ensure" that everything is compiling as expected between builds for different platforms.

@JeffDUnity3D
1. Are there any news about my previous issue? (although the UnityPurchasing reference seems to have fixed it, this still shouldn't happen and indicates a possibly larger problem)
2. Just yesterday we updated the IAP system and even though we now reference the UnityPurchasing assembly and do everything correctly, we still had to restart Unity twice to fix the compilation errors after the update. We are so tired of these errors!
3. And... can we please get a way to programatically disable IAP in the editor? Please please please?

 

OK, got it. Is that the version that will unify the "In App Purchasing" package from the Unity Registry and the one imported from the Services window, which lives in the project's assets?