VisionOS 0.7.1 | Unity 2022.3.16f1 Xcode Build Error

The new release notes mention that foveated rendering will not work until the project is using 2022.3.16f1, which will be released later this week… But 2022.3.16f1 is currently available in Unity Hub for Silicon.

When attempting to build with 2022.3.16f1 and 0.7.1 for Simulator, we get an error “UnityMain.swift:64:100 Cannot find ‘VisionOSEnableFoveation’ in scope” in Xcode.

Are there any changes we need to make to enable foveated rendering, and will there a be a different version of Unity released later this week that is required?

Hey there! Sorry to hear you’re having trouble. This variable should be defined in a new Swift file created by the build postprocessor in com.unity.xr.visionos. Was this an append build, by any chance? I’ll see if I can replicate this behavior on my end, but in the meantime you should be able to just define that variable or replace it with false for simulator builds.

Thanks for the quick reply! I actually might have been mistaken about some things… I tried rebuilding and actually got some errors within Unity itself. It still generated an Xcode project, I might have seen that last time and opened it without checking Unity first to make sure the build completed.

I’ll post the Unity error below, we’ve had a couple engineers see it now with this configuration. Upgrading Unity to .16 from .11 and the VisionOS package upgrade were the only changes, previously this project was building successfully on .11/0.6.3:

Building Library/Bee/artifacts/iOS/AsyncPluginsFromLinker failed with output:
UnityEditor.Build.BuildFailedException: Burst compiler (1.8.11) failed running

