App Crashes After App Store Release But Not on TestFlight — 4 Common Causes

You tested your Rork app thoroughly on TestFlight. Everything worked. Then you hit publish — and crash reports start rolling in.

This is one of the most demoralizing moments in indie iOS development, but it's also one of the most common. The good news: the causes almost always fall into a handful of predictable patterns. Here's what to check first.

Why TestFlight and App Store Builds Behave Differently

The key insight: TestFlight distributes builds using development or internal distribution profiles, while the App Store runs production-signed builds. This affects which environment variables are active, which ATS rules apply, and how some APIs behave.

On top of that, TestFlight runs on your devices and your testers' devices — typically recent, well-maintained hardware. The App Store reaches everyone, including iPhone 8 users running iOS 15 with 2GB of RAM. That gap matters more than you might expect.

Cause #1: Environment Variables Missing in Production Build

If your Rork app uses external APIs, you're probably relying on environment variables like EXPO_PUBLIC_API_KEY. These can be set per build profile in eas.json. A common mistake: variables are configured for the preview profile used in TestFlight, but not for the production profile used for App Store submission.

What this looks like in eas.json

{
  "build": {
    "preview": {
      "distribution": "internal",
      "env": {
        "EXPO_PUBLIC_API_KEY": "test-key-here"
      }
    },
    "production": {
      "distribution": "store"
      // No env block here — variables will be undefined in production!
    }
  }
}

How to fix it

1. Open your project on expo.dev → Secrets
2. Add your API keys as Production secrets
3. Reference them in your eas.json production profile:

"production": {
  "distribution": "store",
  "env": {
    "EXPO_PUBLIC_API_KEY": "$EXPO_PUBLIC_API_KEY"
  }
}

4. Rebuild with eas build --platform ios --profile production and verify

For a deeper look at environment configuration issues, check out our environment variables error fix guide.

Cause #2: App Transport Security (ATS) Enforced in Production

iOS enforces App Transport Security (ATS), which blocks plaintext HTTP connections by default. In debug/TestFlight builds, ATS exceptions may be more permissive. In production builds, strict ATS rules apply — and if any of your API calls use HTTP or have certificate issues, they'll fail silently or cause crashes.

Signs you're hitting this

• Network-related crashes referencing NSURLErrorDomain or SSL errors
• All external API calls fail after App Store installation
• Images or assets with http:// URLs fail to load

Fix: configure ATS exceptions properly in app.json

{
  "ios": {
    "infoPlist": {
      "NSAppTransportSecurity": {
        "NSAllowsArbitraryLoads": false,
        "NSExceptionDomains": {
          "your-api.example.com": {
            "NSExceptionAllowsInsecureHTTPLoads": false,
            "NSExceptionMinimumTLSVersion": "TLSv1.2"
          }
        }
      }
    }
  }
}

Avoid setting NSAllowsArbitraryLoads: true — Apple's reviewers may flag this. Instead, explicitly list each domain that needs an exception. Also double-check that your backend actually serves HTTPS with a valid certificate.

Cause #3: Privacy Manifest Declarations Are Incomplete

Since 2024, Apple requires all apps to include a Privacy Manifest (PrivacyInfo.xcprivacy) declaring which "Required Reason APIs" the app uses. Rork-generated apps may internally use APIs like UserDefaults, disk space APIs, or file timestamp APIs through dependencies — and if these aren't declared, you may see unexpected behavior after App Store review.

Common Required Reason APIs in Rork apps

• UserDefaults — used internally by AsyncStorage
• Disk space APIs — via NSFileManager
• File timestamp APIs — various file operations

Declaring them in app.json

{
  "ios": {
    "privacyManifests": {
      "NSPrivacyAccessedAPITypes": [
        {
          "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryUserDefaults",
          "NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
        },
        {
          "NSPrivacyAccessedAPIType": "NSPrivacyAccessedAPICategoryDiskSpace",
          "NSPrivacyAccessedAPITypeReasons": ["E174.1"]
        }
      ]
    }
  }
}

Expo SDK 50+ auto-generates many of these, but custom native modules may need manual declarations. See the full guide on privacy manifest and API declaration fixes for details.

Cause #4: Out-of-Memory Crashes on Older Devices

Testing only on an iPhone 15 Pro Max gives you a false sense of security. The App Store serves users on iPhone 8 (2017, 2GB RAM) and similar devices. AI-heavy Rork apps — especially those processing images, running local models, or managing large lists — can easily exhaust available memory on constrained hardware.

Optimize FlatList to reduce memory pressure

<FlatList
  data={items}
  renderItem={renderItem}
  maxToRenderPerBatch={10}     // Limit items rendered per batch
  windowSize={5}               // Keep fewer off-screen items in memory (default: 21)
  removeClippedSubviews={true} // Unmount views outside the visible window
  initialNumToRender={8}       // Fewer items on first render
/>

Use expo-image instead of the built-in Image component

import { Image } from 'expo-image';
 
<Image
  source={{ uri: imageUrl }}
  style={{ width: 300, height: 300 }}
  contentFit="cover"
  transition={200}
  // expo-image handles caching and memory management automatically
/>

A simple Rork prompt tweak that helps: explicitly ask for "memory-efficient implementation using expo-image and FlatList optimization" when building image-heavy screens. For a broader look at performance tuning, see our app performance optimization guide.

Add Crash Monitoring So You Can Diagnose Future Issues

If none of the above patterns explain your crash, you need visibility into what's actually happening on users' devices. Sentry is the easiest option to add to a Rork app:

npx expo install @sentry/react-native

// Add this at the top of your app/_layout.tsx or App.tsx
import * as Sentry from "@sentry/react-native";
 
Sentry.init({
  dsn: "https://your-dsn@sentry.io/project-id",
  release: "com.yourcompany.yourapp@1.0.0",
  dist: "1",
  enabled: !__DEV__, // Only active in production
  tracesSampleRate: 0.1,
});
 
export default Sentry.wrap(RootLayout);

With Sentry running, your next release will automatically report crashes with full stack traces, device info, and OS versions. You'll know exactly where the crash happens and on which devices. See the full setup guide: Sentry crash monitoring setup for Rork apps.

A Hidden Trap: Testing the Wrong Build

Here's something that catches many developers off guard. Even within TestFlight, you can distribute two very different types of builds:

• Internal TestFlight build — uses an internal distribution profile (similar to development)
• External TestFlight build (submitted through review) — uses the same production pipeline as the App Store

If you've only tested internal TestFlight builds, you may not have actually tested the production build at all. The most reliable pre-launch check is to submit your app to App Store Connect as a production build, then distribute it through external TestFlight (which goes through a brief review) before flipping the App Store toggle.

This extra step catches a surprising number of issues — especially environment variable mismatches and ATS problems — before real users are affected.

How to test the actual production build before release

# Build the production version
eas build --platform ios --profile production
 
# Submit to App Store Connect (for TestFlight distribution)
eas submit --platform ios

Once the build is in App Store Connect, create an external testing group and run through your key flows on at least one older device. If it crashes here, it'll crash on the App Store too — and you'll catch it before launch.

Understanding the Crash: What to Look For in Xcode

When Sentry isn't yet set up and you need to diagnose a crash quickly, Xcode's Crashes organizer is your best free option. Connect any device that reproduces the crash, then:

1. Open Xcode → Window → Devices and Simulators
2. Select the device, click View Device Logs
3. Filter by your app bundle ID
4. Look for EXC_BAD_ACCESS (memory), SIGABRT (assertion failure), or NSException

For crashes you can't reproduce locally, App Store Connect's Crashes & Energy dashboard (under your app's TestFlight or App Store tab) aggregates crash reports from real devices automatically. No extra setup needed — it uses the dSYM symbols from your submitted build.

The dSYM (debug symbol) file is what translates raw memory addresses into readable function names. EAS automatically uploads dSYMs to App Store Connect during submission, but double-check this is working if your crash reports show only raw addresses:

# Verify that your build includes dSYM uploads
eas build:list --platform ios | head -5
# Check that the build status shows "Uploaded to App Store Connect"

Pre-Release Checklist

Before your next App Store submission, run through these:

• All environment variables defined in eas.json under the production profile
• All API endpoints use HTTPS with valid certificates
• NSAllowsArbitraryLoads is false in your production build
• Required Reason APIs declared in Privacy Manifest
• App tested on an older device (iPhone SE 2nd gen or equivalent)
• FlatList and image components optimized for low-memory devices
• Sentry or equivalent crash monitoring set up for production

App Store crashes after a clean TestFlight run are frustrating, but they're rarely mysterious. The four patterns above cover the vast majority of cases. Work through them systematically, and you'll track down the issue faster than you think.