I have previously had a working build, but for some reason something is getting away from me on this and I just want to go back to basics and simply get a clean project to build.
I’ve been attempting to get a Polyspatial VisionOS project to build through Unity in 6.0, 6.1, 6.2 and 6.3.
I’ve tried XCode 26.2, 26.01, 15 and so on.
I’ve tried different versions of Polyspatial, VisionOS where appropriate, including a completely new project. Clearing linbraries, new build folders, replace, cleaning build folders in XCode…
Is there a version of Unity and XCode and the plugins that will work, and is the most up to date available (2.4.3 it appears)?
What are the issues your facing specifically?
If your using Unity 6.0-6.2 I’d recommend using our 2.4.3 PolySpatial packages, but anything in the PolySpatial 2.x range should work for these versions of Unity.
If your using Unity 6.3 or grater, you will need to use our PolySpatial 3.x packages.
For Xcode I think starting with Unity 6 you need to use Xcode 16 or greater.
Xcode 15 would be for 2022.3 Unity.
You should be able to use Xcode 26 with Unity 6 builds as well. I’ve been using it internally for a while and have not had issues.
The issue comes at the final stage of XCode building, where it will give me linker errors.
Currently testing in 6000.3.2f1
MacOS Tahoe 26.1
Apple VisionOS XR - 3.0.2
AR Foundation - 6.3.1
Polyspatial - 3.0.3
Polyspatial VisionOS - 3.0.2
Polyspatial XR - 3.0.2
XCore is 2.5.3 and there are some other XR things like management of course.
Apple VisionOS is enabled in plug in management for VisionOS platform.
I have tried XCode 26.2 and also 26.01 in case that made a difference and they seem to give the same issue.
I’ve attached a screenshot, but also the log.
Build Unity-VisionOS_2026-01-09T17-47-56.txt (1000.2 KB)
Hi there! Thanks for reaching out and sorry to hear you’re having trouble.
Those warnings about version mismatch are not the real issue. Something seems to have gone wrong with the IL2CPP build. I see a bunch of errors in the log like:
"_g_typeDefinitionSize19108", referenced from:
_g_Il2CppTypeDefinitionSizesTable in libGameAssembly.a[476](wly8k99rrsnl.o)
Can you please report a bug with a project attached that can replicate the issue? We’ll need to poke around in Unity/Xcode to get to the bottom of this.
Thanks!
Hey, project minus library here, as you can see it’s basically empty:
So… I wasn’t able to get that project to build. At least not in a reasonable amount of time. I canceled the first build when I saw that some shadergraph (ArnoldStandardSurface) was trying to compile 18 billion variants. That’s… very much not supposed to happen 
I think this is a bug in URP where, if no URP asset is set, we end up compiling shaders as if all keywords are active. As far as I can tell, this doesn’t have anything to do with PolySpatial or visionOS… it’s just a URP bug that, I’ll admit, needs fixing! For what it’s worth, if you do intend to use URP, you can create a settings asset and set it up in Project Settings > Graphics. That’ll also fix the shader variant explosion and should build and run just fine.
I removed the URP package from the project and was able to build it just fine. The Unity build was pretty quick and I didn’t see any of those errors in Xcode. I don’t see anything since the test scene is just a camera with a black, transparent background, but it looks like your main issue here is having the URP package in the project without actually using URP. Once I resolve that one way or the other I can build and run it on my end.
Okay, thanks for that. It being a URP issue/bug could make sense with the clean project.
However there may be a different bug here for my main project. This was the one that caused me to make a clean build for testing.
Again, ive tested different versions of unity etc, and suspect this is more a package issue. However, if i am able to get a fresh project running with URP and no issues i may be able to build it back up to where it was and isolate the issue on the way.
Does this bug make sense?
So I believe i have isolated my issues.
My original project was a combined VOS and iOS ARKit project. At various times this has built either VOS or iOS, but was most reliable before Unity 6. The insecurity issue that came up now means many older versions of unity are safe to use, so i am only able to test a limited amount, and would prefer to be on 6 in any case.
It seems that I can get a 6.0 iOS build with visionOS and polyspatial included, but the visionOS version will not build from there.
It seems i can also have a 6.3 visionOS build, with ARKit in the project, but not an iOS build.
This is due to packages not playing nice together and I can have a project that either builds to iOS ARKit or VisionOS (realitykit/polyspatial) , but not together in Unity 6.
Another complicating factor was Vivox, which appears to be completely project breaking for VisionOS in unity 6 when getting to build stage. This may also be due to ARKit in the project, but it’s hard to say.
With it being part of the MR Multiplayer template this may be something that trips up people in the future.
This is not all ideal, as while it means i now appear to be able to build, it does mean I have to maintain versions that sit in two different versions of Unity. I’ll see if plastic will play nice with branches.
To summarisie:
-
Project with both iOS and VisionOS won’t exist together in the same version of Unity, but can build from seperate ones.
-
Vivox is broken for VisionOS projects in 6, and therefore i cannot use it for my cross platform project.
Thanks for the detailed reply. The errors from that screenshot seem to be related to the Room Capture feature, which I’m not very familiar with. I’ll need to investigate a bit further.
Got it. As always, a repro project helps us track down the specific issue, but I can do a little more testing today to see if I can cause the issue. It certainly should be possible to include both packages in the same project and target iOS and visionOS. If you can’t, that’s a bug and we’ll fix it. 
I’ve heard a few other reports of this (maybe also from you? ). I’ll need to dig into this a little further as well. I’ll let you know what I find out!
Thanks for looking into those.
I test built with basically empty scenes, so it was only the presence of the packages that made the difference.
But any discoveries you can make are much appreciated.
Quick update: I’m able to repro the iOS build error, but I don’t actually need the visionOS package (or anything other than XR Management and ARKit plugin) to cause it to happen. I think the issue is caused by the Xcode upgrade, not by Unity packages interfering with each other.
Are you sure your iOS build still works in the latest version of Xcode? Of course, we’ll need to fix this on our end either way. Just trying to nail down all of the individual issues you’ve encountered here.
I’ll update again when I have more concrete info about the ARKit fix and a timeline for when it might ship.
It’s entirely possible the ARKit simply didn’t work with the XCode versions I have tried. I had used different older versions, but may have had other issues when doing so. In any case good to know there’s some root cause.
Hey again. Good news! I’ve tracked this down and I have a workaround you can try.
The issue appears to be a change in how Xcode treats the $(TOOLCHAIN_DIR) wildcard. We use it to add extra search paths to the linker command so it can find those missing libraries (swiftCompatibility51, swiftCompatibility56, etc.). Up until this point, it’s pointed to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.toolchain or the path to the default toolchain of whatever Xcode you’re using. Now, for whatever reason, it points to /var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.IND4h9/Metal.xctoolchain and a slightly different version for you. This toolchain does not contain the Swift compatibility libraries (or even the swift/iphoneos folder) so you end up with these errors.
As far as I can tell, this is a bug in Xcode, but I’m still waiting to hear back from Apple about the explanation. In the meantime, you can either hard-code the actual path to your Xcode default toolchain, or just replace the $(TOOLCHAIN_DIR)/usr/lib/swift/$(PLATFORM_NAME) added by our build postprocessor with $(DEVELOPER_DIR)/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/$(PLATFORM_NAME).
The easiest way to find this setting is to select the UnityFramework target in the project view, go to Build Settings and type search into the search field to filter it down to the setting you’re looking for. Make sure you’re not filitering the view to only Basic settings. Then you can double-click the value of Library Search Paths and make the changes needed. Hopefully a picture is better than all those words
Yes, so for 6.3 that indeed now has iOS building succesfully.
Do you expect that would also fix vivox?
Sorry, I haven’t been able to dig into the vivox issue yet. Too many irons in the fire!
If it’s a similar issue (unresolved framework symbols) it could be a fix. Although, I did a quick search for other uses of TOOLCHAIN_DIR in Unity code which would have turned up a result in the vivox plugin if they were using the same way of setting search paths. I have to clear out some other tasks first but I’ll try a build w/ their latest plugin and see what happens.
Could you start a separate thread and/or bug report for that? I can test a build but I don’t personally have a lot of knowledge about that package so I’ll need to tag in some other folks, and it’s much easier to do that if I have an official bug report to point to.
Good point—starting fresh and verifying the VisionOS SDK and build settings can often clear up Xcode build issues. It’s a similar idea to how OpenCore Legacy Patcher helps bridge compatibility gaps between older hardware and modern software.
In this end it wasn’t starting fresh that solved the main issue with Vision and ARKit sharing a project, but myschoen was able to help solve that.
So this was news to me (or maybe I forgot!) but vivox has an additional SDK package for visionOS. If you go to the cloud services dashboard and navigate to Vivox > Packages and SDKs, you can download a .tgz of the package as show in this screenshot
