Can we access a "Locked in Place" value when a window has been locked without being snapped to a surface?

Hey @radicalappdev,

There's no supported way for you to tell when a window has been locked in place. You should implement persistence in your app under the assumption that your app can and will be locked at any time.

Are you able to provide more information as to what exactly you are trying to achieve?

If you'd like us to consider adding the necessary functionality, please file an enhancement request with detailed information about your use case using Feedback Assistant. Once you file the request, please post the FB number here.

If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?

Thanks,
Michael

@Vision Pro Engineer Feedback filed: FB18351716

There are a lot of uses for this. We could adapt the window to this state. For example, hiding other window elements, toolbars, and ornaments. Or provide alternatives to a "locked in place" state.

Hey @radicalappdev,

The examples that you and @J0hn have provided are not indicative of the window being locked in place. Locking in a window in place shouldn't result in visual changes within your application. Similarly, being pinned to a surface does not necessarily mean that that your application should provide a more simplified UI. Consider providing configuration in your application to customize the behavior of your app.

Your application should support scene restoration for all scenes, regardless if the window has been locked in place. There are many possible ways that restoration can happen; so locking-in-place should not be special-cased.

Please let me know if you have additional questions,
Michael

@Vision Pro Engineer

"Locking in a window in place shouldn't result in visual changes within your application"

"so locking-in-place should not be special-cased"

These are just your opinions though, and I disagree. I have valid uses where this would make sense. I described one of them in my earlier comment. I have an app where a certain type of window has what call "focus mode". With visionOS 26 window locking, I would like to enable focus mode for any locked window. Currently the user would have to lock the window, then use controls inside the window to enable focus mode. It would be better if I could offer them the option to enable focus mode when the window is locked.

I don't understand why you're pushing back on this. It's a simple feature request for a value that we can already get for snapped windows. Why do you think we shouldn't be able to access the same value for unsnapped free floating windows?

Hey @radicalappdev,

I'm trying to gain a better understanding of your request and how it might impact platform experience. Enhancement requests are looked at by multiple engineers when considering them for the platform. Compelling examples help us understand your use case. My pushback is both to better understand your use case and examples, and to understand how your desires could be accomplished using existing APIs.

In terms of scene restoration, locking-in-place should not determine if an application should restore to a specific item or level of navigation. Scene restoration should be implemented across the application. The system will decide if the scene should be restored centered on the user, locked in place or snapped to a surface. For more information on this topic, see Adopting best practices for persistent UI.

It would be better if I could offer them the option to enable focus mode when the window is locked.

It terms of this request, I'd still like to understand why this would be better. I could imagine use cases in which someone might prefer to have your application locked in place, but not in the focus mode. Similarly, someone might prefer to have the focus mode enabled on the window when it is not locked in place. They might prefer a focus mode that follows them as they re-center their view.

Thanks for the dialogue,
Michael

@Vision Pro Engineer I'm not talking about interrupting or overriding scene restoration. I'm talking about adapting the window that the user is currently using with other visionOS and SwiftUI features.

It terms of this request, I'd still like to understand why this would be better. I could imagine use cases in which someone might prefer to have your application locked in place, but not in the focus mode.

This is about user choice. I want to give them the option. I'm not talking about limiting focus mode to locked windows only. But for a lot of uses, it would be a better user experience to auto-enable focus mode for locked windows. Without this the user has to (1) lock the window manually enable focus mode). Giving them the option to do both of these just by performing one action is better than always requiring them to do both.

I can already deliver the experience that I want with the existing APIs for snapped windows. I want to provide the same experience for free, floating window. Regardless of intention, users will think about locked windows in exactly the same way they will think about snapped windows. The only difference between these two is one is bound to a surface and the other is free floating. Other than that, they should behave exactly the same. Without access to this value, they will always have to be treated differently.

Hey @radicalappdev,

Thanks for the additional dialogue and reasoning. I've updated your feedback request to include this information. Including extensive information about what you want to achieve and why you want to achieve it is very helpful as we have conversations with the teams about API choices.

Thanks,
Michael