Hi, I’m trying to port an app with a pixel-based GUI over to JUCE and have noticed something strange: the pixel screen size on any iPhone model (including iPhone X on the simulator) is reported as 320x568. Is this normal? I see that even on an iPhone 8 Plus rendered text is nice and sharp, so “under the hood”, things seem to be done correctly, but it basically makes pixel-precise scaling and alignment of bitmaps impossible. Also, does it mean that it’s not possible to take advantage of the whole screen on the iPhone X?
EDIT: While on the screen of the iPhone 8 Plus, it does look flawless, there’s actually significant blurring over up to 4 pixels in x or y direction when I zoom in on a screenshot. So I guess it is really a 640x1136 image that is upscaled…
I don’t know if that has changed in the latest version of the Projucer, but the default launch image asset has just image size “slots” for iPad, iPhone 4/4S, and iPhone 5/5S/SE. So I tried to add an iPhone X sized launch image in a new asset (right click -> add assets -> app icons & launch images -> new iOS launch image). And indeed it worked! (After copying my old launch images and choosing the new asset as my “official” launch screen asset). And yes, it does really just render those resolutions for which I’ve specified images.
Now my question for you: is there any Projucer version that directly provides a slot for the iPhone X launch screen? That would make the process easier. Or am I missing somethingy? Could I specify the launch images in the Projucer project? I’ve seen the “customs Xcassets folder” parameter, but don’t quite understand how to use it.
And as a side note: why is there no iPad Pro launch screen size in XCode? Is it not possible to use the full resolution of the iPad Pro when you’re using a launch image?
We’ve recently made some changes to take advantage of the runtime @available keyword where we can in the codebase. As long as you are building against the iOS 11 SDK, you can keep a lower deployment target and the iOS version of the device will be checked at runtime to determine whether the safe insets property is available instead of previously where we were excluding the code at compile-time:
How should Display::safeAreaInsets be used? It seems that standard practice is to put mobile apps into setFullScreen(true); but it doesn’t look like safeAreaInset is being considered in full screen mode…