@expo/ui first class support

[Brentlok]

Hey everyone 👋

We’ve started working on adding first-class Uniwind support for @expo/ui.

The goal is to make styling Expo UI components feel natural with Uniwind, while still respecting the native APIs exposed by @expo/ui across SwiftUI, Jetpack Compose, and universal components.

Initial scope

For the first version, we plan to support:

• SwiftUI components
• Jetpack Compose components
• Universal components, except web for now
• Mapping className to the appropriate component props
• Mapping color utilities through colorClassName
• Mapping some classes/styles to native modifiers where appropriate
• Full support for standard Uniwind variants like disabled:, portrait:, dark:, and others

Mapping className to style and props

For example:

<Column className="gap-4 items-center p-4" />

Would translate to something like:

<Column
  style={{
    gap: 16,
    padding: 16,
  }}
  alignment="center"
/>

Some utilities can be mapped directly to style values, while others need to become component-specific props.

Mapping colorClassName to color props

For color-only props, we’re considering dedicated class props such as colorClassName. (Like we already do for RN's components)

For example:

<Icon name="star.fill" colorClassName="accent-indigo-600" />

Would translate to:

<Icon name="star.fill" color="#4f39f6" />

This keeps color tokens, themes, and dark mode variants aligned with the rest of the Uniwind styling model.

Mapping classes to native modifiers

We would also like to map some classes/styles to native modifiers where that makes more sense than using regular style props.

For example:

<Button className="accent-indigo-600" />

On iOS, this could map to:

<Button modifiers={[tint('#4f39f6')]} />

This should let us support native platform behavior while still keeping the Uniwind API ergonomic.

Variants

Everything should work with standard Uniwind variants, for example:

We want the same variant system people already use in Uniwind to work with @expo/ui components as much as possible.

Feedback wanted

We’d love feedback from the community before locking in the initial API.

A few questions:

• Which @expo/ui components should we prioritize first?
• Should props like colorClassName be the preferred API for color props, or would you rather see another naming convention?
• Which classes should map to native modifiers instead of regular style props?
• Are there platform-specific APIs from SwiftUI or Jetpack Compose that you think Uniwind should support from day one?
• What would make this integration feel truly “first-class” for your app?

If you’re already using or experimenting with @expo/ui, we’d really like to hear what styling workflows you need most.

[wcastand]

Amazing! can't wait to use that
i only started recently to use expo/ui with sdk 56 making it 1.0

On my end i would say the priority are View/Button/Text and any component in the drop-in replacement list (mostly because i would guess people will start with those when they switch to expo/ui so supporting them would make it extra easy)

colorClassName i was never a fan of it but at the same time i can't think of a cleaner way since color is not possible.

When it comes to modifiers, i don't know enough yet about swift ui and jetpack to provide any insight into which one to map to sorry.

Other than this, i think what you describe sounds already amazing to me if we can have all this on first pass.

Thanks for the great works !

sorry for the lack of deep feedback, still new to expo/ui and modifiers.