Choose a compatible target
Review the starting SDK, React Native dependencies, config plugins, and build setup. Agree on the target and sequence before implementation.
EXPO SDK UPGRADES
Get Your Expo SDK Upgrade Back on Track
We handle the dependency, config plugin, and native build changes for your agreed SDK target. Your team gets documented changes and builds to validate before release.
Senior engineers. Controlled repository access. Scope agreed before work starts.
What the engagement covers
The written proposal identifies the target, the work included, and how your team will accept the result.
Resolve the upgrade work
Align supported dependencies and fix the agreed configuration and native build issues. Library replacements and product changes are discussed before they expand the scope.
Prepare the handoff
Deliver the upgrade branch, changed-dependency summary, build instructions, verification notes, and open items for your QA owner.
Is this the right scope?
A production Expo app with a stalled SDK upgrade, development-build failures, or config plugins that need attention. The initial review distinguishes generated native projects from native directories your team maintains directly.
Scope boundaries
A workflow conversion, backend changes, new features, OTA update infrastructure, app-store submission, and ongoing maintenance are separate scope decisions. An SDK upgrade does not automatically include them.
For a broader build rescue, see React Native upgrade support. If you are deciding who should do the work, compare delivery options.
From assessment to handoff
Start with the codebase and agree on the result before committing to implementation.
1. Bring your starting point
Share the current SDK, build errors, lockfile, native customizations, and deadline. Use the existing qualification flow to start the conversation.
2. Agree on the work
After reviewing the project, define the target, scope, client responsibilities, timeline, and one fixed quote.
3. Review the changed app
We work in a branch and document the checks performed. Your team reviews the result and approves its release.
Make acceptance concrete
Agree on the iOS and Android builds to verify, the test devices or environments, and app-specific flows such as sign-in, navigation, notifications, and payments. Your QA owner supplies test accounts and validates business behavior.
Your team owns the release decision
Provide a technical contact, QA time, test accounts, and a plan for business-critical workflows. We document the agreed checks and remaining limitations; your team reviews the changes and approves deployment.
Before we start
Can you work with config plugins and custom native code?
Yes, when included in the agreed scope. We first establish whether your project regenerates native directories or maintains them directly, then review the plugins and customizations that need to survive the upgrade.
Do we have to move to a different Expo workflow?
Not automatically. We assess the existing workflow and target SDK. Any change to how native projects are maintained is a separate decision with your team.
Is this a security audit?
No. An SDK upgrade addresses the agreed version and compatibility work. A manual security audit is a separate scope, and a dependency scan alone cannot establish that your application is secure.
What do we need to provide?
Controlled repository access under NDA, current build instructions, a technical contact, and a QA owner with test accounts and a testing plan. Build-service and signing access are agreed during scoping.
Review the approach
Use these resources to prepare your questions for the scoping call.
Our upgrade planning follows the official Expo SDK upgrade guidance. Projects using generated native directories also need the Continuous Native Generation workflow considered when preserving customizations.
Tell us where the work is stuck.
Bring your current setup, the change you need, and your deadline. We will discuss the scope and the next step with your team.
Discuss Your Project →