What does this skill do, and when should you use it?
This skill is for teams with an existing native iOS or Android app that want to adopt React Native incrementally. It explains two approaches: isolated delivery as an AAR or XCFramework, and integrated inclusion in the existing Gradle or CocoaPods build. It covers approach selection, shared prerequisites, version requirements, and troubleshooting. Expo SDK 55 is the minimum supported version for brownfield integration.
It helps choose isolated or integrated integration based on Node.js and React Native tooling requirements, hot reload, source maps, repository ownership, and release cadence. It explains consuming an AAR/XCFramework or adding React Native and Expo to Gradle and CocoaPods setups, including native entry points such as ReactActivity and RCTRootView. It also identifies troubleshooting areas involving Metro connectivity, builds, signing, and module resolution.
- An Android team wants to consume React Native as an AAR in an existing Kotlin application without installing Node.js.
- An iOS team wants to consume a prebuilt XCFramework in an existing Swift application while keeping RN code in a separate repository.
- A single team owns both native and RN code and wants Expo included directly in its Gradle and CocoaPods builds.
- A legacy native application is adopting React Native incrementally and needs an architecture decision between isolated and integrated approaches.
- A brownfield project needs to verify its Expo SDK version, autolinking entry points, and build-environment prerequisites.
How do you install this skill?
- The references state both Expo SDK 54 and SDK 55 as minimum requirements; verify against the official template and the actual APIs for the target SDK before adoption.
- Troubleshooting includes rm -rf commands for Maven, iOS build, Pods, and related paths; validate targets, preserve needed state, and prepare recovery before running them.
- Remote private Maven publishing involves usernames, passwords, or tokens; use tightly scoped credentials through controlled environment variables and confirm the destination before publishing.
- No executed build or test evidence is included for the skill's key paths.
- Shell / CLI
- Local filesystem
Node.js LTSYarnCocoaPods for integrated iOS builds
This skill is part of the expo/skills collection. Install the collection with the Skills CLI: npx skills@latest add expo/skills --skill '*'. The README also documents codex plugin add expo@openai-curated for Codex and claude plugin install expo@claude-plugins-official for Claude Code. The source does not provide a CLI command for installing only expo-brownfield.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/expo/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/plugins/expo/skills/expo-brownfield" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- I have an existing Kotlin Android app and want to embed Expo/React Native as an AAR. Which brownfield approach fits?
- How do I integrate Expo and React Native into an existing Swift/CocoaPods project?
After installation, ask the agent a concrete request such as: “I have an existing Kotlin Android app and want to embed Expo/React Native as an AAR. Which brownfield approach fits?” or “How do I integrate Expo and React Native into an existing Swift/CocoaPods project?” When creating the project, pin the SDK explicitly, for example npx create-expo-app@latest my-project --template default@sdk-55, and use the same Expo SDK across the RN project and embedded dependencies.
What are this skill's strengths and limitations?
- Covers both isolated and integrated brownfield architectures.
- Provides decision rules based on team ownership, tooling, repository separation, and release cadence.
- Addresses both iOS and Android, including common Metro, build, signing, and module-resolution issues.
- Clearly states the Expo SDK 55 minimum version.
- The source presents implementation guidance; it does not show that the skill automatically builds or edits projects.
- Both approaches require Node.js LTS and Yarn in the environment that builds the React Native side.
- Integrated iOS builds additionally require CocoaPods; isolated consumers avoid RN tooling but the RN build side still has prerequisites.
- The source provides no test suite or automated validation results.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Expo Brownfield Integrator this page | 58 · Recommended | ★ 2.9k | 22d ago | MIT |
| React Native Brownfield Migration | 53 · Use with care | ★ 1.7k | 19d ago | MIT |
| Expo Native UI Builder | 59 · Recommended | ★ 2.9k | 22d ago | MIT |
| Expo Web-to-Native Migration | 52 · Use with care | ★ 2.9k | 22d ago | MIT |
| React Native Migration Assessor | 57 · Use with care | ★ 1.7k | 19d ago | MIT |
The source explicitly compares isolated and integrated integration. Isolated integration ships an AAR/XCFramework and fits native teams that do not want Node.js or RN tooling, or that maintain and release code in separate repositories. Integrated integration adds React Native sources to Gradle/CocoaPods and fits one team owning everything while requiring seamless hot reload and JS source maps.
How did FollowSkills review this skill?
The material stays within the stated integration scope and describes build-time versus consumer-side dependencies, publication targets, and environment-variable credential flow. However, remote publishing and native build changes have external effects, while explicit user confirmation, least-privilege guidance, rollback procedures, and security review steps are incomplete, so points are deducted.
The isolated and integrated paths, platform configuration, troubleshooting, and development/production differences are documented in useful detail. However, the references conflict on the minimum SDK requirement (SDK 54 versus SDK 55), and no committed test suite or statically verifiable execution evidence covers the key paths. Under static calibration, the score is capped at 10 and reduced for this uncertainty.
The audience, approach-selection rules, Android/iOS/monorepo scenarios, and several non-fit cases are reasonably clear. Trigger boundaries, input/output contracts, compatibility with non-standard build systems, Chinese-language support, and mainland-China network reachability are not sufficiently addressed, so points are deducted.
The skill has layered references, installation commands, examples, version guidance, troubleshooting, an MIT license, and repository maintenance workflows. It lacks a skill-specific version, changelog, clearly named maintenance owner, and explicit update path; some operational assumptions are distributed across the documents, so points are deducted.
The documentation supplies directly reusable Gradle, Podfile, Kotlin, Swift, and publication examples that cover the core brownfield task. There is no verified build result or representative output evidence, and the SDK/API inconsistency may cause rework. Static calibration therefore caps the score at 7 and warrants a conservative score.
Expo documentation and GitHub template references, plus repository CI checks, provide some auditable support for the configuration claims. The selected skill has no dedicated tests, build artifacts, execution logs, or independent corroboration, so static calibration caps the score at 5 and points are deducted.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →