expo/examples: a directory of runnable Expo starters, not a library

What expo/examples is, and the problem it removes

Setting up an Expo project that combines React Native, a navigation library, an authentication provider, and a storage backend usually means reading several sets of docs and guessing at the wiring between them. expo/examples is a repository of complete, runnable projects that already contain that wiring. Each top-level directory is a separate example: with-clerk, with-convex, with-socket-io, with-skia, with-maestro, with-sentry, and roughly forty others. The README describes the repository as "Easy example for using features, libraries, and other integrations with Expo!"

It is aimed at developers who are starting a new Expo app and want a reference implementation rather than an empty template. It is not a library. Nothing here is published as a package you add to an existing codebase, and there are no releases listed for the repository. The unit of consumption is the example directory, and the intended way to get one is through create-expo rather than by cloning the whole repository.

How the repository is laid out and how an example becomes your project

The repository is flat. Every example sits at the top level next to the README, the LICENSE, contributing.md, meta.json, and a script named upgrade-dependencies.sh. The primary language is TypeScript, and the topics list includes react-native-web and expo-web, which matches the README's description of creating "universal React and React Native projects." An example such as with-router-ai therefore targets more than one platform from a single codebase.

There is no shared workspace package that all examples import. Each directory is self-contained, which means the dependency set, the Expo SDK version, and the configuration files live inside that example. The practical consequence is that examples can drift apart in the SDK versions they target, and the top-level README does not publish a table mapping examples to SDK versions. If you need to know what an example was built against, you read its own package.json.

The upgrade-dependencies.sh script at the repository root suggests the maintainers batch-update dependencies across examples rather than relying on a workspace lockfile. That is a reasonable choice for a collection of independent starters, but it also means an individual example's freshness is not guaranteed by the repository's most recent commit.

Creating your first project from an example

The README gives the scaffolding command directly. It uses create-expo with an --example flag, and the package can be run through npx or bun. The example it uses is with-router-ai.

npx create-expo --example <Example>
bun create expo --example <Example>

# Example - with-router-ai

bun create expo --example with-router-ai

After the command finishes, create-expo has produced a new project directory populated from that example. From there you work inside the generated project, not inside a clone of expo/examples. The README does not document the interactive prompts, the directory name that results, or whether a package manager can be preselected, so expect the scaffolded output to be the source of truth for what you got.

The README also documents a launch badge for single-click deployment. You add the badge markup to your own project's README and replace the placeholder with your repository URL.

[![Launch with Expo](https://github.com/expo/examples/blob/master/.gh-assets/launch.svg?raw=true)](https://launch.expo.dev/?github=<GH_REPO_URL>)

Replace <GH_REPO_URL> with the URL of your GitHub repository, for instance https://github.com/expo/examples/tree/master/with-router-ai. The badge points at launch.expo.dev with a github query parameter, which is how the single-click deployment is triggered.

Where expo/examples stops being the right tool

The repository has no releases. There is no changelog at the top level, no semantic versioning of the examples as a set, and no compatibility statement tying an example to a specific Expo SDK release. If your team needs a pinned, auditable dependency with a version number you can put in a lockfile, this repository does not provide one. You take a snapshot of files and own them from that moment.

An example is also a demonstration, not a production application. The README does not claim otherwise, and it does not document error handling, offline behaviour, or upgrade paths for the generated projects. Several examples integrate third-party services such as Clerk, Auth0, Firebase, Sentry, Convex, and Supabase, which means the example will contain configuration for those services. The README does not explain how credentials for those services are supplied, so that is something to check in the individual example before you build on it.

Finally, the repository is contribution-oriented. The README links to a contributing.md and to a first-timers-only badge, and it invites pull requests. That is a healthy signal for a documentation repository, but it also means examples are added because someone wanted to demonstrate an integration, not because a support commitment exists for it.

How it differs from starting with a bare template or a component library

The alternative most developers reach for is a bare template: create-expo with no --example flag, which gives you an empty app and leaves the integration work to you. The difference is the starting point, not the tooling. A bare template has no opinion about which auth provider or database client you use. An example from this repository has already made those choices, so you inherit both the wiring and the assumptions behind it.

A second alternative is a component or utility library that you add to an existing project. That approach keeps your project structure and adds capability. expo/examples does the opposite: it hands you a whole project structure and expects you to adapt it. If your existing app already has navigation, state management, and a build pipeline you are happy with, pulling in an example means either transplanting specific files by hand or accepting a second structure you did not design.

The repository also differs from framework documentation, which explains an API in isolation. An example shows the API in a running app alongside the other pieces it needs. That is more useful when the difficulty is integration and less useful when the difficulty is understanding a single function.

Licence, maintenance, and the cost of tracking upstream

The repository is MIT licensed, and the LICENSE file sits at the top level. MIT is permissive: you can copy an example into your own project, modify it, and ship it, provided you keep the copyright and permission notice. Because the examples are meant to be copied rather than depended on, the practical licence question is whether the notice travels with the copied files. The repository does not include a per-example licence header convention that can be confirmed from the repository files, so if your organisation requires attribution in source files, verify how the LICENSE is expected to propagate. This is not legal advice.

The last push to the repository was on 2026-09-03, which is recent enough that the repository is not abandoned. There are no releases, so there is nothing to upgrade in the conventional sense. Your upgrade path is to re-run the scaffolding command for a newer example or to diff an example directory against your adapted copy. The presence of upgrade-dependencies.sh at the root indicates the maintainers do update dependencies across the collection, but the README does not document how to run it or what it changes, so treat it as an internal maintenance script rather than a supported command.

The real cost is divergence. Once you adapt an example, you own it. There is no merge path back to upstream, and no migration guide for when the Expo SDK moves forward.

Editorial conclusion

Use expo/examples when you want a working starting point for a specific Expo integration, such as with-clerk or with-socket-io, and you are willing to read the example's own files because the top-level README does not document each one. Do not use it as a dependency, a versioned release, or a compatibility matrix. Before adopting an example, check its package.json for the Expo SDK version it targets, and confirm that the integration you need exists as a directory in the repository.

Frequently asked questions

Official sources

1. expo/examples on GitHub
2. Issues
3. License: MIT
4. README