EAS build failure

[tartavull]

This is amazing! Thank you!

I'm getting this error when building a development version with eas

21 | import ExpoSystemUI
  22 | import EXUpdates
> 23 | import ReactNativeWidgetExtension
     |        ^ no such module 'ReactNativeWidgetExtension'
  24 | #if EXPO_CONFIGURATION_DEBUG
  25 | import EXDevLauncher
  26 | import EXDevMenu

Any tips?

[km00776]

Have you found a pix for this?

[yurayavorski]

any updates? I'm getting same issue

[kourtc]

+1

[geoah]

Same issue here, builds fine locally with expo build/run but eas doesn't seem to like this way.

[nathan-ahn]

Could you create a minimum reproducible example? There's likely an issue in the widgetsFolder configuration.

"expo": {
    "name": "my-app",
    "plugins": [
        [
            "react-native-widget-extension",
            { "frequentUpdates": true, "widgetsFolder": "SampleWidgetExtension" },
        ],
    ]
}

[CptFabulouso]

I was getting this error after adding react-native-share lib and not adding it's plugin config to app.json. After adding it there, the build started working again. Yes, it's weird, I don't understand what's happening, but the results are consistent.

Anyway, now I've update react-native-appsflyer lib and this error started appearing again.
So I find out build starts failing with the next version of appsflyer, this is the diff between those two versions and... there does not seem to be anything relevant.

One thing I've noticed is that xCode log from the working build has this line
➜ Implicit dependency on target 'ReactNativeWidgetExtension' in project 'Pods' via options '-framework ReactNativeWidgetExtension' in build setting 'OTHER_LDFLAGS'
while the failing log is missing this.

I've managed to run the build again with newest react-native-appsflyer by moving stuff in plugins around, moving these two libs as top most items (so they run last), while react-native-widget-extension is above react-native-appsflyer.

Anyway, after adding any other lib (and its plugin to bottom of plugins list), the build breaks again. I have no idea what's the issue, I'm not writing solution, but maybe someone can make some sense of this...

[CptFabulouso]

Looking for common traits, any chance any of you are using patch-package, maybe also with monorepo project? After removing patch-package, my builds started to work again consistently.

[nathan-ahn]

We don't use patch-package but we use Bun's built-in patch feature (which I believe works quite similarly) and haven't had these build issues (both local and EAS). We have several patches for native functionality as well.

We've definitely had to do some weird stuff to get our monorepo to work though. We have autolinking searching in multiple nested levels of node_modules. I've found that autolinking can often start from either the Expo project or from within the ios directory (requiring an extra level of node_modules).

  "expo": {
    "autolinking": {
      "searchPaths": [
        "../packages",
        "../node_modules",
        "../../node_modules"
      ],
      "nativeModulesDir": "../packages"
    }
  },

[CptFabulouso]

Alright, I think I've found what's the issue. On EAS the Prebuild stage (not script itself) does 2 things, 1st it runs the expo prebuild command and 2nd runs yarn install for the second time (the first time being before the Prebuild stage) - this is standard EAS CI.
In the successful builds, the second yarn install does recognize nothing in deps changed and any installations are skipped.
In the failing builds, the second yarn install runs the whole installation process again, which removes Attributes and Module files from node_modules/react-native-widget-extension/ios that were copied there during the prebuild.

That's why this only happens on EAS, because normally you don't reinstall dependencies again after running prebuild. You can reproduce this locally by:

• run expo prebuild script
• run yarn install --force
• build project in xCode

Why with the patch-package the second yarn install is prone to re-install deps is beyond me, it does not happen every time. But anyway, the issue will arise anytime deps are re-installed after prebuild, whatever be the reason.

Edit: Probably due to

yarn install v1.22.22
[1/5] Validating package.json...
[2/5] Resolving packages...
warning Lockfile has incorrect entry for "@typescript-eslint/parser@^5.42.0". Ignoring it.
warning Lockfile has incorrect entry for "@typescript-eslint/parser@^5.30.5". Ignoring it.

That "Ignoring it" is probably "Ignoring the lockfile"

Solution

I'm not sure. Attributes and Module files should be probably copied into ios folder rather than in node_modules, but I am not sure if that's possible with how this lib is structured.

Edit: Solution in my project is to fix the lock file, but I'd still consider changes to this lib to avoid modifying or adding files to node_modules

[nathan-ahn]

Interesting. Not a permanent fix, but would adding another round of expo prebuild as a postinstall script fix this issue? In theory, another prebuild would copy the files into node_modules/react-native-widget-extension/ios again. (Perhaps this can be run as a conditional postinstall checking for CI and Mac)

[CptFabulouso]

I was considering this approach, but I currently don't know how to check for CI or Mac within the script and I don't want to run the prebuild every time I install or update some dependency. Fixing the lock file was pretty straight forward and builds now run successfully.

[losstng]

New root cause found (March 2026): EAS Xcode 26.2 default image

Same symptom (no such module 'ReactNativeWidgetExtension') but a different root cause than the yarn lockfile issue.

EAS recently flipped the sdk-55/latest build image to macos-sequoia-15.6-xcode-26.2. The npm package ships ios/Module.swift with import ActivityKit + Live Activity functions. Under Xcode 26.2 / Swift 6, ActivityKit fails to compile inside the main-app pod context (strict concurrency enforcement). The pod produces no .swiftmodule → ExpoModulesProvider.swift can't import it.

Workaround: Pin EAS build image to macos-sequoia-15.6-xcode-16.4 in eas.json:

{ "build": { "production": { "ios": { "image": "macos-sequoia-15.6-xcode-16.4" } } } }

Proper fix: Module.swift should not import ActivityKit at all. The widget data bridge (setWidgetData, setWidgetImage, reloadWidgets) only needs WidgetKit + ExpoModulesCore. ActivityKit belongs in the widget extension target only, not in the main-app pod.

Apple mandates Xcode 26 SDK for all App Store uploads from April 28, 2026 — this will affect everyone on this library.

[nathan-ahn]

@losstng I don't believe that the issue is necessarily linked to newer xcode versions. There may be a separate issue with your environment or module. For reference, we're running local builds on XCode 26.3.0 with no issues and no changes to the implementation required.