topBar.searchBar
The search of the screen, in the bar.
Options
Every key, with the platforms it works on. A dashed platform means the key does nothing there.
21 options shown
Whether the screen has a search. false removes it and closes an open one, taking its results component away. A search added to a shown screen with hideOnScroll starts hidden on iOS.
true opens the search with the keyboard once the screen shows; false hides the keyboard and leaves the search open. On Android a search added by mergeOptions opens only when the same mergeOptions carries focus.
Whether the search field shows when the screen opens, goes away as the content scrolls and comes back at the top of the list. On iOS the screen then goes under the bar by itself, and the list must keep its first rows visible (contentInsetAdjustmentBehavior="automatic"); it doesn't work with largeTitle.collapseOnScroll: false. On Android the bar leaves with the search, as with topBar.hideOnScroll, while the search is closed; not under a large title.
Whether the bar hides while searching and the field moves to the top. With a results component, the results screen lies under the field at the top. Android's open field always takes the row of the bar.
Whether the screen is dimmed while searching. On Android the dimming covers the screens below the bar while the open field is empty and there is no results component, and a tap on it closes the search.
The color of the search field; null returns the system color. On iOS the library keeps the color against the system resetting it under a large title. On Android it tints the pill and fills the field in the bar, by default the theme's pill color.
The color of the cursor and the selection; null returns the system color.
The text of the empty field. Without it, the system "Search" in the language of the device.
The text of the field. The screen opens with it once, when it is created, and mergeOptions replaces what was typed. No search-updated event comes for it, and an unchanged text leaves the cursor alone. Other mergeOptions and coming back to the screen don't reset what was typed.
Where the field is. On iOS 16+: 'stacked' under the title; 'automatic' as the system decides (at the bottom on iPhone with iOS 26, in the bar on iPad); 'integrated' in the bar, at the bottom or in the toolbar on iPhone with iOS 26 and when there is room, else a magnifier in the bar; 'integratedButton' the same, with a magnifier on iPad always while closed; 'integratedCentered' the same, centered in the bar on iPad, in tab controllers and with a style 'browser' or 'editor'. Before iOS 26 every 'integrated…' is a field in the bar; before iOS 16 the option is not read. On Android 'stacked' and 'automatic' are the pill under the title, and every 'integrated…' is a magnifier last among the buttons, always in the bar.
The filters: segments under the field (at the top of the screen when the field is at the bottom) on iOS, a row of chips on Android. The search events carry the id of the selected one as scope, and picking one sends a search-updated event. An empty list removes the strip, also from an open search. On iOS scopes added to an open search show at its next opening.
The id of the scope, sent as scope in the search events and matched by selectedScope. Android drops a scope without one.
The label of the segment or chip. On Android, the id without it.
The identifier tests find the segment or chip by.
The id of the selected scope; without it, or with an unknown id, the first. The user's pick stays with the screen, after coming back, through a mergeOptions that sends the same value again and setDefaultOptions. A mergeOptions into the screen with another value switches the scope without an event.
When the strip of scopes shows. On iOS 16+: 'automatic' (on iOS 26, once the user types), 'onTextEntry', 'onSearchActivation'; before iOS 16 while searching. On Android 'automatic' and 'onSearchActivation' show it as soon as the search is open, 'onTextEntry' once the field has text.
Tokens in front of the text of the field. The search events carry the ids of the tokens in the field as tokens; deleting a token sends a search-updated event, and what the user deleted (or brought back with Undo) stays with the screen until a mergeOptions gives other tokens. Closing the search clears the field and its tokens. An empty list removes them all.
(iOS 16+, Android) The suggestions shown while searching. Picking one sends a suggestion-picked event with its id to the screen; the text stays and the list goes. They also go when the user types on; the list a mergeOptions gives shows again, the same one too, usually on a search-updated event. An empty list removes them.
A screen of its own for the results: a React component over the screen from the moment the search opens (resultsActivation) until it closes. It gets the search events with its own component id, and the lifecycle events on each show and hide. A different component makes a new search, closing an open one.
When the results component shows: 'onSearchActivation' as soon as the search opens, also with an empty field; 'onTextEntry' while the field has text, the screen being visible before. A change by mergeOptions while the search is open applies at once.
The identifier tests find the search field by (the pill, the field in the bar, the search view field, the magnifier). The magnifier of the integrated placements gets <testID>.button, the cancel button <testID>.cancel and the clear button <testID>.clear; on iOS the system draws the cancel button, so it may not take one.