This won’t work since in portrait mode left and right offsets are 0. You can just check for specific pixelWidth
Hmmm. I am not testing offsets. Though I understand the relationship of offsets with safeActualContentHeight and safeActualContentWidth.
This is what I get in the simulator with the iPhone X skin. The app the is Portrait (only). Note the safeActualContentHeight IS different than the actualContentHeight (946 versus 1024).
==================================================================
SCREEN DIMENSIONS - Model: iPhone Architecture: x86_64
display.actualContentHeight = 1024
display.viewableContentHeight = 1024
display.contentHeight = 1024
iP X display.safeActualContentHeight = 946
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
display.actualContentWidth = 472
display.viewableContentWidth = 472
display.contentWidth = 768
iP X display.safeActualContentWidth = 472
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
iP X display.safeScreenOriginX = 0
iP X display.safeScreenOriginY = 44
iP X display.getSafeAreaInsets top,left,bottom,right = 44, 0, 34, 0
==================================================================
Steve
local t, l, b, r = display.getSafeAreaInsets()
l+r+display.safeActualContentWidth == display.actualContentWidth
Same goes for top, bottom and heights
Of course. But that is NOT what I suggested as a test (see above).
I’m just talking about an easy test. That being:
if (display.actualContentHeight ~= display.safeActualContentHeight)
OR (display.actualContentWidth ~= display.safeActualContentWidth)
If either is true (the “either” eliminates the orientation question you raised), then it can be no other device that I know of yet (i.e. must be an iPhone X).
Steve
Steve, I think I need to add a very important to this discussion.
display.contentWidth = the value YOU put in config.lua for width.
display.contentHeight = the value YOU put in config.lua for height. Nothing more, nothing less.
display.actualContentWidth and display.actualContentHeight are going to be scaled to your content area. Let’s say you define width, height to 320 and 480. On an iPhone 5, the pixel width is 640 and the pixel height is 1136. Since this is exactly 2X scale, then your display.actualContentWidth = 320 and display.actualContentHeight = 568.
You cannot use .actualContent* to determine the device you’re on because the numbers are scaled to your content area and you would spend a lot of time hand calculating those values.
We offer display.actualPixelWidth and display.actualPixelHeight which will return you the device’s pixel count which would be a better choice. However, Vlad’s suggestion to use the iPhone10,6 string is a published value by Apple and it alone should be safe to use. But if you insist on using a pixel measurement, you should use the pixel measures.
Rob
Thanks Steve, Vlad, and Rob for some very useful comments. I’d been wondering about this issue as well.
Can this currently be tested inside the simulator on iPhoneX?
Insets - yes. system.getInfo(“architectureInfo”) would return simulator or x86 on simulator or xcode simulator.
Hey guys.
I’m just testing (corona native) in the Xcode iPhone X simulator and “display.getSafeAreaInsets()” returns 0,0,0,0
Am I missing something for native?
Thanks,
Xcode iPhone X simulator is also giving me strange values. Corona simulator seems to be correct.
Corona:
PixelHeight = 2436
SafeAreaInsets = 44/0/34/0
Xcode:
PixelHeight = 2001(!?)
SafeAreaInsets = 132/0/102/0
I ended up submitting using a simulator build (not native). I guess there’s something I’ve missed in xcode somewhere.
Maybe I’m just tired, stressed and overworked, but I can’t resolve this issue.
On all phones other than iPhone X (which I don’t have), there is an extra inset on top. I stupidly released an iPhone X version and now players are telling me that buttons on top of the screen are too low 
Also, using Corona Native, the xcode simulator returns 0,0,0,0 for the safe areas.
Any ideas?
Rob let me bring this up with the engineers. I know there are some circumstances where the values are inconsistent. But I’m not sure why native builds are returning 0 for everything.
Rob
Unfortunately Simulator behavior is different than real device one. We plan to fix it really soon.
About safe area insets: they also account for system UIs like status bar.
Are your issues on Android or iOS?
Thanks Rob. I’m a bit lost with this.
Then the first question of this thread remains. why top-inset in iphone6,7,8 is not zero in a game with a hidden status bar.
simulator returns zero, which seems to be the “right answer” but not real iPhone 6
roballison182, your best bet is to specifically check for iPhone_x ( using system info) and only then lower buttons on top.
I hoped we can do this by lowering all platforms by “top-inset” and it would be generic clean code, but won’t work as just discovered.
Hey guys!
Latest daily build, 3173 should contain better values for safe area insets. They should behave way more similar to iOS devices (i.e. include safe area when status bar is shown)
Here’s app I use for testing: gist, zip
Also, I did not find any issues with native use of safe areas. I would be grateful if someone to provide me with how to reproduce their issues.