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];
}

[GitToTheHub]

Thank you for explaining, what you mean with weird formatting :)

What is the general code formatting for Cordova projects when using curly brackets? When I change code, I always change some code styling issues i noticed during development. I use always the curly bracket in one line with the code and not on an extra new line. But I understand it's weird, when I change the styling on some points and on some points not.

[erisu]

@GitToTheHub I’ll be sending a thread to the dev mailing list later about coding style guidelines. We used to have a document years ago that covered coding style, but it wasn’t complete and eventually became outdated. That coding style document page has since been deleted over time—likely due to changes in the system it was hosted on—and was effectively lost. I had to retrieve it from the Wayback Machine to review it.

Overall, the thread will discuss and include a link to a PR that reintroduces the guidelines and publishes them on Cordova’s website for better visibility.

As a quick response to your question:

What is the general code formatting for Cordova projects when using curly brackets?

It varies by language.

In this case, for Objective-C, we follow the Linux brace style, which means breaking before braces on function, namespace, and class definitions.

[GitToTheHub]

Hi @erisu,

thanks for your response and that you are working on the guidelines.

I asked ChatGPT which style is better to use for Objective-C and it said, that it is better to make a curly bracket in one line with the code. It says, it is a convention by Apple and XCode is formatting it like this by default and it takes less space.

If the bracket should put on a new line, is this also valid for if?

[GitToTheHub]

I see, that a brace for an if gets no break when using linux brace style.

I read the Wikipedia article Indentation style and see, that the linux brace style is a derivate of the K&R (Kernighan & Ritchie) style and is documented there as Linux kernel style.

The default for Objetive-C is a modern derivative of 1TBS (One true brace style). Should Linux brace style anyway be used?