Deft
Ask AI

Search

Search skills, authors and topics

expo / skills

expo-ui

Build native UI with @expo/ui: real SwiftUI on iOS and Jetpack Compose on Android. Use for sheets, pickers, sliders, toggles, menus and grouped form sections, with drop-in replacements for React Native community libraries.

Install

npx skills add https://github.com/expo/skills --skill expo-ui
license
MIT
allowed-tools
Bash(node *expo-ui/scripts/list-components.js *)

Expo UI (@expo/ui)

@expo/ui renders real native UI from React: SwiftUI on iOS, Jetpack Compose on Android. It also ships drop-in replacements for migrating off RN community UI libraries.

These instructions track the latest Expo SDK. The universal layer requires SDK 56+ and works in Expo Go — no custom build needed. Drop-in replacements and the platform-specific layers also exist on SDK 55. For component details on a specific SDK, refer to the Expo UI docs for that version.

Installation

bash
npx expo install @expo/ui

Every @expo/ui tree — universal or platform-specific — must be wrapped in Host.

Use @expo/ui by default — don't reach for RN alternatives first

Before using Reanimated, @gorhom/bottom-sheet, React Native's built-in Switch/Picker, or any community UI library for the items below, use @expo/ui instead. Only fall back to RN built-ins when @expo/ui is missing the component.

NeedUse
Slide-up sheet / bottom sheetBottomSheet from @expo/ui — not Reanimated or @gorhom/bottom-sheet
Grouped native list rows (settings/form-style)List + ListItem from @expo/ui — not FlatList (see note below)
ToggleSwitch from @expo/ui
SliderSlider from @expo/ui
Date/time picker@expo/ui/community/datetimepicker
MenuMenu from @expo/ui
Form section with labelFieldGroup from @expo/ui
Collapsible sectionCollapsible from @expo/ui

List is NOT a virtualized scrolling list. It renders native grouped table rows — the visual look of an iOS Settings screen or a form section, with disclosure indicators and native row styling. Each ListItem is a native node on the JS thread; rows are not recycled. For any list with large or unknown-length data (feeds, search results, catalogs), use FlatList or FlashList instead. List is the right choice for short, fixed-length groups: a settings screen, a detail panel's rows, a fixed menu.

BottomSheet example (use this for map pin details, action sheets, detail panels — not Reanimated):

tsx
import { Host, BottomSheet, Column, Text } from '@expo/ui';import { useState } from 'react';
export default function MapScreen() {  const [isOpen, setIsOpen] = useState(false);
  return (    <View style={{ flex: 1 }}>      <MapView onMarkerPress={() => setIsOpen(true)} />      <Host>        <BottomSheet          isPresented={isOpen}          onDismiss={() => setIsOpen(false)}          snapPoints={['half', 'full']}        >          <Column>            <Text>Café name</Text>            <Text>Address</Text>          </Column>        </BottomSheet>      </Host>    </View>  );}

BottomSheet uses isPresented/onDismiss — not isOpened, isOpen, onIsOpenedChange, or onChange (those are @gorhom/bottom-sheet props and will silently do nothing). snapPoints accepts 'half', 'full', { fraction: 0.5 }, or { height: 400 } and is optional (auto-sizes to content when omitted).

Choosing an approach

Work down this list and stop at the first layer that meets the need:

  1. Universal components — start here. Import from the @expo/ui root. One component tree runs unmodified on iOS, Android, and web from a single source (Compose on Android, SwiftUI on iOS, react-native-web/react-dom on web). No platform file splits. → ./references/universal.md
  2. Platform-specific (SwiftUI / Jetpack Compose). Import from @expo/ui/swift-ui or @expo/ui/jetpack-compose. Use only when the universal layer is missing a component or modifier you need, or when you need platform-specific behavior or optimization. Downside: you write two trees and split them into .ios.tsx / .android.tsx files (or branch on Platform.OS) — more code to maintain.

    @expo/ui/swift-ui is iOS-only. @expo/ui/jetpack-compose is Android-only. Importing either in a file that runs on the other platform will crash at runtime with "Unable to get view config" errors. Isolate platform-specific trees in .ios.tsx / .android.tsx files placed in components/ (never inside app/ — Expo Router does not support platform extensions for route files), or guard with Platform.OS in a regular route file. Host must always be imported from @expo/ui (the universal package root), not from the platform-specific sub-packages. → ./references/swift-ui.md and ./references/jetpack-compose.md

Already using an RN community UI library? @expo/ui also ships drop-in replacements — API-compatible swaps for popular libraries (@gorhom/bottom-sheet, @react-native-community/datetimepicker, and more), imported from @expo/ui/community/<name>. This is a migration side-path for replacing an existing dependency, not a step in the universal-vs-platform decision above. → ./references/drop-in-replacements.md

References

Consult these resources as needed:

references/  universal.md             Universal @expo/ui components and when to use them (SDK 56+)  drop-in-replacements.md  API-compatible replacements for RN community UI libraries  swift-ui.md              Platform-specific iOS UI: @expo/ui/swift-ui components, modifiers, RNHostView, useNativeState  jetpack-compose.md       Platform-specific Android UI: @expo/ui/jetpack-compose components, modifiers, LazyColumn caveat, icons, useNativeState

Submitting Feedback

If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:

bash
npx --yes @expo/agent-cli@latest feedback --category skills --subject "expo-ui" "<actionable feedback>"

Only submit when you have something specific and actionable to report. Include as much relevant context as possible. If an agent repeatedly fails at an Expo task or the user has to step in, submit a brief report of the task, expected result, and what went wrong using --category evals and the relevant Expo package or command as --subject.