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.
• You have signed the CLA.
• All existing tests are passing.
• Tests for the changes are included.

What is the current behavior?

On iOS, ListViewCell.willMoveToSuperview(nil) calls ListView._removeContainer, which removes the cell's item view from the ListView. When UIKit reuses the cell, _prepareCell adds the view back and sets up its native views again.

UIKit takes cells out of the table on reloadData, which happens on every ObservableArray splice. In release builds the rebuild then fails in one of two ways:

• Crash: NSInvalidArgumentException: -[DictionaryAdapter CGColor]: unrecognized selector (or _resolvedMaterialWithTraitCollection: on iOS 26). The data source then returns nil, and UIKit aborts in -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:].
• Frozen screen: the screen stops redrawing while the view tree keeps changing, and taps have no visible effect.

Repro (iOS 26.5 simulator, release build, @nativescript/core 9.1.3, @nativescript/ios 9.1.1):

1. Use a ListView of two-column product rows bound to an ObservableArray.
2. Sort controls clear the array and push a new page.
3. Scroll, then switch sorts quickly.

Out of 6 runs of that flow:

• with plain bound templates, the screen froze in 5;
• with rows filled imperatively in itemLoading, the app crashed in all 6.

What is the new behavior?

ListViewCell no longer tears down its item view in willMoveToSuperview. Item views stay with their reusable cell and are disposed with the ListView: they remain in _map, so eachChildView covers them. The number of item views is still bounded by the number of cells UIKit creates. The _prepareCell path that swaps in a different view returned from itemLoading still calls _removeContainer.

Verification with the same app and flow, with core patched (via patch-package) and nothing else changed:

• 10 of 10 stress runs passed with no crash or freeze.
• An end-to-end flow passed across search paging, product, cart and tab switching.

ListViewHeaderCell.willMoveToSuperview uses the same pattern for sticky headers. This PR leaves it alone because I haven't reproduced a failure there.