VisionOS App Runs Poorly And Crashes First Time It Launches

Here’s a video clearly demonstrating the problem:

This is a major issue for my game, because it’s not meant to be played multiple times. My game is designed to only play once, so it really ruins the experience if it runs poorly until someone force quits or crashes the game.

Does anyone have a solution to this, or has encountered this issue of poor initial launch performance?

I’m not sure if this is an Apple issue or a Unity issue.

Hey there! I’m sorry to hear you’re having trouble. Your game looks really cool! Let’s see what we can do to resolve these issues. First of all, it looks like you’re using the VR/Metal rendering path here, as opposed to PolySpatial and RealityKit? Are you using Unity 6 or 2022.3? What package versions are you using? Are you using any third-party tools or packages from the Asset Store or first-party packages like XR Interaction Toolkit?

Probably both? :slight_smile: It’s hard to tell with these sorts of things, and the only real way to find and fix the problem is for us at Unity to be able to replicate the crash or unexpected behavior. If you are able to submit a bug report with your whole project, that is ideal for us, but I can understand that this is problematic due to copyright/licensing issues or the size of the project. Anything you can provide like the project settings and package manifest, logs or crash reports, etc. will help. If you can’t share the full project, it may be worth some time to try and replicate the issue in a project that you can share, along with a bug report explaining how to replicate the issue.

Off the top of my head, here are some issues that you might be running into:

  • Memory pressure: the OS will kill your app (and I think it results in an exit code of 9?) preceeded by messages in the log about memory usage. It usually happens when the app is consuming >10GB of RAM, although it can depend on what portion of that is needed for GPU buffers, etc.
  • Compositor Services lifecycle: we have some edge cases in the VR/Metal rendering pipeline that can result in the CompositorServices API (which is responsible for drawing full-screen VR experiences) getting into a bad state and crashing the app. These are usually preceeded by a message that starts with BUG IN CLIENT: and say things like “more than 3 frames in flight” or “start was already called” etc.
  • Uncaught exceptions in native code: it could be plugins, the Unity library, Bursted C# code, etc. Those would all come with a native stack trace in the log that should give us some idea about where to start looking.
  • Input system overhead: some customers have reported a lot of time spent in the input system or hand tracking packages in the C# layer that can cause lag/frame drops. Those would show up in the Unity profiler. Doing a profiler trace on the slow bits will help us figure out what’s going wrong.

Please feel free to send this info over DM if you aren’t comfortable sharing it in the public forum. And rest assured, your bug reports and anything that you upload along with them can be kept entirely private (although the title and description is sometimes made public so let us know if you don’t want that to happen). We will not use the data you submit for anything other than trying to fix the bug.

Thanks again for reaching out and for your patience. I’m optimistic that we can resolve these issues and help you ship your game, which, again, looks great! :slight_smile:

1 Like

Wow, that was a lightning fast response. I’m using unity 6 preview. I actually haven’t updated the packages in a long time so I might try that first. I’m out of the office today, but will try to diagnose this issue tomorrow and let you know what I find.
On a possibly related note, when I downloaded the game Vacation Simulator on my AVP, the first time it launched it did a longer loading screen that took a few minutes to complete. It even said under the loading bar that this only has to be done the first time the game launches. Is there some initialization stuff like that that needs to run on my game? Or is that a whole different issue?

Most of that can be explained by “compiling shaders,” but it’s possible they are doing other long-running processes on first run.

That reminds me, though, there’s another issue that a lot of folks have been hitting which is that if your app stalls on the main thread for longer than 2 seconds it will get killed by the OS. There’s more detail here but it’s possible that you’re hitting some long-running process in C# like a garbage collection spike or really big allocation that takes longer than 2 seconds. Again, using the Unity profiler should help find these issues.

1 Like

Like I mentioned, I’m currently using Unity 6 version 6000.0.15f1. Though I believe this issue of the game running poorly and crashing midway on first launch was something I experienced with Unity 2022 before I switched to Unity 6.

My game does run pretty hot. It’s really pushing the performance limits of the AVP. But it’s only a 10 minute experience, so I think it runs well enough.
Of course, the problem is it only runs well enough after the second time it launches. From what I’ve seen, most players just stop playing after it crashes because they don’t know that it runs better without crashing the second time.

I’ve posted this issue on the Apple developer forums as well, but no response yet:
https://developer.apple.com/forums/thread/762724

Here are the packages I have:
|Apple visionOS XR Plugin|1.3.1 g|
|AR Foundation|6.0.3|
|Autodesk FBX SDK for Unity|5.1.1 8|
|Burst|1.8.17 g|
|Collections|2.4.1 8|
|Core RP Library|17.0.3 g|
|Custom NUnit|2.0.5 g|
|Editor Coroutines|1.0.0 g|
|FBX Exporter|5.11|
|Input System|1.9.0 g|
|JetBrains Rider Editor|3.0.31 ©|
|Mathematics|1.3.2 g|
|Mono Cecil|1.11,4 0|
|Oculus XR Plugin|4.2.0 g|
|OpenXR Plugin|1.11.0|
|Performance testing API|3.0.3|
|Searcher|4.9.2 g|
|Shader Graph|17.0.3 g|
|Test Framework|1.4.5 g|
|Timeline|1.8.7 ©|
|Unity Light Transport Library|1.0.1 g|
|Unity Ul|2.0.0|
|Universal RP|17.0.3|
|Universal RP Config|17.0.3 g|
|Version Control|2.4.4 0|
|Visual Scripting|1.9.4|
|Visual Studio Editor|2.0.22|
|XR Core Utilities|2.3.0|
|XR Hands|1.5.0-pre.3|
|XR Interaction Toolkit|3.0.5|
|XR Legacy Input Helpers|2.1.10 g|
|XR Plugin Management|4.5.0|

