GeezerVison

PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

Laying out a tree on iOS spends most of its time marshalling between JS and UIKit rather than in UIKit. Containers (layouts, ScrollView, Page content) default to iosOverflowSafeArea, so every time a container's frame changes, IOSHelper.expandBeyondSafeArea builds four CGRects (the safe area, the full area, the frame in the window, the frame) and reads each one back through getPositionFromFrame: about 70 native getter and struct calls per view, for a result that is the frame itself unless the view touches the edge of the safe area.

Instrumenting core's layout methods in the xplat-benchmarks ns-core app (iOS simulator, a 1,093-view tree) showed each resize calling getPositionFromFrame about 5 times per view, and applySafeAreaInsets taking more time than all the measuring.

What is the new behavior?

The results are the same; the native calls are fewer.

• expandBeyondSafeArea reads each native value once (the reference scroll view's insets, content size and offset, or the controller's safe-area guide and frame; the view's location in the window; the frame) and computes the positions in JS with the same arithmetic. When nothing is expanded and the frame is already on device pixels, it returns the frame itself, and _modifyNativeViewFrame doesn't set it a second time. getAvailableSpaceFromParent is unchanged for other callers.
• layout() uses the position of a frame it has just set, unadjusted and untransformed, instead of reading the native frame back. A transformed view's frame is still read, since it is its transformed bounding box.
• layoutNativeView() skips the native calls when the position is the one it last laid out, which _setNativeViewFrame would leave alone anyway.
• getSafeAreaInsets() checks iosIgnoreSafeArea and the managed-inset ancestor before reading the native insets.
• layout.measureNativeView() and Label's text measure return plain objects instead of writing into the CGSize, which goes through native struct setters.

Performance

xplat-benchmarks ns-core app (plain core layouts, no plugins), iPhone 17 Pro Max simulator (iOS 26.4), size M, 3 interleaved rounds of 10 iterations, median ms until painted. To reproduce, point apps/ns-core at each build of core, build it with scripts/build-ios.sh <simulator-udid> ns-core, and run npm run bench -- run --platform ios --device <udid> --apps ns-core --scenarios mount,relayout --sizes M --rounds 3 (see the repo's README):

Tests

• view-helper/safe-area-expansion.spec.ts runs the new expandBeyondSafeArea and the previous computation (getAvailableSpaceFromParent + getPositionFromFrame) on 2,000 generated frames inside a scroll view and a view controller, with notched insets and fractional positions, and requires identical rects (over 200 of them expanded).
• view-helper/frame-position.spec.ts checks the JS position against reading it back from the frame.
• apps/automated passes on the iOS 26.4 simulator (1827 OK, 0 failed), including the 137 SAFEAREA layout, list view, scroll view, repeater and web view tests. The source changes are iOS-only (.ios.ts files, plus two declarations in view-helper/index.d.ts).