My app builds but crashes on launch

Your app runs fine on your phone from Xcode or Android Studio. The StoreReady build finishes, the app reaches TestFlight or Google Play, and then it closes the moment you open it. The most common reason is that the build had different native code from the app you run.

Why it happens

An Expo app has two halves. Your JavaScript is in Git. The native projects, the ios and android folders, are often not: Expo's .gitignore lists /ios and /android, because expo prebuild can make them again from app.json at any time.

That works until someone adds code to those folders by hand. Push for calls (PushKit), the call screen (CallKit), a custom AppDelegate.swift, your own Swift or Kotlin files. That code lives only on your computer. A build from GitHub never sees it, so StoreReady makes fresh native folders with expo prebuild, and they don't have your code. The app builds, opens, calls code that isn't there and crashes.

It's likely this when:

• your .gitignore has /ios or /android in it
• you, or a developer, once changed something in Xcode or Android Studio
• your app uses a library whose setup says to edit AppDelegate, MainApplication or AndroidManifest.xml, like react-native-voip-push-notification or react-native-callkeep

StoreReady warns about those libraries when it checks your project, but it can't see code that isn't in what you connected.

Three ways to fix it

1. Commit your ios and android folders. Remove /ios and /android from .gitignore, then commit and push the folders. StoreReady then builds your app from them as they are, and never runs expo prebuild on it. From then on make native changes in those folders, and don't run expo prebuild --clean, which would replace them.

2. Publish from your computer. Run npx @storeready/cli publish in your project folder. It notices that your native folders aren't in Git and asks: "Your ios folder isn't in Git. It may hold your own native code. Build from it?" Answer yes. Your folders go with the build, without Pods, build output and signing keys. From Claude Code, Codex or Cursor, the AI tool asks you the same question. The answer is remembered for the folder. In a script, add --native-folders. See The StoreReady CLI.

3. Add a config plugin. A config plugin writes your native changes every time expo prebuild runs, so the code is never lost and your app can stay managed. Some libraries have one you add to plugins in app.json. For the rest, your AI tool can write a small plugin from the changes you made in Xcode and Android Studio.

After any of the three, build a new version.

Read the crash report

Apple keeps a report of every crash of a TestFlight build.

1. Open the app from TestFlight and let it crash. When TestFlight offers to send feedback about the crash, send it.
2. In App Store Connect, open Apps, your app, then TestFlight. Under Feedback, choose Crashes. Each crash shows the build, the device and the iOS version. Download the crash log, or open it in Xcode.
3. In Xcode you can also open Window → Organizer → Crashes, signed in with the same Apple account. Crashes from TestFlight builds appear there after a while.

In the report, look for these lines first:

• Exception Type and Exception Reason (or Last Exception Backtrace) say what went wrong.
• unrecognized selector sent to instance means the app called a method that isn't there. When the method is something like pushRegistry:didUpdatePushCredentials:forType: and the lines below it mention PushKit or CallKit, the native code from your own AppDelegate is missing. That is the case this page is about.
• The Thread 0 lines (or the thread marked Crashed) show where. Lines with your app's name are your code, lines with UIKit, PushKit or Foundation are Apple's.

On Android, crashes are in Play Console under Android vitals → Crashes and ANRs, with the same kind of trace.

Not sure what the report means? Send it to help@storeready.app with the name of your app and we will read it with you.