I just DM’d you a Dropbox link to that Unity project.

If I can’t solve this issue, I was considering doing one of two options:

Option #1:
I would try to find a way to force the game to crash on the first launch, so that on the second launch, it would just play normally. And players will just perceive that as a minor hiccup.

Option #2:
This is the worst option but I would have text in the beginning of the App Store description saying:
“IMPORTANT!!! PLEASE READ!!! FORCE QUIT THIS APP AFTER YOUR INITIAL LAUNCH, THEN START THE APP AGAIN! OTHERWISE, THE APP WILL RUN POORLY AND CRASH!”
And even then, most players won’t read that. Haha

I could be wrong, but my impression is this is an Apple issue. It’s not like the game is running poorly every time, so it’s not like optimizing the performance in Unity will improve that first time launch.

I was initially only gonna post this issue in the Apple dev forums, but I figured perhaps y’all have noticed other devs have encountered something like this. It would seem highly unusual if I’m the only one with this issue.

Thanks for sharing your project! I should be able to take a look at it today. Once I’ve had a look we should know more about what the specific issue is and how to solve it.

1 Like

OK! I think I have a fix for you @asimdeyaf. I had some trouble replicating the issues you’re describing. For some reason, I couldn’t get the profiler to connect to a development build, and although I did finally replicate the crash, it happens quite a while into the game and I didn’t see anything in the console output that would suggest this is the BUG IN CLIENT flavor of compositor services crash. Nor did I see any memory pressure/warning issues, so it’s still not clear to me exactly why the app is crashing.

However, I was able to reproduce the lag/hitches that you were seeing early on in the game, and I’m fairly confident that those are caused by shader warmup. Again, I wasn’t able to “catch” the issue in the profiler or see any logs, but it’s consistent with the kind of thing that would be caused by shader warmup: it’s the first frame that a bunch of objects get activated, and that causes their shaders to compile.

What I did on my end, which I think should work as a quick and dirty fix was the following:

  • Add a scirpt to your startup scene that calls Shader.WarmupAllShaders(). This will front-load all that shader compilation stuff to the very beginning of the game. This means you spend a little more time looking at pass-through (a.k.a. nothing) before the app starts, but it’s not too bad.
  • Enable the undocumented metalCompileShaderBinary player setting, which should further front-load some of the shader compile to the actual Editor build process. I’m going to follow up with our graphics folks to see if this is something we should expose or enable by default since it’s kind of hidden at the moment. You can enable this by finding the line in ProjectSettings/ProjectSettings.asset that reads metalCompileShaderBinary: 0 and flipping the 0 to a 1.

With both of these changes, I was able to run the app without any visible hitches in the opening sequence. I didn’t stick around long enough to see if the crash was fixed, though. I might need some help adding a “cheat menu” so I can skip straight to the scene with the crash. With any luck, the crash is also related to shader warmup, and the changes above will fix it! :crossed_fingers:

Let me know if this works for you. Good luck!

1 Like

That didn’t fix it 100%, but that fixed it 90%, which I am totally happy with… However, I’ve only tested this with builds installed straight from Xcode to my device. I presume it will be the same effect when downloading it from the store, but I’ll let you know if I run into any problems there.

Regarding the crashing, that is actually a separate issue that I’m currently working on. In fact, this game should be crashing every time so I’m more confused on why it was not crashing before. Haha. The crashing is something I can handle myself, so I won’t need to bug you about that… probably.

Thank you very much for your help. You are a lifesaver. :pray:

Hooray! Hopefully 90% is also good enough for certification?

Make sure you are at least testing sometimes with Debug Executable unchecked in the Xcode run scheme (Edit Scheme... in the dropdown next to the run button. For the 2-second hang and a few other cases, visionOS will allow your app to hang if the debugger is attached, since there’s no way to distinguish an app hang from the debugger pausing on a breakpoint.

You can also just test by detaching Xcode and clicking the app icon to launch the app that way. That should be close enough to how it will behave when downloaded from the store. But of course a TestFlight install is the actual closest thing to an app store download :slight_smile:

Don’t you just love those? Well yeah feel free to start a second post/thread about the crash or submit a bug report if you can’t solve it. Good luck!

I just tested it through test flight. Everything seems to be working good with no crashing.
It passed the app review process. (Well actually, it even passed the app review process before when it was performing badly and crashing. Haha) It’s up to me when to release it now. Probably this week or next week, if no other hurdles come up.
Thanks again for your help.

1 Like