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?

SegmentedBarBase.onItemsChanged and TabViewBase.onItemsChanged adopt each new item by calling this._addView(item), which throws when the item already has a parent:

View already has a parent. View: SegmentedBarItem(...) Parent: SegmentedBar(...)

Nothing ever un-parents those items. parent is only cleared by _removeView, and neither widget touches its items when it is destroyed — SegmentedBar.disposeNativeView only clears the tab listener / selection handler. So once a SegmentedBar is torn down, its items keep pointing at the dead bar forever.

The practical consequence: a component that holds a SegmentedBarItem[] field and binds it to a SegmentedBar inside a ListView item template crashes. ListView creates a fresh SegmentedBar per cell, all bound to the same array, so the second cell throws.

Originally reported as NativeScript/nativescript-angular#900.

@nativescript/angular currently works around this in its renderer by reaching in and assigning item.parent = undefined on every array-valued binding. That bypasses _removeView entirely, so _tearDownUI / _parentChanged never run and _context stays set — which makes _setupUI hit its this._context === context early return, and the item is never added to the new parent's native visual tree. Fixing it here lets that workaround go away.

What is the new behavior?

onItemsChanged now detaches an item from its previous parent through the public API before adopting it:

if (item.parent && item.parent !== this) {
    item.parent._removeView(item);
}

this._addView(item);

Applied identically in segmented-bar-common.ts and tab-view-common.ts (the latter keeps its existing "TabViewItem must have a view" check ahead of the detach). Because the detach goes through _removeView, the item is unloaded and torn down properly, _context is cleared, and _addView on the new parent can add it to the native visual tree.

Re-binding a shared item array no longer throws, and the items end up parented to the widget they were last assigned to.

Known and accepted limitation

If the previous parent is still alive, this steals the item from it, and that parent's items array will still list the now-detached item. This is inherent: a View has exactly one parent, so sharing a single item array between two live hosts cannot work. The goal here is "don't crash, last binding wins", not multi-parent support.

Tests

Added to apps/automated/src/ui/segmented-bar/segmented-bar-tests.ts and apps/automated/src/ui/tab-view/tab-view-tests.ts:

• assigning one items array to a second widget while the first is still alive does not throw, and each item's parent becomes the second widget;
• assigning the items of an already torn-down widget to a new one does not throw, and the native items/tabs are actually created for the new host (this is what the item.parent = undefined workaround got wrong).

All four new tests pass. The full apps/automated suite was run on an iOS 26 simulator against both main and this branch: 1800 → 1804 passing, with an identical set of 12 pre-existing SAFEAREALAYOUT *_tab_bar_flat inset failures on both, so this change introduces no regressions.