I’m having a heck of a time with the plugin importer in Unity 6. It seems like it’s broken in so many different ways.
Like, it’s always been somewhat broken, but it’s super broken now.
For context, I’m working on an asset with a native plugin that has a macOS version (Intel + Apple Silicon), and a Windows version in x86, x64 and ARM64. This seems like a fairly normal thing to be doing. Users would expect all these to work.
Due to the number of settings involved, I want to use an editor script to get all the plugin importers and set the various platforms and settings. Right off the bat, if this script runs with [InitializeOnLoad], it breaks. I think it’s running before the editor is ready so the meta files are never produced and the editor really doesn’t like that. Annoying, but okay I’ll just run it manually.
So, if I trigger it to load with a menu item, it works a bit better, but depending on when and where I’m running it, the editor will decide to ignore some of the settings entirely, depending on what platform I’m running on.
So, set it up manually in the inspector. Well, I can pretty easily get into a state where, for example, the x64 importer will not let me set the Standalone CPU to x64. It’ll just jump back to Any CPU. No errors or warnings or anything. I hit apply and it resets.
Let’s talk about Any CPU. Any CPU on Windows is nonsensical. To my knowledge, and unlike, say, macOS, you cannot bundle the various architectures into one DLL. So this option is pointless.
Also, why is there an x86 checkbox and then immediately below it a CPU dropdown for x64 and ARM64? They should all be in the dropdown.
The default import behavior is bonkers. It seems to just apply all platforms and all CPU architectures. This creates all kinds of problems. For one, if the editor decides it doesn’t like the importer settings (which can happen on a whim such as an editor restart). Now it blows up about multiple plugins with the same name existing. A much more sensible default is to disable for all platforms and editor—because Unity seems unable to guess. So, let the user turn things on. (Speaking of which, isn’t there a header in the DLL you can check so Unity can guess?). There is no world in which DLLs should be included for macOS, tvOS, iOS, most consoles, etc. so why default to this?
“Any OS” for editor settings is nonsensical in most cases—especially as a default. “None” would at least make sense (considering the all platforms default) and that doesn’t exist. The whole platform selection as a bunch of checkboxes is nonsensical. They’re almost all mutually exclusive, except for Editor and Standalone. It really should be a drop down with Windows, macOS and Linux broken out separately, and have an Editor checkbox for those three in the platform settings. Too late now, I guess.
x86 is not allowed in the Editor. If it was selected in earlier Unity versions or set through an editor script, then just ignore it or at least unset it. Don’t set to wrong defaults.
Running Unity in Windows, it refuses to believe macOS exists as a platform when set through an editor script. I’m using:
pluginImporter.SetEditorData( “OS”, “OSX” );
This works on macOS, but not Windows. There’s no error, but the resulting meta file for the plugin is empty except for fileFormatVersion and guid. No error in console… although click on the plugin and woah…
As I type this I’m looking at the editor spewing the following two errors on repeat while the macOS plugin is selected:
[Worker0] Could not generate preview image
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
[Worker0] Import Error Code:(4)
Message: Build asset version error: assets/TestPlugin/plugins/macos/TestPlugin.bundle in SourceAssetDB has modification time of '2024-04-08T17:00:18.7728406Z' while content on disk has modification time of '2024-04-08T18:23:58.1885264Z'
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
What are these? Who knows? Who cares? I’ve seen similar errors running Unity on macOS clicking on plugins. Click away, click back on the plugin and no errors. But changing settings may not be possible anymore. At this point it’s all blurring together and I don’t know what’s causing what anymore.
And these are just some of the things I’ve been running into.
Compounding all this is a common situation with Unity upgrades. So, for example, if I release the plugin for Unity 2021 LTS and set up the importer settings to the best of my ability. Someone uses the plugin and then upgrades Unity… chaos ensues. In the past, with InControl, I’ve published for every Unity LTS and even some old versions just so if someone imports, they would have reasonable plugin importer settings. This mostly works, but all goes out the window with a Unity upgrade. It’s especially bad when there’s a new architecture (Apple Silicon or ARM64) where the older Unity version doesn’t know about it. It sure would be nice if Unity just gracefully ignored plugin settings it doesn’t understand and didn’t just overwrite them with bad defaults.
Sorry to gripe, but I just really hope someone gives the plugin importer a long hard look and tries to make it a stable and sane experience for both users and asset developers. If I can’t even get it working for myself, how am I going to get it working for customers?
