domains / families / software-engineering / expo-brownfield

expo-brownfield

combined

Integrate Expo and React Native into an existing native iOS or Android app. Use for brownfield, embedding a React Native screen in SwiftUI/UIKit or Kotlin, or AAR/XCFramework packaging. Covers isolated and integrated approaches. For building or distributing a purely native app with EAS, use eas-app-stores. Integrate Expo and React Native into an existing native iOS or Android app. Use when the user mentions brownfield, embedding React Native in a native app, AAR/XCFramework, or adding Expo to an existing Kotlin/Swift project. Covers both the isolated approach and the integrated approach.

When to use

• Use this skill when you need integrate Expo and React Native into an existing native iOS or Android app. Use when the user mentions brownfield, embedding React Native in a native app, AAR/XCFramework, or adding Expo to an existing Kotlin/S…

When not to use

• Use this skill only when the task clearly matches its upstream product or API scope.
• Verify commands, API behavior, pricing, quotas, credentials, and deployment effects against current official documentation before making changes.
• Do not treat generated examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.

Skill page

Conflict

The expo/skills copy is the upstream procedure and contains critical operational constraints the mirror omits, such as inspecting the host, preserving the native shell, and the explicit prohibition against running prebuild in a manually maintained native host. The sickn33 copy adds a hard version floor (SDK 55) and a specific create-expo-app command that the upstream copy does not state, while also disagreeing on prerequisites (Yarn vs. project package manager) and the integrated-approach rationale (hot reload vs. shared build ownership). Crowning one copy would hide either the safety constraints or the version pinning, so the copies must be combined.