Expo and native changes
Know when hot reload is enough and when the app binary must be rebuilt.
This starter is pinned to Expo SDK 57. Native work should follow the exact SDK 57 documentation and the installed package versions, not a random tutorial for another Expo release.
Classify the change first
| Change | Typical proof |
|---|---|
| Copy, layout, JavaScript logic | Hot reload plus focused tests |
| Expo config, permission, icon, scheme, native package | Fresh development build |
| EAS channel, signing, store capability | Fresh signed build and dashboard verification |
| Server/provider setup | Provider checks plus real end-to-end behavior |
Prompt
Make this Expo/native change: [describe it]. Read AGENTS.md and
agent-skills/expo-best-practices.md first. Use the Expo SDK 57 docs and the
installed package version. Tell me whether it is JavaScript-only, native/config,
or service configuration, and rebuild when hot reload cannot prove it.Guardrails
- Install Expo-managed packages with
pnpm exec expo installwhen applicable. - Keep platform-specific imports behind
.ios,.android,.native, or.webmodules when one import would break another bundle. - Ask for permissions only after a clear user action and explanation.
- Handle granted, denied, limited, canceled, unavailable, and settings-return states.
- Never put service-role, AI, webhook, signing, or store secrets in the app bundle.
- Do not use OTA updates for binary-incompatible native changes.
Minimum verification
Run typecheck, lint, tests, Expo Doctor, web export/runtime smoke, and the relevant physical-device journey. After native config changes, inspect the generated public Expo config and test a clean install and upgrade.