Overriding backend due to platform constraints : 'burst-llvm-10'
Starting 1 library requests
Error: xcrun: error: SDK "xros" cannot be located


  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunProgram (UnityEditor.Utils.Program p, System.String exe, System.String args, System.String workingDirectory, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser) [0x001f7] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:1910 
  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunManagedProgram (System.String exe, System.String args, System.String workingDirectory, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser) [0x0003f] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:1787 
  at Unity.Burst.Editor.BurstAotCompiler+BclRunner.RunManagedProgram (System.String exe, System.String args, UnityEditor.Scripting.Compilers.CompilerOutputParserBase parser) [0x00000] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:1762 
  at Unity.Burst.Editor.BurstAotCompiler.OnPostBuildPlayerScriptDLLsImpl (Unity.Burst.Editor.BurstAotCompiler+BurstAOTSettings settings, UnityEditor.Compilation.Assembly[] playerAssemblies) [0x0097c] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:884 
  at Unity.Burst.Editor.BurstAOTCompilerPostprocessor.DoGenerate (UnityEditor.Compilation.Assembly[] assemblies) [0x00013] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:330 
  at Unity.Burst.Editor.BurstAOTCompilerPostprocessor.GenerateNativePluginsForAssemblies (UnityEditor.Build.IGenerateNativePluginsForAssemblies+GenerateArgs args) [0x0007d] in ./Library/PackageCache/com.unity.burst@1.8.11/Editor/BurstAotCompiler.cs:184 
  at UnityEditor.Modules.BeeBuildPostprocessor.GenerateNativePluginsForAssemblies (PlayerBuildProgramLibrary.Data.GenerateNativePluginsForAssembliesArgs args) [0x00050] in /Users/bokken/build/output/unity/unity/Editor/Mono/Modules/BeeBuildPostprocessor.cs:605 
  at Bee.BeeDriver.BuildRequest+<>c__DisplayClass63_0`1[T].<RegisterRPCCallback>b__0 (System.Object o) [0x00000] in /Users/bokken/build/output/unity/unity/Tools/Bee/Bee.BeeDriver2/BuildRequest.cs:66 
  at Bee.BeeDriver.BeeDriver_RunBackend+<>c__DisplayClass1_0.<ProcessRPCRequest>b__0 () [0x00000] in /Users/bokken/build/output/unity/unity/Tools/Bee/Bee.BeeDriver2/BeeDriver_RunBackend.cs:88 
  at System.Threading.Tasks.Task.InnerInvoke () [0x0000f] in <fd2d3e9b010a4ba4b3fdc0456cd6b40b>:0 
  at System.Threading.Tasks.Task.Execute () [0x00000] in <fd2d3e9b010a4ba4b3fdc0456cd6b40b>:0 
--- End of stack trace from previous location where exception was thrown ---

  at Bee.BeeDriver.BeeDriver_RunBackend.ProcessRPCRequest (Bee.BinLog.RPCActionMessage msg, Bee.BeeDriver.BuildRequest+RPCCallback rpcCallback, IPCConnection ipcConnection, System.Threading.Tasks.Task writePipeConnectionTask, Bee.BeeDriver.InternalState state) [0x000ba] in /Users/bokken/build/output/unity/unity/Tools/Bee/Bee.BeeDriver2/BeeDriver_RunBackend.cs:88 
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&) (at /Users/bokken/build/output/unity/unity/Modules/IMGUI/GUIUtility.cs:190)

Yikes! I haven’t seen those issues, either, although you should be able to work around them by disabling Burst in Project Settings > Burst AOT Settings, flipping to the visionOS tab, and disabling Enable Burst Compilation. With that said, Burst should work on this platform.
What Xcode version are you using? You’ll need Xcode 15.1 beta 2, beta 3, or 15.2 beta 1 for visionOS builds.

1 Like

Disabling that setting fixed the issue, the Xcode project generates and is able to build to simulator. Thank you!

We are now getting a crash related to UnityWebRequest, it looks like this is already covered in another thread - UnityWebRequest crashes app - #21 by puddle_mike.

I am using Xcode 15.2 beta, thanks again for your help.

Phew! Good to hear you’re unblocked (or at least blocked by a known issue :upside_down_face:). I’m still going to try and replicate the issues you are seeing, since I just tested a build with Burst today and didn’t hit that problem. Please let us know if you have any more trouble.

1 Like

I finally got a chance to test this out. Unfortunately (or maybe fortunately?) I wasn’t able to reproduce the errors you’re seeing. I was able to build and run a fresh project in 2022.3.16f1 and com.unity.xr.visionos@0.7.1 for VR and saw foveation working. Here’s what I did:

  • Create a new project with 2022.3.16f1 with the 3D template
  • Switch build target to visionOS
  • Add com.unity.xr.visionos and com.unity.render-pipelines.universal
  • GameObject > XR > Convert Main Camera To XR Rig
  • GameObject > XR > AR Session
  • GameObject > 3D > Cube (optional)
  • Assets > Create > Rendering > URP Asset (with Universal Renderer)
  • Enable Depth Texture on New Universal Render Pipeline Asset
  • Go to Project Settings > Graphics and set Scriptable Render Pipeline Settings to New Universal Render Pipeline Asset
  • Go to Project Settings > Quality and set Render Pipeline Asset to New Universal Render Pipeline Asset
  • Go to Project Settings > XR Plug-in Management and enable Apple visionOS under visionOS tab
  • Go to Project Settings > XR Plug-in Management > Apple visionOS and fill in Hand Tracking and World Sensing usage descriptions
  • Go to Project Settings > XR Plug-in Management > Project Validation and click Fix All
  • Build and run through Xcode

After setting up app signing, I am able to build and run to the device and I see my scene with the default skybox and cube, rendering with foveation.

If you are still hitting these issues, can you submit a bug with a project that reproduces the issue? I’m curious to see what may be causing it, and in theory your app could benefit from having Burst enabled, so we should try to figure out what’s going wrong.

Thanks in advance, and good luck!


We also ran into the same issue when upgrading to 2022.3.15 a while ago (Error: xcrun: error: SDK “xros” cannot be located). We disabled burst for now as well.

My best guess here is that this is coming from a non-beta version of Xcode. Do you have multiple Xcode versions installed? If you run xcode-select -p, does that point to the beta version? Personally, I tend to rule out any funny business and just keep the latest beta installed at /Applications/, and run sudo xcode-select -s /Applications/ every time I upgrade. Of course, this doesn’t always work for folks who need to build iOS apps or for some reason need to keep a non-beta version around. I’ll do a little digging to see how exactly Burst invokes xcrun but if you can share a little more info about your setup (what Xcode versions are installed and at what paths) that would help track down the issue.

Thanks for reporting the issue, and good luck!

1 Like

In my case (with Xcode 15.1 beta 3) which is the only one installed (at /Applications/ running xcode-select -p in the terminal returns /Library/Developer/CommandLineTools. Looking through that finder location I don’t see anything installed related to visionOS even though I make XCode builds for vision just fine.

I don’t see xros in that folder (/Library/Developer/CommandLineTools/SDKs) either. Do you have visionOS support installed in Xcode? You should see something like this in Xcode > Settings under the Platforms tab.

Yep I have visionOS support installed, and have been building successfully to visionOS targets on the same device that has these issues

fwiw I was having similar burst compiler errors and running the above command resolved my issues

sudo xcode-select -s /Applications/

I often have many xcode versions installed given the frequency of updates atm wrt vision os, unity etc… as well as a need to still be able to build using old xcode versions for ios etc…

1 Like

Hey @miro_unity530 are you still having trouble with Burst?

Looking back at this, I’m pretty sure what happened is that you installed the command line tools prior to installing Xcode, maybe by using git or similar? That would likely result in xcrun using a prior, non-beta toolchain instead of the beta you have installed. When I run xcode-select -p I see /Applications/

As @AdamSanche suggests, you should be able to run sudo xcode-select -s /path/to/ and resolve the issue.


I had the same “SDK “xros” cannot be located” error. Thanks to your discussion I could solve it. :+1:

In my case, the reason why xcode-select pointed to /Library/Developer/CommandLineTools was the installation of brew. Brew installs its’ own set of Xcode Command Line Tools during installation and makes xcode-select point to that. (See also Why does Homebrew change the path for the Xcode command line tools? · Homebrew · Discussion #167 · GitHub)

Maybe this hint will help someone.

1 Like

Helped a ton, that was exactly my issue.
My thanks! :]

Thank you so much, that fixed my issue!

I have also run into this error yesterday, a few minutes after a successful build and run on the simulator. Restarting the editor and Xcode got me back running…