Expo Examples

Expo Examples

When to Use

Use this skill when you need Expo's official example projects — the expo/examples repo of ~70 with-* integrations (Stripe, Clerk, Supabase, OpenAI, maps, Reanimated, SQLite, Skia, NativeWind, and more). Reach for it when:

• Integrating a third-party library or service into an existing Expo app and you want the canonical pattern Expo maintains against the current SDK.
• Scaffolding a greenfield project directly from an official example.
• Triaging which example matches a user's need (payments → with-stripe, auth → with-clerk, etc.).

expo/examples is Expo's official library of ~70 integration examples — directories named with-<library> (e.g. with-stripe, with-maps), each built around one library or service. These are not full apps: they're managed projects (no ios//android/ dirs — native setup is via config plugins), and the typical one is a single screen of ~100–200 lines. Mine them for the canonical integration pattern — the dependency set, app.json config plugins, and minimal wiring Expo maintains against the current SDK — and adapt that into the user's app. Don't expect to lift an application architecture from them.

Reach for an example before hand-rolling an integration. (Kinds — full-stack, showcases, starters — are noted in ./references/catalog.md.)

Two modes

1. Inspiration / adapt (most common) — the user already has a project. Find the matching example, read its key files, and apply the pattern to their code.
2. Scaffold — greenfield. Start a fresh project directly from the example.

Prerequisites

• gh (GitHub CLI) for API calls, OR curl/git as fallbacks.
• npx (Node) or bun for scaffolding via create-expo.
• For adapting into an existing app: the user's project must already be an Expo managed project on a known SDK version.

Procedure

1. Find the right example

Map the user's need to an example name (e.g. payments → with-stripe, auth → with-clerk). ./references/catalog.md is a categorized snapshot for fast triage — load it when you need to triage which example matches a user's request — but it drifts, so confirm against the live list:

# Live example names:
gh api repos/expo/examples/contents --jq '.[] | select(.type=="dir" and (.name|startswith(".")|not)) | .name'
# Aliases (renamed) + deprecated (dead/moved) examples — check before recommending:
gh api repos/expo/examples/contents/meta.json --jq '.content' | base64 -d

meta.json is the source of truth for what's renamed or dead (deprecated examples are removed from the repo tree but still listed here, each with a message). If an example is in its deprecated map, don't recommend it — follow the message to the modern path. If it's in aliases, use the destination.

2a. Inspiration mode — study without touching the user's project

The common case: the user already has an app and wants to see how Expo does something. Read the example as reference and apply the patterns by hand — never scaffold an example on top of their project.

First, list the whole example in one call. Integration code is often nested (e.g. Stripe's server routes live in app/api/), so a one-level listing misses the important files:

gh api 'repos/expo/examples/git/trees/master?recursive=1' \
  --jq '.tree[].path | select(startswith("with-stripe/"))'

Then read the high-signal files first: README.md (setup) → package.json (deps) → app.json (config plugins / permissions) → the integration code the manifest revealed → .env (required secrets). Per file:

gh api repos/expo/examples/contents/with-stripe/utils/stripe-server.ts --jq '.content' | base64 -d
# No gh? Raw URL (branch is master):
curl -s https://raw.githubusercontent.com/expo/examples/master/with-stripe/utils/stripe-server.ts

Reading more than a couple of files? Many integrations are spread across server routes, a client provider, and config (Stripe is). Skip the per-file calls — pull the whole example into a throwaway/gitignored dir (not the user's project) and read it freely with Grep/Read, then apply by hand:

npx degit expo/examples/with-stripe /tmp/expo-ref/with-stripe   # clean copy, no git history
# fallback without degit (sparse-checkout, no full ~64 MB clone):
git clone --depth 1 --filter=blob:none --sparse https://github.com/expo/examples.git /tmp/expo-ref/examples \
  && (cd /tmp/expo-ref/examples && git sparse-checkout set with-stripe)

Read from there with Grep/Read; delete the scratch dir when done.

Windows (PowerShell) note: /tmp/ does not exist. Use a local scratch path such as $env:TEMP\expo-ref\with-stripe or .\.scratch\with-stripe. Ensure the scratch dir is outside the user's project and gitignored.

2b. Scaffold mode — new project from an example

npx create-expo --example with-stripe   # short form:  npx create-expo -e with-stripe
bun create expo --example with-stripe    # with bun

3. Adapt into the user's app — non-destructively (critical)

When the user already has an app, add only what the example introduces; never overwrite their setup.

1. Version-align — don't copy pinned versions. Examples track the latest SDK, so their package.json pins won't match an older project. Add only the missing deps with npx expo install <pkg> (it resolves SDK-correct versions) instead of copying exact versions.
2. Merge config, don't replace it. Add only the app.json/app.config.* plugins and permissions the example introduces that the user lacks — keep their existing config block intact.
3. Port the integration code from the example into the user's app at the appropriate location.
4. Recreate env vars from the example's .env shape — it holds placeholders, never working secrets. Use YOUR_KEY-style placeholders; never commit live secrets.

Done when the integration code is ported and every dependency, config plugin, permission, and env var it needs is accounted for in the user's app — not when it merely looks wired up.

Pitfalls

• Default branch is master, not main (matters for raw URLs and sparse checkout). Using main will 404 on raw URLs and break sparse-checkout.
• Don't scaffold an example on top of an existing project. Inspiration mode means read-and-adapt by hand, never create-expo --example into a populated dir.
• Don't copy pinned versions from the example's package.json. They target the latest SDK; use npx expo install <pkg> to resolve SDK-correct versions for the user's project.
• Don't replace the user's app.json/app.config.*. Merge only the new plugins/permissions the example introduces.
• Deprecated examples are removed from the repo tree but still listed in meta.json under deprecated with a message pointing to the modern path. Don't recommend a deprecated example — follow the message.
• Aliases in meta.json map old names to a destination; use the destination when recommending.
• One-level listings miss nested integration code (e.g. Stripe's app/api/ server routes). Always use the recursive tree listing.
• .env in examples holds placeholders, not working secrets. Never copy real secrets from an example; never commit live keys.

Verification

• Confirm the example exists and is not deprecated/aliased:

  gh api repos/expo/examples/contents/meta.json --jq '.content' | base64 -d
  

• Confirm the example directory is present in the live tree:

  gh api repos/expo/examples/contents --jq '.[] | select(.type=="dir" and (.name|startswith(".")|not)) | .name'
  

• After adapting into the user's app, verify deps resolve against the user's SDK:

  npx expo install --check
  

• Verify config plugins are valid:

  npx expo config --type prebuild
  

• Verify the app still starts:

  npx expo start
  

• Single-click deploy sanity check (launch URL format): https://launch.expo.dev/?github=https://github.com/expo/examples/tree/master/<example>

Examples

• Payments → with-stripe
• Auth → with-clerk
• Maps → with-maps
• Styling (NativeWind) → see expo-tailwind-setup related skill

References

• ./references/catalog.md — categorized snapshot of the example library for fast triage. Load this when you need to map a user's request to an example name, then confirm against the live list above (the catalog drifts).

Related skills

• Tailwind / NativeWind styling → expo-tailwind-setup
• Native UI components → building-native-ui
• Authoring a native module → expo-module
• Upgrade the SDK before adopting a latest-SDK example → upgrading-expo

Limitations

• 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.