fix(build): fail with the cause when the setup is wrong - #1450
Merged
Conversation
The xcframeworks and jniLibs are not in the npm tarball; a postinstall hook downloads them. When a package manager skips that hook - pnpm 10 blocks dependency build scripts by default, and so do `--ignore-scripts` and `npm ci --ignore-scripts` - nothing complains. `pod install` succeeds too, because CocoaPods never checks that a vendored framework exists, and the build only fails minutes later with error: Build input files cannot be found: '.../XnnpackBackend.xcframework/ios-arm64-simulator/libXnnpackBackend.a' which names neither the cause nor the fix. Check for the artifacts in the podspec and at Gradle configure time instead, and name `pnpm approve-builds` / `npm rebuild` in the message. Also document the setup failures that the library cannot prevent, each with the exact error text: use_frameworks! (both linkages), a second pod vendoring opencv2.xcframework and the config block that resolves it, the missing x86_64 simulator slice, the iOS 17 deployment target warning, the monorepo location of the config block, and the two shipped Android ABIs.
Two more setup failures that surface as something else. The `react-native-executorch` block is read from INIT_CWD, the directory the install ran in. In a workspace that is the root, so a block in `apps/mobile/package.json` was silently ignored: every backend came down and an app declaring `"libs": []` to dodge an OpenCV framework-name conflict got OpenCV anyway. The lookup now also walks up from the installed package, which lands on the app whenever it keeps its own node_modules, and logs which manifest it read. The Android `minSdkVersion` default was 21 while the prebuilt runtime is compiled against API 26 - `.note.android.ident` reads 26 in libexecutorch.so, libxnnpack_executorch_backend.so and libvulkan_executorch_backend.so alike - so a build below that shipped a library the linker is not guaranteed to load, and failed on the device instead. Default to 26 and say so in the docs, which claimed Android 13+ with nothing enforcing it.
msluszniak
changed the title
msluszniak
marked this pull request as ready for review
September 9, 2026 11:08
barhanc
reviewed
Sep 9, 2026
Comment on lines
+82
to
+84
| Another pod in the app vendors its own OpenCV under the same framework name — | ||
| `react-native-fast-opencv` (via `FastOpenCV-iOS`) is the common one. CocoaPods | ||
| cannot install both. |
Member
There was a problem hiding this comment.
I'm wondering if we don't want to patch it some other way so it is possible to use rne with react-native-fast-opencv, as it wouldnt be that weird if someone wanted to use our lower level API for nn inference and opencv for some image transformations we don't support.
Member
Author
There was a problem hiding this comment.
Ok, I solve this by linking to fast open cv in case of both fast open cv and rne are available.
Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com>
CocoaPods installs one framework named opencv2, so an app with react-native-fast-opencv could not also install us. Wanting both is reasonable: our inference API with their image transformations. When that library is present we now depend on the pod it vendors rather than opencv-rne. Headers have to come from the same place as the binary, so the include root becomes a mirror of ours without opencv2: we ship OpenCV 4.13 headers and they vendor 4.9, and the mismatch fails at link time on cvtColor, which gained an AlgorithmHint parameter in 4.10. `opencvPod` overrides the choice either way. Verified on an Expo app with both libraries: pod install and a simulator build both succeed, and forcing opencv-rne reproduces the original conflict.
0.10.0 is `lastVersion`, so the pages users land on still carried the pre-#1448/#1449/#1450 state: React Native 0.81+ / Expo SDK 54+, no worklets floor, no troubleshooting. - getting-started and the compatibility table take the #1449 changes verbatim, plus the minSdkVersion and troubleshooting pointers - native-libraries takes the monorepo and pnpm notes - a Troubleshooting page written against what 0.10.0 actually ships: the `use_frameworks!` header collision needs the Podfile `pre_install` workaround, the OpenCV conflict has no `opencvPod` escape hatch, and `minSdkVersion` defaults to 21 against API 26 `.so` files Also corrects the monorepo note on the current docs, which still said an app-level block is always ignored - the lookup now walks up from the installed package too.
barhanc
approved these changes
Sep 9, 2026
This was referenced Sep 9, 2026
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
#1452) ## Description Two defects in #1450, both reproduced against `main` at `a1ff6c9`. **`if enable_opencv` was never closed.** Its `end` sat at the bottom of the spec, one line above `install_modules_dependencies(s)`, and the indentation of everything after the `s.dependency` call reads as if the block had already ended. So five attributes were assigned only when OpenCV was on: | attribute | what an app loses without it | | --- | --- | | `pod_target_xcconfig` | every `HEADER_SEARCH_PATHS` entry | | `vendored_frameworks` | `ExecutorchLib.xcframework` | | `static_framework` | the `use_frameworks!` fix from #1448 | | `libraries` | `z`, `sqlite3` | | `frameworks` | `Accelerate`, `CoreML`, Metal | An app that turns OpenCV off through the `libs` config block installs fine and then fails to compile or link. #1450 is what made this reachable: before it, a config block in an app package was ignored and OpenCV was always on. **`rne_build_config` was nil without a config file.** The `else` branch set the five `enable_*` flags but never assigned the hash, and #1450 added `rne_build_config["opencvPod"]` on the path that branch reaches, so a checkout without `rne-build-config.json` raised `NoMethodError` during `pod install`. The comment above it names that case as supported ("a fresh checkout where the native libs were provisioned manually"). The branch is gone: the config is a hash either way, and every flag already reads `!= false`, so an empty hash means all-enabled. **Test.** `pod install` is the only thing that runs this file, and every example app takes the same config row, so a misplaced `end` passes lint, types, tests and review. `__tests__/api/podspecAttributes.test.ts` evaluates the real podspec under a stubbed `Pod::Spec` and asserts the build-critical attributes are assigned, for eight config rows. Against `a1ff6c9` it fails three of them: ``` ● with no config file (manual provisioning) podspec:242: undefined method `[]' for nil:NilClass (NoMethodError) ● with opencv off ● with every optional library off missing: pod_target_xcconfig, static_framework, vendored_frameworks, libraries, frameworks ``` ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) ### Tested on - [ ] iOS - [ ] Android ### Testing instructions ```bash yarn workspace react-native-executorch test __tests__/api/podspecAttributes.test.ts git stash && yarn workspace react-native-executorch test __tests__/api/podspecAttributes.test.ts # 3 failures ``` Needs an `enableOpencv: false` `pod install` on a device build before merge; I have only run the podspec evaluation. ### Related issues Follow-up to #1450. ### Additional notes Backport to `release/0.10` goes on top of #1451.
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
) ## Description Backports the three 0.10.0 setup fixes from `main` to `release/0.10`, plus the follow-up that fixes two defects in the third one. Cherry-picked with `-x`, no manual edits to any of them. | commit | PR | | --- | --- | | `12ce3bb` | #1448 fix(ios): narrow the podspec's public headers | | `c51f76a` | #1449 fix(deps): require worklets >=0.10.0 <0.13.0 and document it | | `a1ff6c9` | #1450 fix(build): fail with the cause when the setup is wrong | | `080e764` | #1452 fix(ios): keep the podspec's build attributes out of the OpenCV branch | All four are now on `main`; #1452 merged as `c8f44f6`. Only conflict was `docs/versioned_docs/version-0.10.0/**`: that snapshot exists on `main` only, since on this branch `docs/docs` **is** the 0.10 documentation. Those three hunks were dropped and the equivalent `docs/docs` changes came across in the same commits. `packages/react-native-executorch/package.json` keeps `0.10.0`; only the worklets peer range changed. ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Bug fix (change which fixes an issue) - [ ] New feature (change which adds functionality) - [ ] Documentation update (improves or adds clarity to existing documentation) - [ ] Other (chores, tests, code style improvements etc.) ### Tested on - [ ] iOS - [ ] Android ### Testing instructions `yarn workspace react-native-executorch test` passes, 3868 tests across 34 suites. The podspec, `android/build.gradle.kts`, `scripts/download-libs.js` and the new podspec test on this branch are byte-identical to `main`: ```bash git fetch origin main git diff origin/main HEAD -- packages/react-native-executorch/react-native-executorch.podspec \ packages/react-native-executorch/android/build.gradle.kts \ packages/react-native-executorch/scripts/download-libs.js \ packages/react-native-executorch/__tests__/api/podspecAttributes.test.ts ``` ### Related issues #1448, #1449, #1450, #1452 --------- Co-authored-by: Bartosz Hanc <bartosz.hanc02@gmail.com> Co-authored-by: Mateusz Słuszniak <msluszniak1@gmail.com>
msluszniak
added a commit
that referenced
this pull request
Sep 9, 2026
## Description Patch release **v0.10.1**. The fixes are already on `release/0.10` via #1451 (backports of #1448, #1449, #1450, #1452); this PR only bumps the version. - `packages/react-native-executorch/package.json`: `0.10.0` -> `0.10.1`. `nativeLibsVersion` stays `0.10.0`; the native artifacts release is unchanged. - `src/fetcher/telemetry.ts`: `LIB_VERSION` -> `0.10.1`, asserted equal to the package version by `__tests__/fetcher/telemetry.test.ts`. Satellites (`bare-resource-fetcher`, `expo-resource-fetcher`, `webrtc`) are untouched by the backports, so their versions stay at `0.10.0`. `models.ts` stays on `resolve/v0.10.0`; no model files moved. ### Introduces a breaking change? - [ ] Yes - [x] No ### Type of change - [x] Other (chores, tests, code style improvements etc.) ### Tested on - [ ] iOS - [ ] Android ### Testing instructions CI runs `yarn workspace react-native-executorch test`; the telemetry version assertion covers the bump. ### Related issues #1451 ### Checklist - [x] I have performed a self-review of my code - [x] My changes generate no new warnings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Setup failures that reach the user as an error pointing somewhere else. All reproduced against the published 0.10.0.
Guards. The native artifacts are downloaded by the postinstall hook, which pnpm 10 blocks by default (
Ignored build scripts), as do--ignore-scriptsandnpm ci --ignore-scripts.pod installstill succeeds, because CocoaPods never checks that a vendored framework exists, and the build dies later onBuild input files cannot be found. The podspec andbuild.gradle.ktsnow check first and namepnpm approve-builds/npm rebuild.Config block in a monorepo. It was read only from
INIT_CWD, the workspace root, so a block inapps/mobile/package.jsonwas ignored and an app declaring"libs": []got OpenCV anyway. The lookup now also walks up from the installed package and logs which manifest it read.Android
minSdkVersion. Default was 21, docs said Android 13+, nothing enforced either..note.android.identreads API 26 in all three shipped.sofiles, so anything lower shipped a library the linker is not guaranteed to load. Default is now 26.Docs. A Troubleshooting page keyed by the exact error text covers the rest:
use_frameworks!dynamictransitive dependencies that include statically linked binariesframeworks with conflicting names: opencv2.xcframeworkNone of the architectures in ARCHS (x86_64) are validexpo-build-propertiesreactNativeArchitecturesarmeabi-v7a/x86splits ship without the.soThe OpenCV conflict has a verified escape hatch:
"libs": ["phonemis"]dropsopencv-rneandpod installthen succeeds, at the cost of every vision task.Introduces a breaking change?
Type of change
Tested on
Testing instructions
pod ipc spec react-native-executorch.podspecin a checkout without artifacts prints the missing paths and the fix, and passes once they exist. 7 tests in__tests__/api/nativeLibsConfig.test.tscover the config lookup. Docs build and lint clean.Checklist
Additional notes
The Gradle guard has not been run. It configures at the top of
build.gradle.kts, so please build an Android app on this branch before merging. RaisingminSdkVersioncan also break an app currently on 21-25; that build was already unsound, but it is a behaviour change.