Expo SDK 58 was released on October 15, 2026, with React Native 0.88 and support for iOS 27. For an existing app, start with a controlled SDK 57-to-58 migration: identify who owns the native projects, align dependencies, create a new development build and prove that updates reach compatible binaries.
The release announcement says the SDK 58 Expo Go apps will arrive in the stores within a few weeks. That availability is separate from upgrading a production project. This guide was checked on October 16 and focuses on the decisions a US mobile product team can review before shipping. The examples are proposed acceptance work, not a claim that MUBBITS has already migrated a client to SDK 58.
Key takeaways
- Upgrade one SDK version at a time when starting from an older app.
- Establish whether native directories are generated or contain manually maintained product code before regenerating anything.
- Treat the native binary, JavaScript update and tested customer journeys as one release plan.
Choose the SDK 58 changes your app needs
The stable announcement introduces a broad platform update, but your first migration does not need to enable every feature. Pick the business reason for upgrading and list optional experiments separately. For example, a customer app may need current platform support while a new widget can wait for a later release.
Pay special attention to custom AppDelegate.swift behavior: the release adopts the iOS scene-based lifecycle and points maintainers to a migration guide. CocoaPods remains the default supported path while Swift Package Manager work is a preview. Avoid combining the SDK migration with a build-system experiment unless that experiment has its own owner and recovery plan.
Expo: SDK 58 stable release, platform changes and migration notes
Find the owner of every native change
Before changing packages, inventory native modules, config plugins, notification configuration, signing, deep links and any platform-specific edits. Mark how each change is recreated. A comment saying the ios folder was generated once is insufficient if developers later added a payment integration directly inside it.
Use the matrix below to choose the next action. Commit or otherwise preserve a reviewable baseline before regeneration. If you cannot explain where a native setting comes from, resolve that uncertainty before treating its directory as disposable.
| Project state | Migration approach | Evidence to retain |
|---|---|---|
| Generated native projects | Confirm all required changes are represented by app configuration and plugins before regeneration | Config, plugins and a reproducible build |
| Manually maintained ios or android | Apply the relevant native upgrade changes and review custom integrations | Native diff and platform build results |
| Mixed or unknown ownership | Compare actual native edits with generation inputs before choosing either path | An owner and recreation method for each change |
| Older than SDK 57 | Plan incremental upgrades with a working checkpoint after each SDK | Intermediate dependency and smoke-test records |
Align packages, then build a real development client
Expo's upgrade guide recommends incremental SDK changes. For a project already on SDK 57, its documented manual sequence installs Expo 58, aligns supported packages and runs Expo Doctor. Review the resulting changes and warnings before accepting them; automated dependency repair does not understand every custom native integration.
After the native project work is complete, create a new development build. Confirm that the app launches on both platforms with the configuration used by the product. Keep the first migration focused on preserving behavior, then evaluate new SDK features in separate changes.
Documented dependency checks for an SDK 57 project
Run in a preserved development branch, then inspect all package and native changes. These commands are documentation-reviewed, not executed here against a supplied mobile app.
npm install expo@^58.0.0
npx expo install --fix
npx expo-doctorExpo: incremental SDK upgrade procedure
Understand generated and manually maintained React Native projects
Ready to move your existing app to SDK 58?
Share the current SDK, native integrations and release requirements. We can help identify the migration work and prepare a tested build.
Keep over-the-air updates compatible with the binary
A JavaScript update must match the native runtime it expects. Expo's runtime-version documentation explains that a runtime version describes compatibility between a build's native code and an update. When native dependencies change, verify the project's runtime policy and create the corresponding build rather than assuming an old installed app can load the new update.
Write down the build, runtime version, update channel and intended audience together. Test a newly installed candidate and an existing supported installation. The old installation should continue receiving compatible updates while the new release is staged. If your policy derives compatibility automatically, inspect its resulting values; do not rely on the policy's name as proof.
Document the recovery path for both surfaces. Replacing an update and replacing a store binary have different operational steps. A release owner should know which lever addresses a JavaScript regression and which problem needs another native build.
Test a complete subscription-app journey
Use a fictional coaching app to make acceptance concrete. A member signs in, restores an existing subscription, opens today's workout, downloads instructions and returns through a notification. The same account should retain its access after an app restart and an eligible update. Record expected behavior before running the test.
Exercise interrupted network access, background and foreground transitions, deep links, permission prompts and the layout sizes your audience uses. Include custom native integrations rather than checking only ordinary screens. If the app adapts to resizing, verify that its primary action remains reachable after the window changes. Test with nonproduction purchase accounts and approved sample content.
Release monitoring should distinguish the candidate build from earlier releases. Agree which startup, error and user-journey signals warrant stopping the rollout, and who can make that decision. Do not invent a universal crash-free target; choose acceptance thresholds using the app's measured baseline and customer impact.
- Cold launch and sign-in succeed on the agreed iOS and Android device set.
- Subscription purchase or restore preserves the correct account entitlement.
- Notifications and deep links land on the intended screen after a fresh launch.
- The update is delivered only to a compatible runtime and the recovery path is documented.
Ship the migration before expanding its scope
A useful handoff contains the native ownership record, dependency changes, build identifiers, compatibility policy, test results and known limitations. That lets the product owner approve the working app and gives the next engineer a reproducible starting point.
If a third-party native module blocks the upgrade, record the exact version and failing behavior, then choose an explicit fix, replacement or delayed rollout. Do not hide the blocker behind a clean JavaScript build. Once the migration is accepted, add optional SDK 58 features with their own tests and customer purpose.
Store submission remains a separate release step: confirm current account, asset and review requirements when preparing it. MUBBITS can help scope native fixes and release support around the app you already have.
Prepare the iOS submission and device review
Frequently asked questions
Is Expo SDK 58 stable or still in beta?
Expo announced the stable SDK 58 release on October 15, 2026. Some individual features remain preview, alpha or experimental; the SDK release does not make every included option equally mature.
Should I delete my ios and android folders to upgrade?
Only follow the generated-project regeneration path after confirming that required native changes can be recreated from configuration and plugins. Manually maintained native projects need the applicable native upgrade changes instead.
Can an EAS Update replace the SDK 58 native build?
An update does not replace incompatible native code. Verify runtime compatibility and produce a new binary for native changes, then test how existing installations and the new build receive updates.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.