Updating to PolySpatial 0.5.0 required me to update Unity from 2022.3.9 to 2022.3.12, which revealed a number of Unity platform issues that have been introduced in the interim:
- (IN-59580) Some native plugins (including .m/.h/.a/etc files) are not added to the Xcode project. It turns out this is due to a change in VisionOSBuildPostProcessor.IsPluginCompatibleWithCurrentBuild introduced in 2022.3.11 – it isn’t handling a plugin having a CPU setting of “” any more. This is often the default, as the inspector will show either “Any CPU” or “ARM64” in for VisionOS by default, and will not write a CPU setting to the .meta file unless this is changed. This can be worked around by manually setting the CPU to something, saving the asset, then reverting and saving.
- Now that the Xcode project is written to Unity-VisionOS.xcodeproj, PBXProject.GetPBXProjectPath doesn’t work as an API, and needs to be obsoleted and replaced with one that takes the build target as an argument.
- The simulator project adds the linker option
all_load. This option affects all libraries, including 3rd party libraries that we have no control over. In my case, it causes the Wwise library to fail to build. Instead, Unity can use
-Wl,-force_load,Libraries/libil2cpp.a to achieve the same effect while limiting the fallout. Alternatively, since the device build does not require this linker flag, I suspect the simulator build could be refactored to also not require different/special linking flags.
The new workflow requiring separate builds for simulator vs device is also unfortunate and slows down development unnecessarily. I feel like a better solution would have been to provide a VisionOS_x64 target instead, so that a single ARM64 build can continue to work on both device and simulator, while still supporting Intel Mac users where needed.
Thanks, @Alex_StudioDrydock, you just saved me a lot of time! None of my native libraries were included anymore, but changing the CPU, saving and reverting fixed the issue.
+1 for the option to have one build for device and arm64 simulator. The solution in 2022.3.9 was great where there was one single export for both. Afaik Xcode 15.1 anyways requires an Apple Silicon chip for visionOS development so maybe supporting x86_64 for visionOS won’t be needed if Apple doesn’t support that architecture in the future.
+1 to a resolution for PBXProject.GetPBXProjectPath not working correctly. This is something we rely on for our build process at present.
Also +1 for the single export option, this is also slowing things down for us as we’re working on the Simulator and device concurrently.
Another +1 for the the single build. Since there are currently differences on simulator and device, regularly things have to built twice, its a pretty big it in dev time.
Is this workaround still working with Polyspatial 0.6.2 or did you find another solution to include native plugins? I tried the workaround and they still are not added to Xcode unfortunately.
Yes, it still works (relates to Unity version, not PolySpatial). Check that the corresponding .meta file has the right CPU and platform under
I actually have the same values in the .meta file like:
I tried folder structures like
Assets/Plugins/VisionOS/NativeCallProxy.h and none of them works. The strange thing is, they even show up in the Xcode inspector, but the files are not there in Finder.
Looks like you’ve built with “Symlink Sources” checked – the files in Xcode are linked to the actual files in your Unity project, and just the folder references are messed up (which shouldn’t matter).
If you need the files copied into the Xcode project folder instead, uncheck “Symlink Sources”.
Oh, you just saved me a lot of time copy pasting stuff - thank you, it works!
How exactly did you do that? I set the CPU to “Any” and back to “ARM64”, but still my files won’t show up in the Xcode build. Also tried to place them in a folder named “VisionOS” and even “visionOS”, but that didn’t work either.
For me, the .meta file shows:
but they still don’t show up in the Xcode project. 2022.3.13f1
I did like @Alex_StudioDrydock suggested:
This can be worked around by manually setting the CPU to something, saving the asset, then reverting and saving.
You need to save after both changes to make it work. Not sure you’re facing the same problem, though. My meta file looks the same.
Thanks. I had tried this, but without luck.
Is there any way to force unity to always add -Wl,-force_load,Libraries/libil2cpp.a?
Not to my knowledge, I have a step in my build postprocessor that applies a regex to the .pbxproj file:
Regex.Replace(s, ",-all_load", $",-force_load,Libraries/libil2cpp.a")