Rork Max SwiftUI App Crash Logs Are Unreadable: The dSYM Upload Pitfall

While preparing an iOS update for Relaxing Healing — one of my apps with over 50 million cumulative downloads across my portfolio — I opened the Firebase Crashlytics dashboard and found something frustrating. Every crash report was showing as "Unsymbolicated," displaying raw memory addresses like 0x0000000100234a40 instead of readable function names.

Crashes were happening. The reports were arriving. But nothing was readable.

This is one of the more disorienting problems in iOS development: the data exists, but you can't use it. If you've been building with Rork Max and just started shipping SwiftUI apps, this configuration gap is easy to miss.

What "Unsymbolicated" Actually Means

When your app crashes on a real device, iOS records a stack trace — a sequence of memory addresses representing the code execution path at the time of the crash. These addresses are meaningless without a translation table.

That translation is called symbolication, and the file that makes it possible is the dSYM file (debug symbols file). dSYM files map memory addresses back to human-readable function names, file names, and line numbers. Firebase Crashlytics uses these files to turn raw crash reports into something you can actually act on.

When dSYM files aren't uploaded to Crashlytics, you get reports that are technically complete but practically useless.

Root Cause: Two Missing Configuration Steps

Rork Max-generated Xcode projects often have default build settings that skip dSYM generation and upload. There are two separate issues to fix.

Issue 1: Wrong Debug Information Format

When the Release build target has Debug Information Format set to DWARF (instead of DWARF with dSYM File), Xcode never generates the dSYM file in the first place. No file means nothing to upload.

Issue 2: No dSYM Upload Script in Build Phases

Even after fixing the format, Crashlytics only receives the dSYM if an upload script runs as part of your build. Firebase provides this script, but it needs to be manually added to your Xcode build phases.

Step 1: Fix the Debug Information Format

Open your project in Xcode and navigate to the target's Build Settings:

1. Select your target in the Project Navigator
2. Open the Build Settings tab
3. Search for "Debug Information Format"
4. Find the Release row — if it says DWARF, change it to DWARF with dSYM File

// Before (dSYM file is never generated)
Debug Information Format (Release): DWARF

// After (dSYM generated on every Release build)
Debug Information Format (Release): DWARF with dSYM File

The Debug configuration can stay as DWARF — this change only needs to apply to Release.

Step 2: Add the dSYM Upload Script to Build Phases

Next, wire up the automatic upload:

1. In Xcode, open your target's Build Phases tab
2. Click the + button in the top left and select New Run Script Phase
3. Paste in the appropriate script based on your dependency manager

For CocoaPods:

# Automatically upload dSYM to Firebase Crashlytics
"${PODS_ROOT}/FirebaseCrashlytics/run"

For Swift Package Manager (SPM):

# SPM path (use this if you migrated from CocoaPods)
"${BUILD_DIR%Build/*}SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run"

Add these to the Input Files section for more reliable uploads:

${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Resources/DWARF/${TARGET_NAME}
$(SRCROOT)/$(BUILT_PRODUCTS_DIR)/$(INFOPLIST_PATH)

Place this Run Script phase after the "Link Binary with Libraries" phase — order matters here.

Notes Specific to Rork Max Projects

Rork Max can generate projects using either CocoaPods or SPM for Firebase. As of 2026, CocoaPods Firebase distribution is being deprecated, so SPM is the better long-term choice. When I updated Relaxing Healing in May 2026, I completed the CocoaPods → SPM migration first, then set up the SPM-style upload script.

If your project uses CI/CD — whether Xcode Cloud, EAS Build, or GitHub Actions — make sure your production build configuration is set to Release. The dSYM upload script only runs when the build type matches.

# Verify EAS Build configuration
# eas.json: production profile should use Release
{
  "build": {
    "production": {
      "ios": {
        "buildConfiguration": "Release"  // Must be Release, not Debug
      }
    }
  }
}

Verifying the Fix

After releasing a new build with these settings in place, check your Crashlytics dashboard:

1. Firebase Console → Crashlytics → select your app
2. Open any crash report from after the new build
3. If the stack trace shows function names like ContentView.body.getter instead of hex addresses, symbolication is working

Symbolication applies going forward only — Crashlytics cannot retroactively symbolicate crash reports from older builds. The fix takes effect from the next release.

This setup takes about ten minutes once, and then it's automatic for every subsequent build. Before shipping any Rork Max app to the App Store, it's worth making this check part of your pre-launch checklist. The faster you can read crash reports, the faster you can fix them — and for apps with active users, that responsiveness directly affects retention.