expo-dev-client

Overview of expo-dev-client skill

What expo-dev-client does

The expo-dev-client skill helps you decide when you actually need an Expo development client, then guides you through configuring and building one with EAS Build locally or for TestFlight. Its real job is not just “make a build,” but “get a custom native-capable test app onto real devices without guessing through Expo docs.”

Who should use this skill

This skill is best for:

• Expo teams adding native modules
• Developers testing local Expo modules or custom native code
• Apps that use Apple-specific targets like widgets, app clips, or extensions
• Teams that need a repeatable path to internal iOS testing via TestFlight

If your app runs fully in Expo Go, this skill is usually unnecessary.

The main install decision

The biggest adoption question is simple: do you need a development client at all? The expo-dev-client skill is valuable because it answers that early. It explicitly pushes you to try Expo Go first with npx expo start, which prevents wasted build time and unnecessary EAS complexity.

What makes expo-dev-client different from a generic Expo prompt

A generic prompt might tell an agent to “set up Expo dev client,” but this skill is more decision-oriented. It focuses on:

• the threshold for needing a dev client
• the required eas.json shape
• the difference between local and cloud/TestFlight builds
• the practical command path for deployment-style testing on physical devices

That makes it more useful for setup and release-adjacent workflows than a broad Expo assistant prompt.

How to Use expo-dev-client skill

Install the expo-dev-client skill

Install it in your skills-compatible environment with:

npx skills add https://github.com/expo/skills --skill expo-dev-client

Because this skill is compact and centered in SKILL.md, installation is mainly about making it available for reuse during Expo native-testing tasks.

Start with the job-to-be-done, not the command

Before invoking the expo-dev-client skill, define the actual goal:

• “I added a native SDK and need to test on an iPhone”
• “We need a branch-specific dev client for QA”
• “Our app now includes a widget, so Expo Go is no longer enough”
• “We want an iOS development build distributed through TestFlight”

This matters because the skill is strongest when the need for custom native code is clear.

Check whether Expo Go is enough first

A common mistake is reaching for expo-dev-client too early. The recommended first test is:

npx expo start

If your app works in Expo Go, stop there. A development client adds build time, signing requirements, and distribution overhead. Use this skill only when native capabilities force that step.

Know the best-fit triggers

Use expo-dev-client when your project includes:

• local Expo modules
• custom native code
• third-party native modules unavailable in Expo Go
• Apple targets such as widgets, app clips, or extensions

These are the cases where a dev client changes from “optional” to “required.”

Prepare the minimum input an agent needs

If you want an agent to use the expo-dev-client skill well, give it:

• target platform: ios, android, or both
• intended distribution path: local install, internal testing, or TestFlight
• whether the app already has EAS configured
• your current eas.json
• whether the app uses native modules not supported by Expo Go
• any versioning or signing constraints

Without that context, the agent can still suggest commands, but it may miss the right build profile or over-prescribe setup.

Use a stronger prompt than “set up expo-dev-client”

A weak prompt:

Set up expo-dev-client.

A stronger prompt:

Use the expo-dev-client skill to determine whether this Expo app needs a dev client. We added a third-party native iOS SDK and need a TestFlight-distributed development build for internal QA. Review this eas.json, identify missing settings, and give the exact commands for building and submitting.

Why this works better:

• it asks for fit validation first
• it names the native trigger
• it specifies the target workflow
• it provides config for concrete correction

Configure eas.json correctly

The key configuration surfaced by the skill is a development build profile with developmentClient: true, typically alongside version automation:

{
  "cli": {
    "version": ">= 16.0.1",
    "appVersionSource": "remote"
  },
  "build": {
    "production": {
      "autoIncrement": true
    },
    "development": {
      "autoIncrement": true,
      "developmentClient": true
    }
  },
  "submit": {
    "production": {},
    "development": {}
  }
}

The important fields are:

• developmentClient: true: tells EAS to bundle the development client
• autoIncrement: true: reduces build-number friction
• appVersionSource: "remote": keeps versioning consistent through EAS

Build for TestFlight when remote device testing matters

For iOS teams, the highest-value expo-dev-client usage path is often TestFlight:

eas build -p ios --profile development --submit

This is the practical “expo-dev-client for Deployment” flow when you need a dev-capable app distributed to testers, not just a local artifact. It combines cloud build and submission, which is usually faster than piecing together separate steps.

Use local builds when speed or privacy matters

If you do not need TestFlight, local builds can be the better workflow:

