BR: safeAreaInsets not reported correctly on iOS

MacOSX and iOS
1

The safeAreaInsets of the display on iOS are no longer reported correctly. Before rotating the device, all insets are zero. After rotating, the insets are reported correctly.

The breaking commit is: 7bc7dff6f66396e2e7c1c2132ce455faa2756758

Latest develop (79053759a50ccc383d110c7862aa091927d23985) does not fix the issue.

Please fix!

2

Can you reproduce this issue in any of the JUCE examples, such as the DemoRunner? If not, please can you provide a minimal example that demonstrates the problem?
On what OS version are you seeing this issue?

Here, the DemoRunner built from the develop branch opens with the correct insets on the iOS 26 simulator, so I suspect there are other contributing factors.

3

I can reproduce this in GuiAppExample when adding a rectangle which draws the safe area (bounds minus safeAreaInsets). Attached is a patch which shows the problem.

The device is an iPhone 13 mini running iOS 18.6.2. I’m building with Xcode 16.4.0.

CMake configuration:

-G Xcode
-DJUCE_BUILD_EXTRAS=ON
-DJUCE_BUILD_EXAMPLES=ON
-DJUCE_ENABLE_MODULE_SOURCE_GROUPS=ON
-DCMAKE_SYSTEM_NAME=iOS
-DCMAKE_OSX_DEPLOYMENT_TARGET=12.0
-DCMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY="iPhone Developer"
-DCMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM=<team-id>

IMG_4125
IMG_41251125×2436 58.8 KB

IMG_4124
IMG_41241125×2436 59 KB

JUCE-09-02-08.patch (2.0 KB)

4

@reuk Any thoughts on this?

5

Given that the DemoRunner and PIPs seem to respect the insets, it’s likely that your example is missing some logic that’s included in the demo projects.

For PIPs, we handle safe area insets like this:

// The content component of the MainWindow
class SafeAreaComponent : public juce::Component
{
public:
    explicit SafeAreaComponent (std::unique_ptr<Component> c)
        : content (std::move (c))
    {
        addAndMakeVisible (*content);
    }

    void resized() override
    {
        if (const auto* d = Desktop::getInstance().getDisplays().getDisplayForRect (getLocalBounds()))
            content->setBounds (d->safeAreaInsets.subtractedFrom (getLocalBounds()));
    }

private:
    std::unique_ptr<Component> content;
};

...

void MainWindow::parentSizeChanged()
{
    if (auto* c = getContentComponent())
        c->resized();
}

It’s important to listen for parentSizeChanged(), since this is used to signal a change in the current insets.

6

Your suggestion works, thanks.

To me this feels like a workaround, especially since the commit mentioned changes the behaviour, but since you’re offering this I assume you’re not going to make a change to revert the behaviour?

7

No, reverting would reintroduce the issue that was addressed by that change.

I’m not sure this is really a workaround, since the safe insets are allowed to change at runtime (imagine that the device orientation changes, or the onscreen keyboard is shown, or the app is used in windowed mode on an iPad where it may or may not need to leave room for the top status bar). So, your app will need to handle changing insets anyway, and the startup-insets will be handled for free if you implement handling for the other scenarios where the insets may change.

8

Thanks for confirming.