fix(ios): use auto layout to respect safe areas

[GitToTheHub]

• The toolbar didn't respect the safe areas, because it was using manual frames and the web view’s frame was also adjusted manually. This bypasses the safe area system, so the toolbar can end up under the home indicator or the items can be too close to it.
• Disable manual frame math for the toolbar and address label.
• Use Auto Layout to constrain the toolbar to the view’s safe area bottom and leading/trailing edges, and height to TOOLBAR_HEIGHT.
• Constrain the address label above the toolbar (or to the safe area bottom if no toolbar).
• Constrain the web view to the safe area top and to the top of the address label/toolbar (or view bottom if hidden).
• Remove code which was related to manual layout
• Don't set height manual for toolbar and adresslabel, let auto layout decide. This aligns the toolbar better on iOS 26 with the new button layout.
• Generated-by: XCode 26, GPT-5

How it looks before and now:

iOS 18.5

Before	Now

iOS 26

Before	Now

Platforms affected

• iOS

Motivation and Context

Description

Testing

Checklist

• I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change
• Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• I've updated the documentation if necessary

[johann9898]

I tested this with

cordova.InAppBrowser.open('https://www.apache.org', '_blank', 'location=no,toolbarposition=top')

It seems to have some spaces at the bottom. Is this expected?

[GitToTheHub]

Thanks for posting this. There should be no gap at the end. I will fix this.

[GitToTheHub]

@johann9898 I fixed this. The WebView stretches now to the bottom edge of the phone

[GitToTheHub]

@dpogue Is this ok to merge?

[GitToTheHub]

@dpogue I see my IDE Visual Studio Code uses LF for line endings and not CRLF. Is there a rule, which one is to use for this project or does it not matter?

[erisu]

@dpogue I see my IDE Visual Studio Code uses LF for line endings and not CRLF. Is there a rule, which one is to use for this project or does it not matter?

Leave it as LF. We do not use CRLF.

[GitToTheHub]

@erisu Ok, I thought this was the thing you mentioned when I changed the package.json in cordova-ios

[erisu]

Ok, I thought this was the thing you mentioned when I changed the package.json in cordova-ios

LF and CRLF refer to the types of line breaks used by different operating systems. For example, Linux and macOS use LF (\n), while Windows uses CRLF (\r\n). In Cordova's case, LF is preferred.

What I commented on last time was the removal of the trailing newline at the end of the file. Cordova repos generally keep a trailing newline at the end of the file.

[GitToTheHub]

What I commented on last time was the removal of the trailing newline at the end of the file. Cordova repos generally keep a trailing newline at the end of the file.

Thank's for the clarification. So I know, that every file has to end with an empty new line. I will keep this in mind in future changes.

[dpogue]

Missing a trailing line break and there are a few weird formatting changes, but the implementation looks okay otherwise

[GitToTheHub]

Missing a trailing line break ...

I added the trailing line brake.

... and there are a few weird formatting changes ...

Can you explain, what you mean with these weird formatting changes?

[GitToTheHub]

@dpogue I would merge this now, is this ok?

[dpogue]

This is probably fine to merge.

The "weird formatting" I saw was stuff entirely unrelated to the safe area insets that seemed inconsistent with the code style for the rest of the project, like

- (void)goBack:(id)sender
{
    [self.webView goBack];
}

changing to

- (void)goBack:(id)sender {
    [self.webView goBack];
}