Expo framework file-based routing
Expo is a React Native framework that provides file-based routing as a core feature, alongside a standard library of native modules.
Expo & React Native · all subjects
core concepts
25 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Expo examples demonstrate specific features
Expo examples are small apps that each demonstrate a specific feature or integration, such as Expo Router, Expo Widgets, or a camera screen. The full list is available in the Expo examples repository.
Model Context Protocol (MCP) enables AI integration with Expo
Model Context Protocol (MCP) is a standard protocol that allows AI models to integrate with external data sources and provide enhanced context for more precise responses. Expo MCP Server is a remote MCP server hosted by Expo that integrates with popular AI-assisted tools such as Claude, Claude Code, Cursor, VS Code, and others, enabling them to interact directly with Expo projects. Expo MCP is also available through Claude Connectors on Claude web, desktop, and mobile apps with no local installation required.
Expo MCP Server capabilities overview
Expo MCP Server teaches AI-assisted tools about the Expo SDK and lets them interact with mobile simulators and React Native DevTools. Core capabilities include: learning about developing with Expo by fetching official Expo documentation on demand; managing dependencies with guidance toward recommended packages and using npx expo install for compatible versions; managing builds and workflows including triggering and monitoring EAS builds, running workflows, and pulling crash data from TestFlight; and automating visual verification and testing where multimodal AI can screenshot and interact with running apps in simulators.
Server capabilities versus local capabilities in Expo MCP
Expo MCP Server provides two types of capabilities. Server capabilities are available with just the remote MCP server connection without needing a local development server. Local capabilities require a local Expo development server running and provide advanced features: automation tools for taking screenshots, tapping views, finding elements by testID; development tools for opening React Native DevTools; and project analysis for generating expo-router sitemap.
Expo MCP limitations
The current Expo MCP implementation has the following limitations: only supports a single development server connection at a time; iOS support for local capabilities is limited to simulators only (physical devices not yet supported); iOS support for local capabilities is only available on macOS hosts.
Expo Updates protocol specification version
Expo Updates v1 is a protocol for delivering updates to Expo apps running on multiple platforms. The protocol version is specified as '1' in request and response headers via the expo-protocol-version header.
Update definition in Expo Updates
An update is defined as a manifest together with the assets referenced inside the manifest.
Directive definition in Expo Updates
A directive is a message from the server that instructs clients to perform an action.
Client update loading behavior
An app running a conformant Expo Updates client library must load the most recent update saved in the client library's update database, possibly after filtering by the contents of the update's manifest metadata.
Client library update retrieval process
A conformant client library must make a request for the most recent update and directive with constraints specified in headers. Upon receiving a response containing an update, the client library must make additional requests to download and store any new assets specified in the manifest, edit local state to reflect the new update, and update the local state with the new expo-manifest-filters and expo-server-defined-headers found in the response headers. Upon receiving a response containing a directive, the client library must consume the directive depending on the directive type and edit local state accordingly.
Request headers required by Expo Updates client
A conformant client library must make a GET request with the following headers: (1) expo-protocol-version: 1 to specify version 1 of the Expo Updates specification; (2) expo-platform to specify the platform type (iOS must be 'ios', Android must be 'android', if neither the server should return 400 or 404); (3) expo-runtime-version which must be a runtime version compatible with the client, stipulating the native code setup the client is running; (4) any headers stipulated by previous responses' server defined headers.
Request accept header preferences in Expo Updates
A conformant client library may send one of accept: application/expo+json, accept: application/json, or accept: multipart/mixed based on supported response structures. It should send accept: application/expo+json, application/json, multipart/mixed. A client library may express preference using 'q' parameters as specified in RFC 7231, which default to 1.
Code signing request headers in Expo Updates
A conformant client library configured to perform code signing verification must send an expo-expect-signature header to indicate that it expects the conformant server to include the expo-signature header in the manifest response. The expo-expect-signature header is an Expo SFV dictionary which may contain: sig (should contain boolean true to indicate requirement for signature in sig key), keyid (should contain the keyId of the public key the client will use to verify the signature), alg (should contain the algorithm the client will use to verify the signature).
Server response format options in Expo Updates
A conformant server must return a response structured in at least one of two response structures and may support either or both: (1) content-type application/json or application/expo+json with common response headers and manifest body in response body (does not support directives), or (2) content-type multipart/mixed as specified in multipart response section. A server should respond with HTTP 406 error status when an unsupported response structure is requested or when responding with an incompatible response for the requested protocol version.
Multipart response with no parts in Expo Updates
A multipart response with no parts may respond with HTTP 204 status and no content, and thus no content-type response header. A multipart response with zero-length body should be considered a no-op (no updates or directives available), though headers for the response should be sent nevertheless and processed by the client.
Server response header selection logic
The choice of update and headers are dependent on the values of the request headers. A conformant server must respond with the most recent update, ordered by creation time, satisfying all parameters and constraints imposed by the request headers. The server may use any properties of the request like its headers and source IP address to choose among several updates that all satisfy the request's constraints.
Common response headers in Expo Updates
Common response headers must include: expo-protocol-version (must be 1), expo-sfv-version (must be 0), expo-manifest-filters (Expo SFV dictionary used to filter updates stored by client library by metadata attribute; if a field is mentioned in the filter, the corresponding field in metadata must either be missing or equal for update to be included; client library must store manifest filters until overwritten by newer response), expo-server-defined-headers (Expo SFV dictionary defining headers that client library must store until overwritten and must be included in every subsequent update request), cache-control (must be set to appropriately short period; value of 'private, max-age=0' recommended to ensure newest manifest is returned; longer cache ages could result in stale updates), content-type (must be determined by proactive negotiation as defined in RFC 7231; will always be either application/expo+json or application/json since client is required to send accept header).
expo-signature header in Expo Updates response
The expo-signature header should contain the signature of the manifest to be used during the validation step of code signing if the request for the manifest contained the expo-expect-signature header. This is an Expo SFV dictionary which may contain: sig (must contain the signature of the manifest), keyid (may contain the keyId of the key the server used to sign the response; client should use the certificate that matches this keyid to verify the signature), alg (may contain the algorithm the server used to sign the response; client should use this field only if it matches the algorithm defined for the certificate matching keyid).
Multipart response format in Expo Updates
An update response of multipart/mixed format is defined by the multipart/mixed MIME type as defined by RFC 2046. Headers for this response format are the common response headers, with content-type having a multipart/mixed value. Part order is not strict.
Manifest part in multipart response
The optional manifest part must have part header 'content-disposition: form-data; name="manifest"' (the first parameter does not need to be form-data, but the name parameter must have manifest as value). It must have part header 'content-type: application/json' or 'application/expo+json'. It should have part header expo-signature as defined in other response headers if code signing is being used. The manifest body must be sent in the part body.
Extensions part in multipart response
The optional extensions part must have part header 'content-disposition: form-data; name="extensions"' (the first parameter does not need to be form-data, but the name parameter must have extensions as value). It must have part header 'content-type: application/json'. The extensions-body must be sent in the part body.
Directive part in multipart response
The optional directive part must have part header 'content-disposition: form-data; name="directive"' (the first parameter does not need to be form-data, but the name parameter must have directive as value). It must have part header 'content-type: application/json' or 'application/expo+json'. It should have part header expo-signature as defined in other response headers if code signing is being used. The directive body must be sent in the part body.
Code signing in Expo Updates
Expo Updates supports code signing the manifest and directive bodies. Code signing the manifest also transitively signs the assets since their hashes are present in the manifest and verified by a conformant client. A conformant client may request the manifest or directive be signed using a private key, and then must verify the signature of the manifest or directive using the corresponding code signing certificate before it is used or any corresponding manifest assets are downloaded.
Code signing certificate requirements
The client must verify that the signing certificate is either a self-signed, trusted root certificate or is in a certificate chain signed by a trusted root certificate. In either case, the root certificate must be embedded in the application or device's operating system.