I realize I’m a bit late to the party here on this one, but given that this change seeks to address concerns with changing hardware structures, is it reasonable to assume insets will be static once initialized, or should we be concerned with handling changes in runtime?
Safe area insets can change dynamically as your game runs. For example, if your game allows portrait orientation, changing from landscape to portrait orientation also changes the safe area insets:
5 Likes
I don’t have the notch support neither the new phones to choose. Was it temporarily available to get the feature?
1 Like
Don’t have it in the tab, or I at least can’t find it.
1 Like
Thanks, the notch functionality is a much needed improvement. We do have concerns, though. As a few others have previously mentioned, pushing in the UI on the non-notched side leaves it looking a bit off-center and, well, broken.
Are there plans for another safe inset that only affects the notched side of the screen?
1 Like
Hi, thanks for your feedback!
We provided symmetrical safe area insets in landscape mode because we found this to be an industry-standard design choice present in many mobile apps.
We recommend symmetrical left/right insets because it creates a more balanced layout, but if you prefer to use asymmetrical safe area insets you can use PlayerGui.CurrentScreenOrientation to differentiate between LandscapeLeft and LandscapeRight orientations, and create a custom safe area for each orientation.
3 Likes
Hi all, just a heads up on the notch screen support client release:
- We have turned on notched screen support on 10% of Android and iOS devices.
Please let us know if you spot any notch-related bugs in your experience!
5 Likes
It would still be quite convenient if we could toggle symmetrical insets with a property - this solution is a big ask for many legacy games (and new games alike)
any updates on rollout?
Why is the notification of this being rolled out only as a comment to an announcement headed only as a studio beta?
I was planning to schedule in development time for notch aware GUIs at the end of this month…
It’s still a beta feature in studio so I don’t get how I’m suppose to test/implement this (I’m assuming that reading ScreenInsets will throw an error if beta is disabled). I’d have expected a more thorough developer focused timeline on the roll out than a sudden phased A/B style introduction into prod. I know my UI doesn’t look good with notches as is so wanted to be on the ball to get this out in time.
Hi, thanks for the feedback!
I was wondering, what API would you prefer for designing UI for screens with rounded corners + notches?
For example, if you could toggle symmetrical insets = off, would the hardware safe area still be inset by rounded corners or not? If not, would you prefer to use an API like GuiService.TopLeftScreenRoundedCornerRadius to get the radius of each screen corner, and inset your UI using that information in code?
Currently, rollout is at 10% as part of an ongoing A/B test. I don’t have any updates for how long the A/B test will run, we are monitoring various performance/engagement metrics to make sure we don’t cause issues for any games.
1 Like
Hi, thanks for your comment.
You can test/implement notch support for your game by using the mobile emulator in Studio, and enabling the Notch Support Beta Feature. This will make the new ScreenGui APIs visible in the Studio interface and update the emulation devices.
However, you can turn off the beta or play the game on a mobile client without notch support without any errors. The new ScreenGui APIs are available in all games regardless of the notch support A/B test enrollment status. If notch support is not enabled, you will just see a black bar and the hardware safe area insets will always be zero.
So, a simple UI design strategy is to design your UI with the Notch Support beta enabled, and test your UI on both notched and non-notched devices. Then, your UI should work for all users regardless if they are in the A/B test group, because notch support disabled is equivalent to emulating a non-notched device (aka 0 safe area insets).
Unfortunately, we don’t have a more concrete timeline to share currently because we are still gathering performance/engagement metrics from the A/B test. However, I’ll keep you updated!
I would prefer to not inset by rounded corners if symmetrical insets = off, as this is how the legacy behavior worked and is what we designed for (we have menu bars and UI elements that extend to the edge of the screen).
I think it’s much more versatile to then offer an API like you proposed so both outcomes could be achieved.
Perhaps another option would be an Enum:
ScreenInsets {
NotchSymmetrical – default behavior with mirrored notch safe area
NotchAndScreenCorners – notch safe area, follow screen corners on opposite side (safe area)
NotchAndScreenEdge – notch safe area, ignores screen corners on opposite side (no safe area)
}
Maybe not a complete implementation but I’m coming from a place of wanting quick built-in flexibility vs. having devs write the same code over and over to support the same cases. Thank you for your response
4 Likes
Hey there. I have recently noticed that in the Device Emulation tab, iPhones have these weird notch-related offsets at the bottom of their screens.
1 Like
Hi, thanks for reporting this! Yes, this is a bug because the home indicator shouldn’t cause any bottom inset in landscape mode. I believe this should be fixed now.
Please let me know if you run into any other issues!
4 Likes
Any updates about this now? What are the known bugs that are preventing this from getting released to the public?
1 Like
Will there be other devices in the future with notched screen support? Especially iPhone 14.