• faster iteration in some environments
• more control over local tooling
• useful for device testing before wider internal rollout

Choose local when you are debugging setup or validating a native integration on your own device. Choose TestFlight when you are coordinating with QA or non-technical testers.

Read the right repository file first

This skill is simple: start with SKILL.md. There are no extra support directories like resources/, rules/, or helper scripts in this skill path, so most of the usable guidance is already concentrated there.

That also means users should not expect deep automation logic; this is primarily a practical decision-and-workflow guide.

Suggested workflow for real projects

A reliable expo-dev-client guide workflow is:

1. Confirm whether Expo Go fails for a native reason.
2. Review or create eas.json.
3. Add a development profile with developmentClient: true.
4. Decide between local build and TestFlight distribution.
5. Run the exact EAS build command for your platform.
6. Test on a physical device.
7. Revisit profile settings if versioning or submission behavior is off.

This order reduces wasted build cycles and catches the “didn’t need a dev client” case early.

expo-dev-client skill FAQ

Is expo-dev-client only for advanced Expo apps?

Mostly yes. Beginners can use it, but the skill is most relevant once an app outgrows Expo Go due to native requirements. If you are still in pure managed-workflow territory, it may not add value yet.

Is expo-dev-client the same as just installing expo-dev-client in a project?

No. The expo-dev-client skill is guidance for the workflow around development-client builds. It helps with when to use them, how to configure EAS, and how to choose a build path. It is not merely a package-install reminder.

When should I not use the expo-dev-client skill?

Do not use it when:

• your app already works in Expo Go
• you only need JavaScript-level iteration
• you are looking for a full release-build guide rather than development-client setup
• your problem is unrelated to native capabilities or build distribution

How is this different from a normal Expo troubleshooting prompt?

A normal prompt may produce generic build advice. The expo-dev-client skill is narrower and therefore better at install-decision guidance: it emphasizes the “need a dev client or not?” checkpoint and the exact EAS profile details that commonly block adoption.

Is expo-dev-client useful for Android too?

Yes, but the strongest explicit guidance in the skill excerpt is around iOS and TestFlight. The underlying logic still applies to Android development builds when custom native code requires a dev client instead of Expo Go.

Is this good for deployment workflows?

Yes, within limits. expo-dev-client for Deployment is best understood as internal distribution of development builds, especially through TestFlight for QA or branch testing. It is not a substitute for full production release planning.

How to Improve expo-dev-client skill

Provide the current project state up front

To get better results from the expo-dev-client skill, include:

• your eas.json
• target devices and platform
• whether this is local-only or TestFlight
• what native module or target forced the change
• whether Expo Go was already tried

This helps the agent move from generic guidance to exact edits and commands.

Ask for a decision before asking for steps

A high-quality prompt starts with:

First determine whether this app truly needs expo-dev-client.

That single instruction improves output quality because the skill’s main value is avoiding unnecessary dev-client setup.

Include config snippets for review

If you paste your existing eas.json, an agent can:

• detect missing developmentClient: true
• suggest versioning fixes
• align submit and build profiles
• avoid inventing configuration you do not need

This is much better than asking from scratch.

Be explicit about distribution intent

The right command depends on whether you want:

• a local development build
• a cloud build for device install
• a TestFlight-submitted iOS build

If you do not state that, the first output may be technically correct but operationally wrong for your team.

Watch for the main failure mode

The most common failure is using expo-dev-client for apps that should stay in Expo Go. The second is under-specifying EAS configuration and then blaming the skill for vague output. Both are preventable if you provide the native requirement and current config.

Iterate after the first answer

After the first response, ask follow-ups like:

• “Validate this eas.json against a dev-client TestFlight workflow.”
• “Rewrite the build commands for Android only.”
• “Assume our app uses a widget extension; what changes the decision?”
• “Minimize the setup to the smallest working development profile.”

This pushes the expo-dev-client skill from generic explanation into project-specific execution.

Improve team adoption with a standard prompt

If multiple developers will use this skill, create a reusable internal prompt template such as:

Use expo-dev-client to assess whether this Expo app requires a development client. Here is our eas.json, target platform, distribution goal, and native dependency list. Return: 1) decision, 2) config changes, 3) exact commands, 4) likely blockers.

That makes outputs more consistent and reduces onboarding friction.

Use the skill as a gate, not just a recipe

The best way to improve expo-dev-client usage is to treat it as a decision gate before building. If the skill is used only after the team already committed to a dev client, you lose its biggest advantage: preventing unnecessary native-build workflow overhead.