App Crashes when Opening Control Center

Unity Engine
, ,
1

Hi all,

Just updated our app to 0.7.1 and am running into a new app lifecycle issue. If I open the Control Center (by looking up and clicking on the small arrow button), while the app is running without the debugger attached, the app will crash after a few seconds.

If I open the Control Center with the debugger attached, everything works well. I can go to the Home menu and get back into the app as expected. Because of this, I haven’t been able to get any meaningful data about the crash. I tried attaching the debugger after launching the app, but this also prevents the issue from reproducing.

My setup is:

  • VisionOS Unity package: 0.7.1
  • Unity version 2022.3.16f1
  • Xcode 15.2 beta 1
  • Vision Pro on beta 7 (21N307)

Any ideas?

Thanks,
Diego

2

In the off chance that this is helpful, here are the logs I’m seeing when opening the Control Center.

-> applicationWillResignActive()
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> resuming, timeouts(0.0, 604800.0) QOS(0x0) Voucher (null)
[Telemetry]: Activity <nw_activity 12:2[639F6AE1-DCB5-473E-B820-19939160E907] (reporting strategy default)> on Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> was not selected for reporting
Connection 3: set is idle false
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> now using Connection 3
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> sent request, body S 3968
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> received response, status 200 content K
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> done using Connection 3
Connection 3: set is idle true
HTTP/2 Connection 3 Stream 5 ended successfully true
Ignoring alt-svc entry
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> response ended
Task <AC8CEE3E-A37B-4C9C-82A6-3F48DF886A2C>.<4> finished successfully
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> resuming, timeouts(0.0, 604800.0) QOS(0x0) Voucher (null)
[Telemetry]: Activity <nw_activity 12:2[2E9328E6-CF61-43C9-858A-0AED13EF8E2B] (reporting strategy default)> on Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> was not selected for reporting
Connection 3: set is idle false
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> now using Connection 3
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> sent request, body S 595
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> received response, status 200 content K
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> done using Connection 3
Connection 3: set is idle true
HTTP/2 Connection 3 Stream 7 ended successfully true
Ignoring alt-svc entry
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> response ended
Task <5F936467-22D2-4284-A3FF-74829941C67F>.<5> finished successfully

3

Hey there! Sorry to hear you’re having trouble, but thanks for reporting. I have not observed this behavior, but I spend most of my time testing apps with the debugger attached. I will test this out tomorrow. Are you seeing this on a device, in the simulator, or both?

4

I’m seeing this on device. Haven’t tested it on the simulator. Let me know what you find!

5

Hey there! I just want to confirm I am seeing this on device. I don’t see it happen in the simulator, although it looks like we stop rendering or getting head tracking input when the OS menu is open, so we may need to do something about that…

Anyway I’ve opened an internal bug ticket to track the crash issue and we’ll investigate a fix. Thanks for letting us know!

3 Likes
6

Amazing. Thank you for looking into this!

7

Do you know if this will be fixed in the new releases next week? And I don’t suppose there are any workarounds we can try on our side… those have been very helpful!

8

Unfortunately, this didn’t make it into the upcoming release. It’s still something I’m looking into and will share a workaround if I find one. Since it doesn’t happen with the debugger attached it’s a particularly tricky issue to… well, debug! :slight_smile:

Thanks for your patience on this. We realize it’s a major issue and we’re doing our best to fix it.

9

I also have an issue I’ve been debugging that only happens when not in the debugger. If it helps, I have been using a simple custom plugin to forward Debug.Log to NSLog, which allows you to print debug Unity logs by monitoring the running app in Apple’s Console app. Grab it here:

The other thing I’ve done is upload the build to TestFlight and use the crash reporting built into the testflight to receive stacks that are viewable in XCode…

2 Likes
10

Thanks for the tips! Since I have source access over here my ideal workflow is to actually catch this bug in action in the debugger, so that’s still been my goal… but you’re right I might just have to resort to trace debugging. :sob:

I’m sure we’ll figure this out soon enough. It’s high on my priority list and while it didn’t make it in for 2022.3.18, I’m optimistic that we can get it fixed by patch 19. With any luck, it’s something that can be fixed in packages! :crossed_fingers:

11

Hi @mtschoen! Just wanted to check in on this issue since we’re gearing up for launch next week, and this is currently our only blocker. Have you been able to find a fix yet? Do you know if it’ll make it into patch 19?

12

I’m still looking at this but I’ve been able to track it down to the app getting the sceneWillResignActive signal when the user opens the “indicator” menu or control center. We use this to pause Unity, and it’s used to signal other events like going to home screen or the user removing the headset.

In a pinch, you should be able to either remove the call to this method, or specifically remove the call to UnityPause(1) and _didResignActive = true; in UnityAppController.mm:applicationWillResignActive. This should work around the control center crash but you may have other issues like audio persisting when returning to the home screen or otherwise not pausing the Unity simulation when it should be paused. We’re working on a better fix that should handle all of these cases properly. It should be something we can either fix in packages or do with a build post processor in case we miss the boat for the next Unity release.

1 Like
13

This is great news. Thanks for the update! As long as we get the update early next week, we should have enough time to rebuild and publish. Do you think it’ll be ready by then? If not, I can look at temporarily adding that workaround.

14

Definitely give the workaround a try. It would be good to confirm that it fixes the issue for you, and if your app has any particular quirks if left unpaused.

15

It worked for us on device. Our app would crash when opening this menu and now it is fine.
The thing remaining with this menu is when we pinch on the X icon of our app, it goes to pause when I believe it should quit ??

thanks for the work around !

16

I just tried the workaround as well. I’m seeing very strange behavior with it. The app no longer crashes when the control center is open, but as @cliv3dev mentioned, the app no longer quits… ever? Closing it with the X in the control center, then re-entering would keep the app in the same state.

Additionally, going out into the home menu without quitting the app, then re-entering will shift the world space of the app. For example, if you open the app, place an object, go back to the home menu, turn your head and re-enter the app from this new position, the object will be rotated. The expected behavior is that it should stay in the same location relative to the world.

17

I’ve been playing with the app lifecycle callbacks a bit, and the best workaround I could come up with is this.
When the control center is open:

  • The app continues to render. (It currently pauses the app.)
  • If the control center is closed, the app continues to run as expected.
  • If the user quits the app by pressing X in the control center, the app quits as expected.
  • If the user goes to the Home menu, the app quits as well (not expected, but might be an okay tradeoff if we need to ship with this version of Unity).

It appears that force quitting the app and going back to the Home menu, gives us the same callback, so this is the best I could do.

For reference I modified two methods in UnityAppController.mm, which now look as follows:

- (void)applicationDidEnterBackground:(UIApplication*)application
{
    ::printf("-> applicationDidEnterBackground()\n");

    if (_unityAppReady)
    {
        _wasPausedExternal = UnityIsPaused();
        if (_wasPausedExternal == false)
        {
            UnityRequestQuit();
            UnityQuitApplication(0);

            UnityWaitForFrame();
        }
    }

    _didResignActive = true;
}

// ...

- (void)applicationWillResignActive:(UIApplication*)application
{
    ::printf("-> applicationWillResignActive()\n");

    if (_unityAppReady)
    {
        UnitySetPlayerFocus(0);
    }
}

This feels super hacky, but it seems to work. @mtschoen any other ideas/pointers?

1 Like
18

This seems reasonable to me, but as you say, quitting when the app goes into the background probably isn’t going to work for everyone. What I’m working on now is using the LayerRenderer State to decide when to pause the app. So far I only need to change trampoline code, so while it will roll out with a future Unity Editor version, it’s still something you can patch locally. I’ll ping this thread again when I have something solid. For now, I think what you have here is a good workaround, especially if you’re happy with the behavior.

3 Likes
19

Sounds good. Thank you! We’re definitely holding out for a proper fix before launch, but if we HAVE TO ship this, it’s not the worst. :slight_smile:

For the record though, I do think continuing to render while the control center is open, is a much better experience than just keeping the last frame up.

1 Like
20

Oh yeah… head-locked rendering is a ship stopper, for sure :laughing: