building-native-ui

Overview of building-native-ui skill

What the building-native-ui skill is for

The building-native-ui skill is a practical guide for creating polished Expo Router interfaces that feel native instead of merely cross-platform. It is most useful when you want an AI agent to make concrete UI decisions for React Native and Expo apps: route structure, iOS-style controls, headers, tabs, animations, media flows, visual effects, and platform-aware patterns.

Who should install it

This building-native-ui skill is best for frontend developers working in Expo or React Native who need more than generic component code. It especially fits teams building mobile-first products where navigation, native controls, motion, and platform conventions matter. If you are already using Expo Router or planning to, this skill gives better direction than a broad “build me a mobile UI” prompt.

Real job-to-be-done

Users typically install building-native-ui when they want an agent to turn a rough product idea into implementation-ready UI choices without guessing the Expo-specific path. The real value is not just sample code; it is reducing wrong starts around tabs, sheets, search, storage, media, icons, animations, and route organization.

What makes it different from a generic UI prompt

The strongest differentiator is that the skill encodes Expo-specific preferences and constraints. It points the agent toward:

• Expo Router file and layout conventions
• Native-feeling iOS controls and SF Symbols
• Reanimated-based motion instead of older animation approaches
• Practical platform boundaries such as when Expo Go works and when custom builds are required
• Focused reference docs for tabs, search, media, gradients, zoom transitions, and visual effects

What matters most before adopting it

Before you use building-native-ui for Frontend Development, know that it is opinionated. It pushes native patterns over generic cross-platform UI kits, prefers Expo-friendly APIs, and includes features with version or platform limits such as iOS-only capabilities, New Architecture requirements, and SDK requirements. That is good when you want a high-quality native feel, but it is a weaker fit for heavily web-shared design systems or framework-agnostic app scaffolding.

How to Use building-native-ui skill

Install the building-native-ui skill

If your agent supports Skills, add it from the Expo skills repository:

npx skills add https://github.com/expo/skills --skill building-native-ui

If your environment already has the Expo skills repo available, load the building-native-ui skill from plugins/expo/skills/building-native-ui.

Read these files first

For fastest adoption, do not start by skimming everything. Read in this order:

1. SKILL.md
2. references/route-structure.md
3. references/tabs.md
4. references/toolbar-and-headers.md
5. references/animations.md

Then pull in narrower references only if your feature needs them:

• references/form-sheet.md
• references/search.md
• references/media.md
• references/storage.md
• references/icons.md
• references/visual-effects.md
• references/zoom-transitions.md
• references/gradients.md
• references/webgpu-three.md

This path mirrors how real UI decisions usually happen: app structure first, then navigation, then screen behavior and polish.

Know the install context before prompting

A good building-native-ui install decision depends on your runtime constraints. The skill explicitly advises trying Expo Go first before making custom builds. That matters because some referenced capabilities do not work everywhere:

• CSS gradients need React Native New Architecture and are not available in Expo Go
• Apple Zoom transitions are iOS 18+
• Some toolbar and search patterns are iOS-only
• Form sheet examples require Expo Router stack setup, and some details require newer Expo SDK versions

If your app must run entirely in Expo Go, say so in the prompt. Otherwise the agent may choose features that force a development build.

Give the skill the right inputs

The building-native-ui usage quality depends heavily on context. Provide:

• Your Expo SDK version
• Whether Expo Go is required
• Target platforms: iOS, Android, web
• Whether you use Expo Router already
• The screen or flow you want built
• Design goals such as “native iOS settings feel” or “Instagram-like camera”
• Any hard requirements around storage, media, animations, search, or tabs

Weak input:
“Build a settings screen.”

Strong input:
“Using Expo Router on Expo SDK 55, build a settings area for iOS and Android. Must work in Expo Go. Use native-feeling controls for notification toggles, theme mode selection, and a storage section. Keep route files in app/ only and place reusable UI in components/.”

The stronger version gives the skill enough information to choose controls, avoid unsupported APIs, and respect route conventions.

Turn a rough idea into a complete prompt

A reliable prompt template for the building-native-ui guide is:

• Product context
• Platform targets
• Runtime constraints
• Screen list or route tree
• Interaction details
• Visual style goals
• Output format requested

Example:

“Use the building-native-ui skill to design and implement a photo detail flow in Expo Router. Target iOS first, Android acceptable. Try to stay compatible with Expo Go unless a feature clearly requires a custom build. I need:

• route structure for list, detail, and search
• native tabs if appropriate
• a large collapsing image header
• search in the header
• saved items persisted locally
• smooth Reanimated transitions
  Return:

1. recommended file tree
2. route files to create
3. key component code
4. note any features that require iOS-only APIs or custom builds.”

This prompt works because it asks the skill to make decisions, not just generate JSX.

Follow the skill's preferred workflow

In practice, the best building-native-ui usage workflow is:

1. Ask for route and navigation structure first.
2. Ask for native control choices per screen.
3. Add motion and headers after the structure is correct.
4. Add persistence, media, or search only when those flows are clear.
5. Finally, ask the agent to flag any custom build or platform-only requirements.

This prevents common rework, especially when a flashy UI concept conflicts with Expo Go, route conventions, or platform support.

Use the route conventions exactly

One of the highest-value parts of this skill is its Expo Router discipline. When prompting, tell the agent to follow the route rules from references/route-structure.md:

• Keep route files in app/
• Put non-route code outside app/
• Use _layout.tsx for stacks
• Use [id].tsx and [...slug].tsx correctly
• Ensure / always resolves to a route

This is more important than it looks. Generic prompts often produce mixed route and component files inside app/, which creates long-term maintenance issues.

Ask for native controls instead of custom widgets

If your goal is a native feel, explicitly ask the skill to choose built-in or platform-native controls where possible. The references suggest:

• Switch for binary settings
• segmented control for short mode toggles
• picker for longer option lists
• SF Symbols via expo-symbols instead of FontAwesome-style icon packs

That guidance is useful because many generic prompts default to over-customized controls that look less native and add extra design debt.

Prefer Reanimated when motion matters

The skill is opinionated here: use Reanimated v4 instead of React Native’s built-in Animated API for serious UI motion. If your screen needs entering, exiting, layout, or scroll-driven animations, state that directly. This helps the agent choose patterns already supported by the references and avoids weaker baseline animation code.

Match feature ideas to the right reference file

A quick repository-reading map helps when the first output is too broad:

• animated transitions or gesture polish → references/animations.md
• sliders, switches, segmented controls → references/controls.md
• modal card experiences → references/form-sheet.md
• gradients and layered backgrounds → references/gradients.md
• icon systems → references/icons.md
• camera, video, audio, file saving → references/media.md
• app folder design and params → references/route-structure.md
• header search and filtering → references/search.md
• local persistence → references/storage.md
• native tabs and migration choices → references/tabs.md
• stack headers, menus, toolbar actions → references/toolbar-and-headers.md
• blur and glass effects → references/visual-effects.md

Practical prompt examples that improve output

Better than:
“Make a tabbed app UI.”

Use:
“Apply building-native-ui to recommend whether this app should use Expo Router NativeTabs or JS tabs. The app has Home, Search, Inbox, and Profile. Prioritize native behavior on iOS, keep labels short, and explain any migration tradeoffs.”

Better than:
“Add icons and animations.”

Use:
“Using building-native-ui, replace generic icon usage with SF Symbols where supported and add Reanimated-based entering and scroll-linked animations for the header. Keep the implementation maintainable and call out any platform fallbacks needed.”

These prompts improve output because they force the agent to use the skill’s actual decision rules rather than producing generic code.

building-native-ui skill FAQ

Is building-native-ui only for iOS-style apps?

No, but it leans strongly toward native-first mobile UI and includes several iOS-oriented recommendations such as SF Symbols, Apple Zoom transitions, toolbar patterns, and certain sheet behaviors. It still helps on Android because the route, animation, media, storage, and Expo Router guidance remain useful.

Is the building-native-ui skill beginner friendly?

Yes, if you already know basic React Native or Expo. The skill is more implementation-oriented than conceptual, so beginners get the most value when they ask for one screen or flow at a time and provide version and platform details up front.

What does building-native-ui do better than a normal prompt?

The main advantage is constraint-aware output. A normal prompt may invent the wrong navigation structure, choose non-native icon systems, ignore Expo Router conventions, or suggest features that need a custom build without warning you. building-native-ui narrows those choices to patterns grounded in Expo references.

When should I not use building-native-ui?

Skip it if your main goal is:

• a design-system-agnostic React app
• a web-first UI
• a fully custom branded component library with little interest in native conventions
• framework-neutral mobile architecture guidance

In those cases, the skill’s Expo and native-pattern bias may be too narrow.

Does building-native-ui require Expo Router?

Practically, yes for best results. Much of the skill is organized around Expo Router concepts such as _layout.tsx, route folders, native tabs, form sheets, and headers. You can still borrow control or animation advice outside Expo Router, but the strongest value comes when your app follows that stack.

Do I need a custom dev build to use this skill well?

Not always. The skill explicitly recommends trying Expo Go first. But some features referenced by the skill can require more:

• New Architecture for CSS gradients
• newer iOS versions for Apple-specific transitions
• packages or APIs that are not available in Expo Go

If build simplicity matters, say “Expo Go only” in your prompt.

How to Improve building-native-ui skill

Start with constraints, not aesthetics

The fastest way to improve building-native-ui results is to specify hard constraints before asking for UI polish:

• Expo Go only or custom build allowed
• SDK version
• iOS-only vs cross-platform
• router already installed or not
• whether New Architecture is enabled

Without that, the agent may choose attractive patterns that are expensive to adopt.

Ask for decisions, not just code

This skill is most useful when you ask it to choose among native options. For example:

• “Should this be segmented control or tabs?”
• “Should search live in the header or in-content?”
• “Should I use NativeTabs here?”
• “Can this visual effect stay in Expo Go?”

Decision-oriented prompts produce better output than “generate a screen” because the repository is strongest as a pattern guide.

Provide a target route tree

A lot of output quality comes from navigation clarity. Even a rough route tree helps:

• /
• /search
• /items/[id]
• /settings/profile

This gives the skill enough structure to apply Expo Router conventions and avoid messy file placement.

Name the exact interaction patterns you want

Do not just say “make it feel premium.” Specify the interaction:

• scroll-reactive header
• modal form sheet with footer
• native search in header
• camera with flip and flash controls
• local saved state
• zoom-like image transition

Those phrases line up with the skill’s reference files and lead to more grounded implementation choices.

Watch for these common failure modes

The most common weak outputs are:

• route and component files mixed inside app/
• custom icon packs suggested instead of SF Symbols
• old animation APIs used where Reanimated is better
• unsupported features proposed without calling out platform or build requirements
• overdesigned controls where native controls would be simpler and better

If you see one of these, ask the agent to revise against the relevant reference file.

Ask the agent to annotate platform limits

A high-value refinement step is:
“Revise this using building-native-ui and annotate each feature as Expo Go compatible, custom-build required, iOS-only, or New Architecture only.”

This turns a nice-looking response into an adoption-ready plan.

Iterate by layer, not by rewriting everything

For best results, refine in passes:

1. route structure
2. screen skeletons
3. control selection
4. navigation and headers
5. animation and visual polish
6. storage or media integration

This layered workflow fits how the skill is organized and makes it easier to catch bad assumptions early.

Request file-specific implementation

When the first answer is too generic, ask for changes in actual files:

• app/_layout.tsx
• app/index.tsx
• app/search.tsx
• app/items/[id].tsx
• components/ItemCard.tsx

That pushes the agent to use building-native-ui as an implementation guide rather than a design brainstorm.

Use the references to challenge weak outputs

If the agent gives generic advice, point it back to the repo:

• “Rework this using references/route-structure.md conventions.”
• “Switch this animation approach to the patterns in references/animations.md.”
• “Replace the icons with the references/icons.md guidance.”
• “Check whether this should be a form sheet based on references/form-sheet.md.”

This is the most practical way to get meaningful information gain from the skill instead of a shallow summary.

Improve building-native-ui results with a better final prompt

A strong final prompt for building-native-ui for Frontend Development looks like this:

“Use the building-native-ui skill to implement an Expo Router feature for a saved-recipes app. Target iOS and Android, but keep Expo Go compatibility if possible. I need a route structure, native-feeling tabs, a search experience, recipe detail pages, local persistence for favorites, and smooth header animations. Put only routes in app/, use Reanimated for motion, prefer SF Symbols where appropriate, and clearly mark any part that requires iOS-only APIs, New Architecture, or a custom build.”

That prompt works because it combines product goal, technical limits, route discipline, UX expectations, and review criteria in one place.