iOS Archive Fails with “Cycle inside ” after upgrading to expo-datadog from 54.0.0 to 54.0.1

[pierpo]

Describe what happened
After upgrading expo-datadog to 54.0.1, iOS archive builds started failing on EAS with an Xcode build-system dependency cycle.

EAS build fails with exit status 65 and the following error:

error: Cycle inside XXXTESTING; building could produce unreliable results.
Cycle details:
→ Target 'XXXTESTING' has copy command from
  .../BuildProductsPath/Release-iphoneos/ExpoBatchRichNotifications.appex
  to
  .../Applications/XXXTESTING.app/PlugIns/ExpoBatchRichNotifications.appex
○ That command depends on command in Target 'XXXTESTING': script phase “Upload dSYMs to Datadog”
○ Target 'XXXTESTING' has a command with output:
  .../Release-iphoneos/XXXTESTING.app.dSYM
...
Raw dependency cycle trace shows:
Copy ExpoBatchRichNotifications.appex
→ Upload dSYMs to Datadog
→ GenerateDSYMFile
→ ProcessInfoPlistFile
→ Copy ExpoBatchRichNotifications.appex

This started immediately after bumping expo-datadog to 54.0.1

Steps to reproduce the issue:

1.	Set-up Datadog on an Expo 54 project
2.	Have an embedded app extension (in our case a Notification Service Extension), e.g. ExpoBatchRichNotifications.appex (from @batch.com/expo-plugin rich notifications).
3.	Run an iOS archive build (EAS): eas build -p ios --local
4.	Observe archive failure with the Xcode “Cycle inside ” error above.

Describe what you expected:

Upgrading expo-datadog to 54.0.1 should not break iOS archive builds. The dSYM upload build phase should not introduce dependency cycles, including for apps embedding .appex extensions.

Additional context

• Version of the Expo SDK: 54.0.19
• Version of expo-datadog: 54.0.1
• Version of @datadog/mobile-react-native: 3.1.1
• app.json

    [
      'expo-datadog',
      {
        errorTracking: {
          androidSourcemaps: !!env.DATADOG_API_KEY,
          androidProguardMappingFiles: !!env.DATADOG_API_KEY,
          iosDsyms: !!env.DATADOG_API_KEY,
          iosSourcemaps: !!env.DATADOG_API_KEY,
          serviceName: appEnv.DD_SERVICE,
        },
      },
    ],

Hypothesis

The “Upload dSYMs to Datadog” script phase appears to have gained explicit inputPaths / outputPaths (and/or changed behavior/ordering), which may cause Xcode’s build system to pull the script into the dependency graph and create a cycle when an .appex is embedded.

➡️ If the script phase is inserted before/around the “Embed App Extensions” copy files phase, Xcode can end up with the loop shown in the trace.

[sbarrio]

Hi @pierpo, thanks for reaching out.

Indeed this was introduced on 54.0.1 as part of a fix trying to solve problems with build phases on iOS.

We'll take a look at this and come back to you.

[leggomuhgreggo]

Also encountering this issue with v54.0.1

[kliakhovskii-brex]

Just bumped into that during Expo 55 upgrade :) Took me time to trace as this was introduced in a minor version for v54 and no fix. I may pin v54 for expo-datadog, but would be good to at least revert the problematic changes @sbarrio (so no need to verify tons of deps during major expo upgrade). The current version is basically broken for iOS.

[kevinschaffter]

Can confirm same issue, pegging to 54 works for now

[LucasBourgeois]

Having the same issue on sdk55, any update ?

[Kerumen]

We hit the same cycle on Expo 55 / expo-datadog@55.0.0 (app embeds a .appex). The OP's hypothesis is correct — the cycle comes from the inputPaths/outputPaths added to the "Upload dSYMs to Datadog" script phase in withIosDsyms. Declaring $(DWARF_DSYM_FOLDER_PATH) as an input wires the script into the build graph next to GenerateDSYMFile → ProcessInfoPlistFile → the .appex embed copy, closing the loop.

Our workaround is to patch expo-datadog to drop those inputPaths/outputPaths so the phase no longer participates in the dependency graph:

--- a/build/plugin/withIosDsyms/withIosDsyms.js
+++ b/build/plugin/withIosDsyms/withIosDsyms.js
@@ -33,12 +33,6 @@ ${exports_1.IOS_DATADOG_CI_EXPORT}
 $DATADOG_CI_EXEC dsyms upload $DWARF_DSYM_FOLDER_PATH
         `,
             shellPath: "/bin/sh",
-            inputPaths: [
-                '"$(DWARF_DSYM_FOLDER_PATH)/$(DWARF_DSYM_FILE_NAME)"',
-                '"$(DWARF_DSYM_FOLDER_PATH)/$(DWARF_DSYM_FILE_NAME)/Contents/Resources/DWARF/$(PRODUCT_NAME)"',
-                '"$(DWARF_DSYM_FOLDER_PATH)/$(DWARF_DSYM_FILE_NAME)/Contents/Info.plist"',
-            ],
-            outputPaths: ['"$(DERIVED_FILE_DIR)/datadog-dsym-upload-marker"'],
         });
         return config;
     });

Applied via pnpm patchedDependencies (patch-package format works too). This clears the archive cycle on 55.0.0. Tradeoff: without the output marker the phase loses Xcode's incremental skip and runs on every archive, but the dSYM upload itself is unaffected.

Would be great to revert this change or make the inputPaths/outputPaths opt-out, since the current versions are broken for any iOS app embedding an extension.

[sbarrio]

Hi, sorry for the late reply, we completely missed this.

I've just prepared a PR to fix this problem. It will be released soon with the next release of expo-datadog.

Thanks for your support 🙇